Quali sono le mitigazioni per tutte le vulnerabilità owasp top 10?

Ecco la descrizione dettagliata data di seguito che può essere presa in considerazione al fine di rilevare tutte le vulnerabilità che sono elencate nella OWASP Top 10 e anche per soddisfare l'intervistatore.

1. Prevenire gli attacchi di iniezione:
   1. Il modo più semplice per proteggere contro l'iniezione è quello di evitare l'accesso a interpreti esterni, quando possibile. Per molti comandi di shell e alcune chiamate di sistema, ci sono librerie specifiche del linguaggio che svolgono le stesse funzioni. L'utilizzo di tali librerie non coinvolge l'interprete della shell del sistema operativo, e quindi evita un gran numero di problemi con i comandi della shell.
   2. Un'altra forte protezione contro l'iniezione di comandi è assicurarsi che l'applicazione web venga eseguita solo con i privilegi di cui ha assolutamente bisogno per svolgere la sua funzione. Quindi non si dovrebbe eseguire il webserver come root o accedere a un database come DBADMIN, altrimenti un attaccante può abusare di questi privilegi amministrativi concessi all'applicazione web. Alcuni ambienti J2EE permettono l'uso della sandbox Java, che può impedire l'esecuzione di comandi di sistema.
2. Costruire una corretta autenticazione e gestione delle sessioni:
   1. Un uso attento e corretto di meccanismi di autenticazione e gestione delle sessioni personalizzati o off the shelf dovrebbe ridurre notevolmente la probabilità di un problema in quest'area. Definire e documentare la politica del vostro sito rispetto alla gestione sicura delle credenziali degli utenti è un buon primo passo. Assicurarsi che la propria implementazione applichi coerentemente questa politica è la chiave per avere un meccanismo di autenticazione e di gestione delle sessioni sicuro e robusto. Alcune aree critiche includono:
      1. Controllo della modifica delle password
      2. Uso delle password
      3. Rafforzamento delle password
      4. Conservazione delle password
      5. Protezione delle credenziali in transito
      6. Protezione dell'ID di sessione
      7. Liste di account
      8. Caching del browser
3. Prevenzione del cross-site scripting:
   1. Il modo migliore per proteggere un'applicazione web da attacchi XSS è assicurarsi che l'applicazione esegua la convalida di tutte le intestazioni, i cookie, le stringhe di query, i campi dei moduli e i campi nascosti (es.e., tutti i parametri) rispetto ad una rigorosa specifica di ciò che dovrebbe essere permesso. La validazione non dovrebbe tentare di identificare il contenuto attivo e rimuoverlo, filtrarlo o sterilizzarlo. Ci sono troppi tipi di contenuto attivo e troppi modi di codificarlo per aggirare i filtri per tale contenuto. Raccomandiamo fortemente una politica di sicurezza "positiva" che specifichi cosa è permesso. Le politiche "negative" o basate sulla firma d'attacco sono difficili da mantenere e probabilmente sono incomplete. La codifica dell'output fornito dall'utente può anche sconfiggere le vulnerabilità XSS impedendo che gli script inseriti siano trasmessi agli utenti in una forma eseguibile. Le applicazioni possono ottenere una protezione significativa dagli attacchi basati su javascript convertendo i seguenti caratteri in tutti gli output generati nella codifica appropriata delle entità HTML come < < > > (( )) #&\ / '"
4. Prevenire riferimenti insicuri a oggetti diretti:
   1. La migliore protezione è evitare di esporre agli utenti riferimenti diretti a oggetti usando un indice, una mappa di riferimento indiretta, o un altro metodo indiretto che sia facile da validare. Se si deve usare un riferimento diretto ad un oggetto, assicurarsi che l'utente sia autorizzato prima di usarlo.
   2. Stabilire un modo standard di riferirsi agli oggetti dell'applicazione è importante:
      1. Evitare di esporre agli utenti, quando possibile, i riferimenti a oggetti privati, come chiavi primarie o nomi di file
      2. Validare ampiamente qualsiasi riferimento a oggetti privati con un approccio "accept known good"
      3. Verificare l'autorizzazione a tutti gli oggetti referenziati
5. Guida base alla configurazione della sicurezza:
   1. Il primo passo è quello di creare una linea guida di hardening per la vostra particolare configurazione di web server e application server. Questa configurazione dovrebbe essere usata su tutti gli host che eseguono l'applicazione e anche nell'ambiente di sviluppo. Raccomandiamo di iniziare con qualsiasi guida esistente che potete trovare dal vostro fornitore o quelle disponibili dalle varie organizzazioni di sicurezza esistenti come OWASP, CERT e SANS e poi adattarle alle vostre particolari esigenze. La linea guida di hardening dovrebbe includere i seguenti argomenti:
      1. Configurare tutti i meccanismi di sicurezza
      2. Spegnere tutti i servizi inutilizzati
      3. Impostare ruoli, permessi, account, password
      4. Registrazione e avvisi
6. Proteggere i dati sensibili:
   1. Il modo più semplice per proteggersi dalle falle crittografiche è ridurre al minimo l'uso della crittografia e conservare solo le informazioni assolutamente necessarie. Per esempio, piuttosto che criptare i numeri delle carte di credito e memorizzarli, basta chiedere agli utenti di reinserire i numeri. Inoltre, invece di memorizzare le password criptate, usare una funzione a senso unico, come SHA-1, per fare l'hash delle password.
   2. Se si deve usare la crittografia, scegliere una libreria che è stata esposta al pubblico scrutinio e assicurarsi che non ci siano vulnerabilità aperte. Incapsulare le funzioni crittografiche utilizzate e rivedere attentamente il codice. Assicurarsi che i segreti, come chiavi, certificati e password, siano memorizzati in modo sicuro. Per rendere difficile ad un attaccante, il segreto principale dovrebbe essere diviso in almeno due posizioni e assemblato in fase di esecuzione. Tali posizioni potrebbero includere un file di configurazione, un server esterno, o all'interno del codice stesso.
7. Assicurare il controllo degli accessi a livello di funzione:
   1. Capire le regole
   2. Elementare tutte le risorse e le funzioni
   3. Elementare tutti gli utenti
8. Prevenire il CSRF:
   1. Prevenire il CSRF richiede l'inserimento di un token imprevedibile nel corpo o nell'URL di ogni richiesta HTTP. Tali token dovrebbero essere almeno unici per sessione utente, ma possono anche essere unici per richiesta.
   2. L'opzione preferita è quella di includere il token unico in un campo nascosto. Questo fa sì che il valore venga inviato nel corpo della richiesta HTTP, evitando la sua inclusione nell'URL, che è soggetto a esposizione.
   3. Il token unico può anche essere incluso nell'URL stesso, o in un parametro dell'URL. Tuttavia, tale posizionamento corre il rischio che l'URL sia esposto ad un attaccante, compromettendo così il token segreto.
9. Dove cercare le vulnerabilità sui componenti di terze parti conosciuti:
   1. Tenere aggiornate tutte le applicazioni e i componenti di terze parti
   2. Cercare le vulnerabilità in qualsiasi versione appropriata dei componenti su Exploit-db, vulndb, CVE, ecc.
   3. Update to other required versions as per the vulnerability mitigations and recommendations.
   4. Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component.
10. Redirect validation:
    1. Simply avoid using redirects and forwards.
    2. If used, don’t involve user parameters in calculating the destination. This can usually be done.
    3. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.

Hiren Patel (Pune, MH)