Secure Code Review: Un approccio pratico

Questo articolo riguarda diverse tecniche di revisione del codice e la loro applicazione nel mondo reale

Cosa imparerai:

Cos’è la revisione del codice sicuro e come gestirli in scenari di vita reale

Cosa dovresti sapere:

Concetti di sicurezza di base

Revisione del codice sicuro:

Secure Code Review è un processo che identifica il pezzo di codice insicuro che può causare una potenziale vulnerabilità in una fase successiva del processo di sviluppo del software, portando infine a un’applicazione non sicura. Quando viene rilevata una vulnerabilità nelle fasi precedenti di SDLC, ha un impatto minore rispetto alle fasi successive di SDLC, quando il codice insicuro si sposta nell’ambiente di produzione. Nel processo SDLC (Software Development Life Cycle), il processo di revisione del codice sicuro rientra nella fase di sviluppo, il che significa che quando l’applicazione viene codificata dagli sviluppatori, possono eseguire la revisione del codice autonomo o un analista della sicurezza può eseguire la revisione del codice o entrambi. Gli sviluppatori possono utilizzare strumenti automatici che possono essere integrati con il loro IDE (Eclipse, MS VS, ecc.) Successivamente, possono richiedere l’aiuto di un esperto di sicurezza per identificare più difetti nel codice, poiché gli esperti di sicurezza hanno una visione più intrinseca dei problemi di sicurezza che potrebbero essere persi dagli sviluppatori.

Diversi studi e sondaggi mostrano che circa il 75% degli attacchi avviene a causa di un’applicazione non sicura, all’interno della quale è incluso il codice non sicuro. In questo modo, diventa una parte molto essenziale di SDLC che dovrebbe essere eseguita rigorosamente. Gli sviluppatori tendono principalmente a concentrarsi sulla funzionalità dell’applicazione e ignorano l’approccio di codifica sicura. Ma al giorno d’oggi sono diventati più consapevoli della revisione del codice a causa dei crescenti incidenti di hacking e attacchi ai server.

Figura– 1

Tecniche per proteggere la revisione del codice:

in generale, possiamo dividere il codice di sicurezza il processo di revisione in due diverse tecniche:

1. strumento automatico/ con Scatola Nera: In questo approccio, il codice di sicurezza revisione è effettuata utilizzando diversi open source/strumenti commerciali. Per lo più gli sviluppatori li usano mentre stanno codificando, ma un analista di sicurezza può anche prendere l’aiuto di loro. Gli strumenti sono molto utili durante la revisione del codice quando implementiamo il processo SDLC sicuro nell’organizzazione e forniamo lo strumento agli sviluppatori stessi per eseguire una revisione “self-code” mentre stanno codificando. Inoltre, gli strumenti sono utili per analizzare grandi basi di codice (milioni di linee). Possono identificare rapidamente potenziali pezzi di codice insicuri nella base di codice, che possono essere analizzati dallo sviluppatore o da un analista di sicurezza.
2. Manuale / Scatola bianca: In questa tecnica, una revisione approfondita del codice viene eseguita su tutto il codice, che può diventare un processo molto noioso e noioso. Ma in questo processo, difetti logici possono essere identificati che potrebbe non essere possibile utilizzando strumenti automatizzati, come problemi di logica di business. Gli strumenti automatici sono per lo più in grado di trovare difetti tecnici come gli attacchi di iniezione, ma possono mancare difetti come problemi di autorizzazione. In questo processo, invece di passare riga per riga attraverso l’intera base di codice, possiamo concentrarci su potenziali problemi nel codice. Queste potenziali vulnerabilità possono essere date un’alta priorità. Ad esempio, in C/C++, se cerchiamo di trovare qualsiasi funzione di copia nel codice e verificare se sta usando funzioni come, strcpy() per eseguire la funzione di copia. Come sappiamo, strcpy () è noto per essere vulnerabile agli attacchi di buffer overflow. Potremmo anche voler verificare se nell’applicazione viene utilizzata una crittografia personalizzata, che gli strumenti automatici potrebbero mancare in quanto possono identificare solo algoritmi standard.

   Quindi l’approccio migliore sarà un mix di entrambi, a seconda del volume e della criticità dei dati. Nel mondo di oggi in cui vengono sviluppate molte applicazioni complesse, non possiamo ignorare nessuna delle tecniche sopra menzionate.

Vantaggi di Fissare la revisione del codice:

Ci sono alcuni fattori che devono essere presi in considerazione durante lo sviluppo di un robusto meccanismo di controllo di accesso dell’applicazione web:

1. Sforzo vantaggio: L’impegno a risolvere le vulnerabilità in una prima fase di SDLC processo è più o meno la fase successiva del processo. Una volta che il codice è completo e il difetto non è identificato, è un processo molto noioso e dispendioso in termini di tempo per trovare problemi una volta che l’applicazione è pronta per entrare in produzione. Inoltre, il fissaggio dell’ultimo minuto può influire sull’intera funzionalità del programma e ostacolare le scadenze fissate per il rilascio del prodotto. Chissà, potrebbe creare un’altra falla di sicurezza, che può essere facilmente possibile con un codice ampio e complesso.
2. Costo beneficio: Il costo è direttamente proporzionale allo sforzo richiesto. Non solo i costi di sviluppo, ma anche, una vulnerabilità identificata nell’ambiente di produzione può comportare maggiori costi. Ancora una volta, ne vale la pena, poiché i costi associati a un attacco possono essere molto più ripidi.
3. Conformità: Alcune conformità, come PCI, rende necessario fare una revisione del codice sicuro prima di lanciare il prodotto. Quindi un’organizzazione che segue SDLC completo ha maggiori possibilità di essere certificata.
4. Reputazione: Secure code review rimuove la maggior parte delle falle di sicurezza nella fase precedente, rendendola più sicura rispetto alle semplici valutazioni della scatola nera. Quindi c’è meno possibilità che il prodotto sia compromesso, quindi minore possibilità di danni alla reputazione.

Approccio:

Questi sono basati su mix di processo standard e il mio approccio. Può differire da persona a persona.

Processo standard:

Figura-2

Definisci ambito: in primo luogo, è necessario comprendere e fornire una stima approssimativa sull’ambito della revisione del codice e sugli sforzi in esso coinvolti. Inoltre, i vincoli di bilancio possono essere definiti. Che tipo di revisione del codice può essere eseguita? Scatola nera o scatola bianca? Cerca di capire la logica di business dell’applicazione. Ricorda quali vulnerabilità devi cercare, come OWASP Top 10, SANS, ecc. Puoi provare a rivederle il più possibile, se non tutte. Quindi puoi dedurre quanti di essi possono essere rilevati utilizzando gli strumenti e quali sono più adatti per la revisione manuale.

Categorizza le vulnerabilità: qual è la tua priorità, ovvero quale tipo di vulnerabilità prenderai come priorità? Ad esempio, nelle applicazioni aziendali, è possibile concentrarsi principalmente sulla logica di business dell’applicazione e immergersi in profondità, poiché quelle tecniche sono facilmente rilevabili dagli strumenti. Dare loro la priorità.

Le seguenti sono alcune categorie che puoi guardare:

• Autorizzazione
• Autenticazione
• difetti di Iniezione
• Impropria gestione degli errori/Eccezioni difetti
• Encryption (Crittografia)
• il Controllo e la Registrazione
• Relative alla sessione di difetti (gestione della Sessione)
• Insicuro configurazione

Raccomandazione: Come un analista di sicurezza, è nostro dovere filtro falsi positivi generati dagli strumenti e confermare per confermare che essi sono veri e propri difetti. Dopo aver fatto una corretta revisione del codice, è necessario documentare le vulnerabilità trovate in un rapporto completo che copre la categoria della vulnerabilità e la loro mitigazione. Si può andare un passo avanti e suggerire un codice sicuro di esempio. Personalmente includo anche i frammenti di codice nel report, preferibilmente in un file Excel e quindi lo allego.

Questo è il modo in cui lo faccio personalmente. I punti seguenti si basano sulla mia esperienza fino alla data di revisione del codice. Ho ancora molto da imparare e i punti qui sotto possono o non possono valere in ogni condizione:

Esegui sempre revisioni manuali: la revisione automatica del codice è un processo in cui esegui gli strumenti di scansione come Rational, Ounce Labs e Parasofton la base di codice seguita da un controllo manuale dei risultati. Lo scanner contrassegna l’intero codice con vulnerabilità in base alla sua percezione. Ora è compito dell’auditor distinguere tra problemi reali e falsi positivi. Qui è dove inizia il vero dolore. Non hai il comando su ogni lingua. Quindi è necessario l’aiuto di risorse specifiche per la lingua. Ora, ho familiarizzato con quasi tutte le principali lingue (.NET, Java, PHP) vulnerabilità specifiche. Facendo una valutazione scatola nera non si arriva mai a sapere dove si trova il vero problema.

Parla prima con gli sviluppatori: più coinvolgi gli sviluppatori nel processo di revisione del codice, più efficace sarà l’analisi. Hai fiducia che qualunque cosa tu stia facendo si basa sulla giusta comprensione del codice. D’altra parte, gli sviluppatori anche ottenere felice che si sta prendendo theminto fiducia invece di dichiarare qualcosa di vulnerabile subito.

Avere un notebook e penna a portata di mano per capire il flusso del programma. Comprendere la fonte della macchia e dove si riflette nel codice è necessario per catturare le vulnerabilità reali. Solo vedendo che la macchia sta entrando nel programma e riflettendo in qualche altra parte del programma non sempre significa che è vulnerabile a Cross Site Scripting, per esempio. Anche in questo caso, parlare con gli sviluppatori aiuta, in quanto potrebbero implementare un meccanismo di filtraggio/convalida dell’input centralizzato. Quindi non saltare alle conclusioni.

Usa un editor di testo avanzato: l’editor di testo dovrebbe essere in grado di cercare un termine nell’intera base di codice. Uno di questi editor di testo è Notepad++. Si cerca il termine e li mette in evidenza in modo che si può vedere dove tutti i luoghi il termine particolare viene utilizzato. Ti aiuta a unire i pezzi e vedere il quadro completo.

Hai tempo sufficiente per fare la revisione del codice, in quanto devi applicare i tuoi pensieri più di una volta per rilevare vulnerabilità reali. Quindi chiedi sempre ai tuoi clienti un tempo sufficiente per completare completamente il progetto.

Essere connessi a Internet aiuta sempre al momento della revisione del codice. Alcuni termini, funzioni o metodi ti infastidiscono sempre come potresti non averli visti prima. Google aiuta molto a capirli.

Trova vulnerabilità nel contesto dell’applicazione: non solo dovresti rilevare vulnerabilità reali e applicabili nel contesto dell’applicazione – poiché diminuisce il numero di problemi – ma anche, dovresti proporre le contromisure nel rapporto. Ciò rende gli sviluppatori felici e fiduciosi. Lo scanner può segnalare qualsiasi problema come Alto, Medio o basso. È tua responsabilità dare loro una classifica appropriata in base al contesto delle applicazioni.

Ognuno ama il proprio programma: i programmi sono come un bambino sviluppatori. Non sempre individuare i punti deboli del programma, anche apprezzarli se si trova qualsiasi meccanismo robusto utilizzato nel programma. In questo modo, puoi renderli amichevoli e verranno sempre utilizzati per rivedere il loro codice. Quindi entrambi sono felici.

Addestrali: ultimo ma non meno importante, addestrare gli sviluppatori sulle vulnerabilità nel mondo reale. Dare loro formazione, coinvolgerli e incoraggiarli a rivedere i loro codici prima della produzione. Dite loro come si risparmia fatica e denaro. Se si dispone di uno strumento di scansione che supporta i plug-in per IDE, installarlo presso le loro macchine in modo che possano fare il corretto sviluppo e una revisione mano a mano.

Un’illustrazione di esempio:

Considera questo esempio (Owasp WebGoat Project):

String username = “”;

Password stringa = “”;

nome utente = s. getParser ().getRawParameter (NOME UTENTE);

password = s.getParser().getRawParameter(PASSWORD);

……………..

………..……

String query = ” SELEZIONA * DA user_system_data DOVE user_name = ‘”

+ nome utente + “‘e password = ‘” + password + “‘”;

ce.addElement(nuovo StringElement(query));

Gli input dell’utente vengono richiesti tramite getRawParameter e assegnati alle variabili “username” e “password”. Ancora una volta, vengono utilizzati direttamente nella query SQL senza alcuna convalida di input e vengono incorporati nella query dinamica. Qualsiasi utente malintenzionato può manomettere questa query per eseguire i propri codici SQL arbitrari. Quindi, se proviamo a trovare tutti i punti di ingresso nella base di codice (getRawParameter in questo caso), possiamo rilevare difetti di iniezione. Anche se cerchiamo query SQL utilizzate nel codice, se scopriamo che vengono utilizzate come query dinamiche, potrebbero essere un caso di una possibile iniezione SQL.

In rete: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf