Dipende da cosa si intende per "analisi sicura del codice sorgente". Si può fare tutto ciò che si vuole. 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 fornirà una dichiarazione che sostanzialmente dice "Dichiaro che questo codice è sicuro", con una comprensione che è un'affermazione più profonda di "Ho cercato un mucchio di modelli noti e non ho trovato problemi". / p>

Se fossi interessato alla traduzione autentica di una filosofia cinese, ti fideresti di una persona che conosceva molto la filosofia e aveva un mucchio di foglietti per aiutarla a decifrarla, ma in realtà non conosceva il cinese ?

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

  int storeDataInCircularBuffer (Buffer * dest, const char * src, size_t length) {if (dest->putPtr + length < dest->putPtr) return ERROR ; // previene l'overflow del buffer causato da un overflow if (dest->putPtr + length > dest->endPtr) {... // scrive i dati in due parti return OK; } else {... // scrive i dati in una parte return OK; }}  

Questo codice doveva essere parte di un buffer circolare. In un buffer circolare quando raggiungi la fine del buffer, ti avvolgi. A volte questo ti costringe a suddividere il messaggio in arrivo in due parti, il che va bene. Tuttavia, in questo programma SQL, si preoccupavano del caso in cui length potesse essere abbastanza grande da causare un overflow di dest->putPtr + length , creando un'opportunità per un buffer overflow perché il prossimo controllo non funzionerebbe bene. Quindi mettono in un test: if (dest->putPtr + length < dest->putPtr) . La loro logica era che l'unico modo in cui questa affermazione potrebbe essere vera è se si è verificato un overflow, quindi rileviamo l'overflow.

Questo ha creato un buco di sicurezza che è stato effettivamente sfruttato e ha dovuto essere corretto. Perché? Bene, 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 l'ha testato, gcc ha effettivamente emesso il codice corretto. Tuttavia, alcune versioni successive, gcc ha avuto ottimizzazioni per sfruttare questo. Ha visto che non esisteva un comportamento definito in cui l'istruzione if poteva superare il suo test e l'ha ottimizzata!

Quindi, per un poche versioni, le persone avevano server SQL che avevano un exploit, anche se il codice aveva controlli espliciti per prevenire tale exploit!

Fondamentalmente i linguaggi di programmazione 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 trovare un avviso CERT su questo: Nota sulla vulnerabilità VU # 162289 Compilatori C potrebbe ignorare silenziosamente alcuni controlli avvolgenti. e anche questo correlato. Grazie Greg!

Penso che sia necessario essere un buon programmatore per avere successo, quindi ti consiglio di diventarlo. Potrebbero esserci molte cose che mancano al tuo toolkit / scanner. Onestamente non consiglio di affidarti completamente agli strumenti che scansionano il tuo codice per te, 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 capacità di passare attraverso 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 ciò che vuoi quando si tratta di produrre un prodotto solido ed esattamente ciò di cui hai bisogno durante una revisione del codice.

Anche se 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 il codice da solo e determinare se è buono o cattivo? Waaaay meglio.

Non provare a superare una verifica del codice sicuro se non sai cosa stai facendo, ma non rinunciare completamente all'idea se ritieni di non essere a un punto in cui puoi fare una buona recensione. Consiglio di provare a imparare creando le tue revisioni del codice sicuro mockup e di esaminarle alcune volte per assicurarti che tutto sia a posto.

Tuttavia, dovresti assolutamente imparare non solo a programmare, ma anche a programmare 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 tecnica o sintattica che vengono utilizzate in modo improprio in qualche modo minore. Un punto e virgola mancante, un segno di uguale invece di un doppio uguale, un confine di array che è stato definito doppiamente il primo giorno ma una versione è stata modificata nella versione successiva, parentesi mancanti, perdite di memoria, tutti hanno portato a vulnerabilità. Uno sviluppatore esperto potrebbe vederli, ma un principiante probabilmente no.

Ciò che il tuo esperto di sicurezza dovrebbe fare è incoraggiare i tecnici a utilizzare strumenti di scansione automatizzata come analizzatori di codice statici, tester fuzz e verificatori dinamici di app . Aiuta i team di ingegneri a comprendere la convalida dell'input, gli attacchi di iniezione, i limiti di fiducia. Sviluppa la consapevolezza che i difetti di sicurezza devono essere assegnati in modo appropriato e risolti rapidamente. Pianifica e conduci test di penna. E, cosa più importante, fare in modo che gli ingegneri eseguano revisioni del codice sul 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 di sicurezza del codice.

Dipende dalle tue aspettative. Le vulnerabilità di sicurezza causate da problemi di progettazione (es. Protezione CSRF mancante, solo implementazione rudimentale di un protocollo ecc.) Possono probabilmente essere trovate se il tester ha una profonda conoscenza dei concetti di sicurezza, anche se è solo in grado di seguire il flusso del 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 \ 0 , problemi causati da la dimensione dei tipi di dati e firmato o non firmato, ecc. non verrà trovata se il tester non ha una conoscenza più approfondita della lingua, delle cattive pratiche e dei modelli di insicurezza tipici specifici della lingua. Prendi la storia delle vulnerabilità di Java come esempio, dove nemmeno gli sviluppatori esperti di Java hanno notato i buchi che hanno perforato nella sandbox del linguaggio aggiungendo riflessioni al linguaggio e solo esperti esterni con una profonda conoscenza di gli interni del linguaggio hanno rilevato i difetti.

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

Anche questa comprensione è richiesta con linguaggi di scripting come JavaScript che interpretano il codice di alto livello nelle istruzioni della CPU e nell'allocazione della memoria. Sfortunatamente, questa recensione dipenderà dalla piattaforma. Vedi ad esempio su https://en.m.wikipedia.org/wiki/Interpreted_language.

Occorre essere un buon programmatore per eseguire analisi sicure del codice sorgente?

No.

Sarà in grado di eseguire revisione del codice sicura senza la conoscenza di più linguaggi di programmazione e la padronanza di essi?

No.

La programmazione è molto più che competenza nei dettagli di come funzionano i vari linguaggi. È una delle cose di cui hai bisogno per essere un buon programmatore, ed è anche una delle cose di cui hai bisogno per essere in grado di analizzare il codice sorgente da una prospettiva di sicurezza (o da qualsiasi altra qualità).

Quindi mentre tu non è necessario essere un buon programmatore, è necessaria la padronanza dei linguaggi coinvolti.

Per capire correttamente il pericolo di attacchi di canale laterale, è necessario conoscere l'hardware. Ci sono attacchi di canale laterale davvero brutti, come eseguire un processo non privilegiato su una configurazione multi-CPU in parallelo con uno privilegiato che esegue alcune attività di crittografia / decrittografia e sondare quali linee di cache condivise vengono sporcate in che tipo di modello temporale o da Temporizzazione della rispettiva consegna di sequenze di pattern specifiche che vengono crittografate.

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