Secondo le mie informazioni, non esiste una regola rigida per eseguire una revisione del codice di sicurezza, ma tutti noi sviluppiamo la nostra strategia per lo stesso. Mi stavo chiedendo se tutti noi possiamo condividere le diverse strategie coinvolte o utilizzate nella revisione del codice di sicurezza.
Come @sonofaaa ha menzionato, nel libro "L'arte della valutazione della sicurezza del software", gli autori discutono le strategie di auditing del codice nel capitolo 4 (fine della parte I).
In particolare, la sensibilità del flusso esterno (flusso di dati e flusso di controllo) e la direzione di tracciamento (affettamento in avanti o indietro) sono discussi insieme a molti metodi neutri di revisione. Altri argomenti sono discussi in grande dettaglio. È il miglior materiale scritto in materia di revisione sicura del codice.
Dovrei anche menzionare "Programmazione sicura con analisi statica" - un libro di Brian Chess e Jacob West di Fortify Software. Coprono gli interni e utilizzano strumenti di analisi statica incentrati sulla sicurezza e li confrontano con altri moduli / strumenti nel mondo di revisione del codice protetto.
Se vuoi verificare i moderni analizzatori statici incentrati sulla sicurezza, ti suggerisco di iniziare a utilizzare alcuni strumenti open source o gratuiti come CAT.NET per .NET (in genere C #, VB.NET e / o ASP.NET), find-sec-bug (o il precedente LAPSE +) per Java Enterprise e JSP e RIPS Scanner per PHP. Normalmente non troverai analizzatori statici orientati alla sicurezza che supportano i linguaggi dinamici, perché non si basano su un sistema di tipi, ma fammi sapere se sei interessato al supporto di Python, Ruby o di un altro linguaggio dinamico (o di qualsiasi altro lingua) e cercherò di indicarti la giusta direzione. Per cominciare, prova Bandit (progetto OpenStack per codice Python) e Brakeman Pro per Ruby.
Gli analizzatori statici focalizzati sulla sicurezza commerciale sono pensati per sviluppatori orientati alla sicurezza di applicazioni altamente specializzati e specializzati. Il costo di questi presuppone che qualcuno eseguirà e analizzerà questi strumenti quotidianamente, come un lavoro a tempo pieno, durante tutto l'anno. Se sei interessato a vedere risultati rapidi - controlla HPFOD - ma se sei interessato a integrare questi strumenti a lungo termine, portafoglio di applicazioni a rischio per un'installazione di grandi dimensioni: consulta Cigital ESP . Ci sono anche molte boutique di sicurezza delle applicazioni e negozi di consulenza che eseguono e ottimizzano questi strumenti per i loro clienti. A seconda del tuo locale e della direzione strategica, sceglierei di collaborare con uno indipendentemente da qualsiasi altra cosa che ho menzionato, in quanto possono essere inestimabili per il successo di un programma appec. Cercare su LinkedIn "consulenza sulla sicurezza delle applicazioni" dovrebbe funzionare se non sai dove andare dopo.
Di solito inizio con una lista di controllo. Di 'la OWASP top 10 o le linee guida per la codifica CERT C (o la sezione del mio libro!). Ottengo il team per valutare il codice in relazione alla checklist e anche per eseguire test e revisioni indirette. I problemi "popolari" della revisione aperta vengono aggiunti all'elenco di controllo, sostituendo i problemi non presenti in origine.
Inoltre, vengono utilizzati gli strumenti di analisi statica laddove disponibili.
Il vantaggio di questo approccio è anche il suo più grande svantaggio. I problemi della lista di controllo sono facilmente individuabili, ma spesso sono gli unici problemi riscontrati poiché la ricerca di errori creativi non è facile.
Contrariamente alla tua affermazione, credo che la revisione del codice (di sicurezza) non dovrebbe essere un'attività prevalentemente ad-hoc. Esistono alcune metodologie piuttosto forti per eseguire una revisione del codice efficiente . Per ottenere i migliori risultati, questo dovrebbe essere fatto in modo incrementale e iterativo.
Ecco un esempio di un profilo ad alto livello di tale metodologia, con alcuni principi guida:
TAOSSA La parte I copre diversi approcci e scenari ibridi, e Brandon Edwards fa un ottimo lavoro per esaminare le strategie di revisione agnostica della tecnologia e le insidie più comuni di recensioni di grandi dimensioni nei video qui (http://pentest.cryptocity.net/code- audit /)
Alcune metodologie possono leggermente differire a seconda di ciò che si sta verificando - per le applicazioni Web può essere una, per le applicazioni C / C ++ un'altra. Inoltre, dipende dal fatto che il codice sorgente sia disponibile. Ma, generalmente, coinvolge le seguenti fasi:
Durante questo processo vengono utilizzati analizzatori di codice statici o dinamici. Quale da usare dipende da te, i link che ho dato potrebbero aiutarti.
Tuttavia, molto spesso devi controllare il software che è stato precedentemente verificato da te, quindi puoi semplificare il tuo lavoro. Per il codice sorgente puoi usare WinMerge , che ti permetterebbe di trovare le differenze tra la vecchia e la nuova versione. Per binario puoi usare Darungrim , BinDiff .
Gli argomenti che potrebbero avere senso leggere riguardo alla domanda corrente possono essere trovati qui intorno:
Leggi altre domande sui tag appsec code-review manual-review