Qual è il OWASP Top 10 Vulnerabilities list?
Pubblicato per la prima volta nel 2004 dal progetto Open Web Application Security, l’ormai famoso elenco delle vulnerabilità OWASP Top 10 (incluso in fondo all’articolo) è probabilmente il più vicino che la comunità di sviluppo abbia mai raggiunto una serie di comandamenti su come mantenere sicuri i propri prodotti.,
Questa lista rappresenta le minacce più rilevanti per la sicurezza del software oggi secondo OWASP, al fronte-smacking di molti che si chiedono come SQL iniezioni sono ancora una tale preoccupazione dopo tutti questi anni. Essi giudice vulnerabilità tipi, in base a quattro criteri:
- facilità di sfruttabilità
- prevalenze
- funziona
- l’impatto di business
è Interessante notare che, OWASP afferma che in realtà non fattore nella loro equazione la probabilità che gli hacker cercheranno di sfruttare una certa vulnerabilità.,
Quando è iniziato, gli scrittori hanno deciso che il modo migliore per coprire la maggior parte del terreno era quello di mettere vulnerabilità simili che credevano essere le più preoccupanti nei raggruppamenti. Hanno riconosciuto che mancando le statistiche corrette ci potrebbe sempre essere una domanda su quali vulnerabilità erano necessariamente le principali preoccupazioni, soprattutto perché questo può essere un domande soggettive secondo il modello di minaccia di ogni organizzazione.
Tuttavia, dopo molto dibattito, hanno offerto la loro lista di ciò che credevano di affrontare il più ampio insieme di organizzazioni, anche se non in particolare ordine.,
Con il tempo, l’elenco delle vulnerabilità OWASP Top 10 è stato adottato come standard per le migliori pratiche e requisiti da numerose organizzazioni, stabilendo uno standard in un certo senso per lo sviluppo. Un noto adottante della lista è gli standard di elaborazione dei pagamenti di PCI-DSS.
Sfortunatamente, poiché l’elenco delle vulnerabilità Top 10 di OWASP ha raggiunto un pubblico più ampio, le sue reali intenzioni come guida sono state male interpretate, danneggiando gli sviluppatori invece di aiutare. Quindi, come dovremmo capire lo scopo di questo elenco e in realtà incoraggiare gli sviluppatori a codificare in modo più sicuro?,
Comprensione degli aggiornamenti all’elenco 2017
Negli anni successivi, hanno aggiornato e riordinato le voci, aggiungendo alcuni nuovi tipi di vulnerabilità man mano che diventano rilevanti, anche se altri sono stati eliminati dall’elenco. Nuove versioni sono state rilasciate nel 2010, 2013 e 2017. La nuova lista è stata assemblata dopo un lungo e arduo studio che ha esaminato più di 50.000 applicazioni e analizzato circa 2,3 milioni di vulnerabilità.,
I seguaci regolari della lista avranno notato che insieme ad alcuni cambiamenti nell’ordine — nonostante il fatto che gli attacchi di iniezione rimangano in cima — ci sono alcuni nuovi arrivati alla versione aggiornata 2017 della famiglia di vulnerabilità OWASP Top 10.
Battere la concorrenza per farsi strada sul campo dando il via a reindirizzamenti e inoltri non convalidati è il problema delle API non protette., La sua inclusione nell’elenco al numero A10 è probabilmente il risultato del fatto che gli sviluppatori sono semplicemente molto più dipendenti dalle API di quanto non fossero abituati, interagendo con molti più componenti e prodotti esterni rispetto a prima. Entrare nello spot A7 è una protezione dagli attacchi insufficiente, che colpisce gli sviluppatori per non essere abbastanza completi nell’aggiungere protezioni per rilevare, registrare e, naturalmente, rispondere ai tentativi di danneggiare i loro prodotti.,
L’altro cambiamento importante qui nella versione 2017 è la combinazione dei riferimenti agli oggetti diretti insicuri di A4 e del controllo degli accessi a livello di funzione mancante A7, creando una vulnerabilità di controllo degli accessi unificata e evidenziando la necessità di stabilire correttamente i controlli per chi può e non può accedere agli account e ai dati.,
Fraintendendo l’elenco delle 10 vulnerabilità di OWASP
Una forza per il bene, questa lista si è purtroppo trasformata in uno strumento per svergognare gli sviluppatori che non riescono a seguire i suoi insegnamenti, usato come un club per rimproverarli per non essere perfetti quando si tratta di sicurezza. Questo approccio è controproducente e manca la missione di OWASP di incoraggiare e dotare gli sviluppatori di codice in modo più sicuro. Inoltre, non riesce a riconoscere le realizzazioni dei punteggi degli sviluppatori che stanno spingendo fuori enormi quantità di nuovo software ad un tasso mai visto prima.,
In una recente intervista, il presidente di OWASP Martin Knobloch ha espresso il suo disappunto per l’utilizzo della lista come una sorta di lista di controllo per una corsa finale prima di un rilascio, che serve più come meccanismo di convalida che come guida.
Come qualcuno che crede fortemente in un approccio shift-left alla sicurezza, non sorprende che sia in schiacciante accordo con la frustrazione di Knobloch di quanti hanno preso la lista OWASP Top 10 come strumento di FUD, e non l’insieme di principi guida che doveva essere.,
Sfidando approcci di settore per la sicurezza
Strategie di sicurezza organizzativa che dipendono aspettarsi fallimento dagli elementi umani nel modo in cui proteggono il software a favore di strumenti lucidi sono destinati a fallire.
Negli ultimi anni la messaggistica di troppi fornitori, specialmente nel lato della rete, è stata che “il perimetro è morto” e che le aziende hanno bisogno di cercare sicurezza in profondità per trovare i cattivi che sono già all’interno della loro rete., Troppi titoli alle conferenze hanno cercato di convincere i CISO che squadre di hacker d’élite stanno sparando per loro con exploit 0-day rarefatti che li lasceranno indifesi a meno che non acquistino il loro prodotto che in qualche modo li renderà inespugnabili a questi attacchi altrimenti inarrestabili.
Questa visione sullo stato della sicurezza è inutilmente fatalistica, grondante di hype di marketing, e manca alcuni dei concetti di base di come i professionisti della sicurezza dovrebbero pensare al rischio.,
Un approccio globale alla sicurezza non dovrebbe predicare la rimozione degli sviluppatori umani dal processo, solo per introdurre gli strumenti di sicurezza di un fornitore da correggere dopo che hanno terminato il loro lavoro. Questo presuppone che gli sviluppatori non possono essere attendibili, è offensivo, e non fa nulla per rendere il vostro team più forte quando si tratta di sicurezza e gestione del rischio.
Qual è la lista delle vulnerabilità OWASP Top 10 e non
Un paio di volte all’anno c’è il post sul blog obbligatorio che chiede come sia possibile che nel 2017 stiamo ancora parlando di attacchi a livello di script kiddie., Probabilmente ne ho scritti alcuni io stesso, per i quali mi scuso.
Il OWASP Top 10 non è impostato per risolvere ogni attacco nel libro, ma per aiutare i team a evitare gli errori più comuni che hanno molte più probabilità di ottenere le loro applicazioni violate. Un attaccante determinato può trovare molte strade per violare il loro obiettivo. Tuttavia, gli avvisi di gestione del rischio intelligente non si concentrano sulla minoranza dei casi, ma cercano invece di affrontare le questioni che devono affrontare il pubblico più ampio.,
Per trarre dai concetti di campo di sicurezza fisica, il risk manager medio dovrebbe essere molto più preoccupato per il suo cliente di entrare in un incidente sulla strada rispetto ai ninja addestrati dal SEAL Team 6 che arrivano attraverso le finestre, guidati da AI (e blockchain).
La sicurezza reale consiste nel formare le persone su come lavorare in modo sicuro e fornire loro le tecnologie, le conoscenze e i processi per rendere più facile la loro sicurezza., Mentre è sempre importante eseguire i controlli di sicurezza QA e finali prima di un rilascio, la sicurezza deve iniziare nelle prime fasi del funzionamento del team, eseguendo tutto il processo di sviluppo del prodotto. Gli errori accadranno, ma è molto più conveniente e decisamente più intelligente per cercare di evitare il maggior numero possibile di problemi, in primo luogo.
Per molti sviluppatori, l’obiettivo di guida si concentra su come far funzionare il prodotto, concentrandosi meno sul fatto che sia sicuro o meno. Non è colpa loro.,
Durante la loro formazione, hanno imparato che se producono un prodotto con una quantità minima di bug, hanno ottenuto un A. La sicurezza sarebbe comunque gestita da un altro dipartimento. Invece, i manager devono cogliere l’occasione per mostrare loro un modo migliore di lavorare che include considerare come codificano e i componenti con cui stanno lavorando hanno un impatto sulla sicurezza del loro prodotto.,
OTTENERE 451 RESEARCH REPORTON di FISSAGGIO OPEN SOURCE SOFTWARE Free Download
misure Pratiche Per migliorare le procedure di Sicurezza
Una trappola comune che è venuto fuori dei giorni di sviluppo a cascata aspettare fino alla fine del ciclo di sviluppo per eseguire controlli di sicurezza, in cui gli sviluppatori ricevono una lista di vulnerabilità per risolvere, ritardando il rilascio e il crescente attrito tra di loro e il team di sicurezza.,
Nella speranza di ingrassare gli ingranaggi e tenere il passo con la velocità di DevOps, le organizzazioni sono alla ricerca di nuovi modi per proteggere il loro codice fin dall’inizio e mantenere l’armonia tra i loro reparti.
Un metodo sempre più popolare per portare la sicurezza nelle fasi precedenti dello sviluppo del prodotto è in team di impollinazione incrociata con una miscela di sviluppatori e addetti alla sicurezza, consentendo a ciascuna parte di dare input e imparare gli uni dagli altri., Questa può essere un’eccellente opportunità per gli esperti di sicurezza di far apparire molti dei problemi che l’OWASP Top 10 tenta di affrontare in un ambiente meno conflittuale, in una fase che potrebbe effettivamente avere un impatto.
Quando si tratta di strumenti che possono contribuire a promuovere una migliore implementazione della sicurezza, dobbiamo pensare non solo a come la tecnologia può catturare i nostri errori o violazioni dopo il fatto, ma aiutarci a lavorare in modo più intelligente e sicuro fin dalle prime fasi., Questa prospettiva è parte integrante della mentalità shift-left, alla ricerca di opportunità per affrontare i problemi prima che diventino problemi costosi.
Integrare le tecnologie per aumentare le capacità degli sviluppatori
Un chiaro esempio di come le tecnologie per lo spostamento a sinistra possono aiutare gli sviluppatori a utilizzare OWASP Top 10 viene fornito con la voce numero 9 che mette in guardia contro l’utilizzo di componenti con vulnerabilità note. Uno dei problemi più comuni che sorgono in questo spazio è nel guadagnare visibilità su ciò che è nei componenti open source che hanno aggiunto al loro prodotto.,
Gli sviluppatori si rivolgono quasi sempre a componenti open source per aiutarli a costruire il loro prodotto più velocemente e in modo più efficiente, aggiungendo potenti funzionalità senza la necessità di scrivere il nuovo codice da soli.
Nella maggior parte dei casi, è improbabile che verifichino se il componente presenta vulnerabilità note prima di aggiungerlo al proprio prodotto. Anche se eseguono un controllo superficiale per vedere se ha problemi specifici, è improbabile che siano a conoscenza di eventuali problemi nelle dipendenze del componente.,
Tuttavia, se stanno usando uno strumento di analisi della composizione del software, possono effettivamente ricevere informazioni utili sul fatto che un componente open source abbia vulnerabilità note associate ad esso durante il ciclo di vita dello sviluppo del software (SDLC), risparmiando loro tempo che altrimenti potrebbe essere speso per strappare e sostituire il componente dopo un controllo da parte del team di sicurezza in seguito lungo la linea prima del rilascio dopo che è stato,
Sii un abilitatore della sicurezza all’interno della tua organizzazione
In base alla mia lettura dei Top 10 di OWASP e dei commenti di Knobloch, l’elenco dovrebbe essere preso come uno strumento per consentire ai team di includere la sicurezza nel loro processo di pensiero su come codificano, configurano e spediscono i loro prodotti.
I team di sicurezza che non si impegnano con i loro sviluppatori, facendo lo sforzo di capire come possono consentire loro di avere la sicurezza essere un elemento intrinseco del loro flusso di lavoro, si troveranno rapidamente messi da parte.,
Se vuoi rimanere rilevante, diventa un abilitatore e usa l’elenco OWASP Top 10 come un modo per avviare conversazioni, non per minacciare. Alla fine, si potrebbe scoprire che si cattura più (O) VESPE con miele di aceto.
L’elenco ufficiale delle 10 vulnerabilità OWASP
A1. Injection-I difetti di iniezione, come SQL, NoSQL, OS e LDAP injection, si verificano quando i dati non attendibili vengono inviati a un interprete come parte di un comando o di una query. I dati ostili dell’attaccante possono ingannare l’interprete nell’esecuzione di comandi non intenzionali o nell’accesso ai dati senza un’adeguata autorizzazione.
A2., Autenticazione interrotta-Le funzioni dell’applicazione relative all’autenticazione e alla gestione delle sessioni sono spesso implementate in modo errato, consentendo agli aggressori di compromettere password, chiavi o token di sessione o di sfruttare altri difetti di implementazione per assumere temporaneamente o permanentemente l’identità di altri utenti.
A3. Esposizione ai dati sensibili: molte applicazioni Web e API non proteggono adeguatamente i dati sensibili, ad esempio finanziari, sanitari e PII. Gli aggressori possono rubare o modificare tali dati debolmente protetti per condurre frodi con carta di credito, furto di identità o altri reati., I dati sensibili possono essere compromessi senza protezione aggiuntiva, come la crittografia a riposo o in transito, e richiede precauzioni speciali quando scambiati con il browser.
A4. XML External Entities (XXE) – Molti processori XML meno recenti o mal configurati valutano i riferimenti di entità esterne all’interno dei documenti XML. Le entità esterne possono essere utilizzate per divulgare i file interni utilizzando il gestore URI di file, le condivisioni di file interne, la scansione delle porte interne, l’esecuzione di codice remoto e gli attacchi denial of service.
A5.,Controlli di accesso interrotti-Le restrizioni su ciò che gli utenti autenticati sono autorizzati a fare spesso non vengono applicate correttamente. Gli aggressori possono sfruttare questi difetti per accedere a funzionalità e/o dati non autorizzati, accedere agli account di altri utenti, visualizzare file sensibili, modificare i dati di altri utenti, modificare i diritti di accesso, ecc.
A6. Sicurezza errata configurazione-Sicurezza errata configurazione è il problema più comunemente visto., Questo è comunemente il risultato di configurazioni predefinite non sicure, configurazioni incomplete o ad hoc, archiviazione cloud aperta, intestazioni HTTP mal configurate e messaggi di errore dettagliati contenenti informazioni sensibili. Non solo tutti i sistemi operativi, i framework, le librerie e le applicazioni devono essere configurati in modo sicuro, ma devono essere patchati/aggiornati in modo tempestivo.
A7.,Cross Site Scripting (XXS)-XSS difetti si verificano ogni volta che un’applicazione include dati non attendibili in una nuova pagina web senza una corretta convalida o fuga, o aggiorna una pagina web esistente con i dati forniti dall’utente utilizzando un’API del browser in grado di creare HTML o JavaScript. XSS consente agli aggressori di eseguire script nel browser della vittima che può dirottare le sessioni utente, deturpare i siti web, o reindirizzare l’utente a siti dannosi.
A8. Deserializzazione insicura-La deserializzazione insicura spesso porta all’esecuzione di codice remoto., Anche se i difetti di deserializzazione non comportano l’esecuzione di codice remoto, possono essere utilizzati per eseguire attacchi, inclusi attacchi di replay, attacchi di iniezione e attacchi di escalation dei privilegi.
A9. Utilizzo di componenti con vulnerabilità note: i componenti, come librerie, framework e altri moduli software, vengono eseguiti con gli stessi privilegi dell’applicazione. Se viene sfruttato un componente vulnerabile, tale attacco può facilitare gravi perdite di dati o acquisizione del server., Le applicazioni e le API che utilizzano componenti con vulnerabilità note possono compromettere le difese delle applicazioni e consentire vari attacchi e impatti.
A10. Registrazione insufficiente& Monitoraggio: la registrazione e il monitoraggio insufficienti, insieme all’integrazione mancante o inefficace con la risposta agli incidenti, consentono agli aggressori di attaccare ulteriormente i sistemi, mantenere la persistenza, ruotare su più sistemi e manomettere, estrarre o distruggere i dati., La maggior parte degli studi sulle violazioni mostrano che il tempo per rilevare una violazione è di oltre 200 giorni, in genere rilevato da parti esterne piuttosto che da processi o monitoraggi interni.