È necessario essere un buon programmatore per eseguire un'analisi sicura del codice sorgente?

Dipende da cosa si intende per "analisi sicura del codice sorgente". Si può fare qualsiasi cosa si voglia. Il problema, presumo, è quando qualcun altro ha chiesto qualcosa chiamato "analisi sicura del codice sorgente" e ci si chiede perché non si è qualificati per questo.

In molti casi, tale analisi deve essere eseguita da un esperto in materia (PMI). Nel prodotto finale, una PMI pubblicherà una dichiarazione dicendo sostanzialmente "Dichiaro che questo codice è sicuro", con una comprensione che è una dichiarazione più profonda di "Ho cercato un sacco di modelli conosciuti, e non ho trovato problemi."

Se ti interessasse l'autentica traduzione di una filosofia cinese, ti fideresti di un individuo che conosceva molto la filosofia e aveva un sacco di trucchi per aiutarti a decifrarlo, ma in realtà non conosceva il cinese?

Un grande esempio che mi viene in mente è un bug che ha colpito un motore SQL. Perdonami per non avere il nome di quale motore, o quale versione puoi verificare, ho avuto problemi a trovarlo da allora. Tuttavia, l'errore è stato commovente. L'errore era nel codice che assomigliava a questo:

int storeDataInCircularBuffer(Buffer* dest, const char* src, size_t length)
{
    if (dest->putPtr + length < dest->putPtr)
        return ERROR; // prevent buffer overflow caused by overflow
    if (dest->putPtr + length > dest->endPtr) {
        ... // write the data in two parts
        return OK;
    } else {
        ... // write the data in one part
        return OK;
    }
}

Questo codice era destinato a far parte di un buffer circolare. In un buffer circolare quando raggiungi la fine del buffer, ti avvolgi. A volte questo ti costringe a rompere il messaggio in arrivo in due parti, il che è ok. Tuttavia, in questo programma SQL, erano interessati al caso in cui length poteva essere abbastanza grande da causare un eccesso di dest->putPtr + length , creando un'opportunità per un overflow del buffer perché il controllo successivo non funzionava correttamente. Quindi hanno inserito un test: if (dest->putPtr + length < dest->putPtr) . La loro logica era che l'unico modo in cui questa affermazione potesse mai essere vera è se si verificava un overflow, quindi prendiamo l'overflow.

Questo ha creato un buco di sicurezza che è stato effettivamente sfruttato e ha dovuto essere riparato. Perché? Beh, all'insaputa dell'autore originale, la specifica C ++ dichiara che l'overflow di un puntatore è un comportamento indefinito, il che significa che il compilatore può fare tutto ciò che vuole. Come è successo, quando l'autore originale lo ha testato, gcc ha effettivamente emesso il codice corretto. Tuttavia, alcune versioni successive, gcc ha avuto ottimizzazioni per sfruttare questo. Ha visto che non c'era un comportamento definito in cui quell'istruzione if potesse superare il test e l'ha ottimizzata!

Così, per alcune versioni, le persone avevano server SQL che avevano un exploit, anche se il codice aveva controlli espliciti per prevenire detto exploit!

I linguaggi di programmazione fondamentali sono strumenti molto potenti che possono mordere lo sviluppatore con facilità. Analizzare se ciò accadrà richiede una solida base nella lingua in questione.

(Modifica: Greg Bacon è stato abbastanza bravo da scovare un avviso CERT al riguardo: Nota di vulnerabilità VU # 162289 C i compilatori possono scartare silenziosamente alcuni controlli wraparound. e anche questo relativo. Grazie Greg!)

Penso che sia necessario essere un buon programmatore per avere successo, quindi consiglierei di diventarlo. Potrebbero esserci molte cose che mancano al tuo toolkit / scanner. Sinceramente non consiglio di affidarti completamente agli strumenti per eseguire la scansione del tuo codice, poiché gli exploit cambiano costantemente e qualcuno potrebbe aver codificato in un modo in cui lo scanner non è in grado di rilevare le vulnerabilità.

La possibilità di scorrere il codice e vedere come funziona, e come non dovrebbe funzionare, è fondamentale per proteggere lo sviluppo del software. Avere uno sviluppatore consapevole dei problemi di sicurezza è esattamente quello che vuoi quando si tratta di produrre un prodotto solido, e esattamente quello di cui hai bisogno durante una revisione del codice.

Mentre sì, puoi puntare e fare clic e controllare le vulnerabilità con i tuoi scanner e toolkit, non sarà molto efficace nel grande schema delle cose. Sai quanto saresti più efficace se potessi guardare al codice te stesso e determinare se è buono o cattivo? Waaaay meglio.

Non provare a passare una recensione sicura del codice se non sai cosa stai facendo, ma non rinunciare all'idea se non ti senti in un punto in cui puoi fare un buona recensione Ti consiglio di provare a imparare creando le tue recensioni di codice di sicurezza personali e esaminandole alcune volte per assicurarti che tutto sia a posto.

Ma ancora, dovresti sicuramente imparare non solo a scrivere codice, ma a scrivere bene.

È dubbio che un esperto di sicurezza sarebbe efficace nell'eseguire l'analisi del codice sorgente senza essere anche un abile programmatore. Molte vulnerabilità sono il risultato di pratiche di codifica tecniche o sintattiche che vengono utilizzate in modo non corretto. Un punto e virgola mancante, un segno di uguale invece di un doppio equivale, un limite di matrice che è doppiamente definito il primo giorno, ma una versione viene modificata nella versione successiva, parentesi mancanti, perdite di memoria, tutti hanno portato a vulnerabilità. Uno sviluppatore esperto potrebbe vederli, ma probabilmente un principiante non lo farebbe.

Ciò che dovrebbe fare il tuo esperto di sicurezza è incoraggiare gli ingegneri a utilizzare strumenti di scansione automatizzati come analizzatori di codici statici, tester di fuzz e verificatori di app dinamici. Aiuta i team di ingegneri a comprendere la convalida degli input, gli attacchi di iniezione, i limiti di affidabilità. Creare consapevolezza sul fatto che i difetti di sicurezza devono essere priorizzati in modo appropriato e affrontati rapidamente. Pianificare e condurre i test di penna. E, cosa più importante, fai in modo che gli ingegneri facciano le revisioni del codice del lavoro degli altri.

Sì, l'esperto di sicurezza dovrebbe essere in grado di leggere il codice, ma ciò non significa che sia qualificato per essere l'arbitro della sicurezza del codice.

Dipende dalle tue aspettative. Le vulnerabilità di sicurezza causate da problemi di progettazione (ad esempio la mancanza della protezione CSRF, l'implementazione rudimentale di un protocollo, ecc.) Possono probabilmente essere trovate se il tester ha una profonda conoscenza dei concetti di sicurezza, anche se (s) è in grado di seguire il flusso di codice senza avere una conoscenza più approfondita del linguaggio di programmazione specifico.

Ma problemi di sicurezza specifici del linguaggio come buffer overflow, errori off-by-one, gestione di unicode o %code% , problemi causati dalla dimensione dei tipi di dati e firmati e non firmati ecc. non saranno trovati se il tester ha nessuna conoscenza approfondita della lingua, delle cattive pratiche e dei tipici schemi di insicurezza specifici della lingua. Prendiamo come esempio la storia delle vulnerabilità di Java, dove nemmeno gli sviluppatori esperti di Java hanno notato i buchi che hanno inserito nella sandbox della lingua aggiungendo una riflessione alla lingua e solo esperti esterni con una profonda conoscenza degli interni linguistici hanno rilevato i difetti.

Does one need to be a good programmer to perform secure source code analysis?

No.

Will he be able to perform secure code review without knowledge of multiple programming languages and mastery over them?

No.

C'è molto di più della programmazione che dell'esperienza nei dettagli di come funzionano le varie lingue. È una delle cose che devi essere un buon programmatore, ed è anche una delle cose che devi essere in grado di analizzare il codice sorgente da una prospettiva di sicurezza (o qualsiasi altra qualità).

Quindi, anche se non hai bisogno di essere un buon programmatore, hai bisogno della padronanza delle lingue coinvolte.

Non solo la revisione sicura del codice richiede la conoscenza del linguaggio di alto livello, ma anche delle opzioni del compilatore e COME IL CODICE FUNZIONERÀ ATTUALMENTE SULLA CPU! I linguaggi di alto livello sono efficienti per scrivere codice perché nascondono molta della complessità. Ma molti errori e bug si nascondono all'interno della complessità. Come sottolineato in un'altra risposta, i compilatori cercano di fare la cosa giusta, ma è davvero necessario capire cosa sta succedendo smontando il codice e sviluppando una profonda comprensione di come funziona.

Questa comprensione è richiesta anche con linguaggi di scripting come JavaScript che interpretano il codice di alto livello per le istruzioni della CPU e l'allocazione della memoria. Sfortunatamente, questa recensione dipenderebbe dalla piattaforma. Vedi ad esempio il link .

Per capire correttamente il pericolo degli attacchi dei canali laterali, è necessario conoscere l'hardware. Ci sono davvero brutti attacchi sul canale laterale, come l'esecuzione di un processo non privilegiato su un'installazione multi-CPU in parallelo con uno privilegiato che esegue alcune attività di crittografia / decrittografia e il sondaggio che le linee della cache condivise vengono sporcate in quale tipo di modello temporale o sincronizzare la consegna delle specifiche sequenze di pattern che vengono crittografate.

Poiché gli algoritmi di crittografia sono sottoposti a un attento esame da parte dei matematici e di altri teorici, gli attacchi a canali laterali sono sempre più importanti modi per aprire di nuovo il gioco. Lo svantaggio è che devono essere creati per una particolare implementazione, codice e hardware.