Diventa Autore per CoreTech | Scopri di più
23/10/20 CoreTech Blog
Zohar Shachar, un ricercatore di sicurezza israeliano, ha recentemente rivelato i dettagli di una taglia che ha ricevuto circa un anno fa da Google . Il problema di sicurezza che ha riscontrato era una vulnerabilità avanzata di cross-site scripting (XSS) in Google Maps.
C'era un dettaglio su questo caso che spiccava. Shachar ha effettivamente ricevuto due taglie per la stessa vulnerabilità. Dopo che Google ha assegnato la prima taglia, Shachar ha deciso di controllare la correzione e ha scoperto di poter aggirare il problema. Ha anche ammesso che questo non è l'unico caso del genere: è stato anche in grado di sfruttare una vulnerabilità di iniezione SMTP precedentemente risolta in GSuite .
Questo caso solleva una domanda importante: quante vulnerabilità pubblicamente accessibili non sono state effettivamente risolte? Mostra anche che anche i giganti delle applicazioni web più rinomati come Google commettono errori da principianti e dimenticano di testare le loro correzioni o non le testano abbastanza bene.
Non tutti sono fortunati come Google in questo caso: non tutte le vulnerabilità vengono trovate da un penetration tester responsabile come Shachar. La maggior parte dei cacciatori di taglie prenderebbe semplicemente la taglia e andrebbe avanti.
Questo è spesso il caso dei penetration tester manuali interni, in particolare quelli sovraccarichi di lavoro a causa del divario di competenze in materia di sicurezza informatica : semplicemente non hanno tempo per testare le soluzioni. È quindi assolutamente possibile che molte vulnerabilità rilevate siano ancora presenti ed è anche peggio perché l'azienda è sicura che non ci siano più.
Uno dei motivi per cui le correzioni sono inefficaci è l'approccio che è ancora abbastanza comune tra gli sviluppatori. Ci sono sviluppatori che non vedono le vulnerabilità come veri problemi perché i team di sicurezza e i team di sviluppatori lavorano spesso in silos, tranne nelle aziende che sono riuscite a spostarsi completamente a sinistra. I penetration tester possono essere percepiti dagli sviluppatori in una luce negativa, come persone che causano lavoro non necessario. E con un tale approccio, uno sviluppatore mirerà semplicemente a soddisfare la richiesta del penetration tester, senza pensare veramente a correggere la vulnerabilità. Ad esempio, filtreranno solo per la stringa utilizzata per sfruttare la vulnerabilità, ignorando altre potenziali stringhe che possono avere lo stesso effetto.
Un altro motivo è che non tutti i tipi di vulnerabilità sono facili da correggere. Mentre le SQL injection sono facili da eliminare e tutti i comuni linguaggi di programmazione back-end consentono di utilizzare query parametrizzate per eliminare tali vulnerabilità, le cose non sono così semplici, ad esempio, con lo scripting cross-site avanzato (come nel caso di Google Maps). Evitare XSS nel codice dell'applicazione può essere difficile e, in alcune situazioni, richiede molta attenzione da parte dello sviluppatore.
La mancanza di nuovi test, come nel caso di Google, peggiora ulteriormente la situazione perché gli sviluppatori non imparano dai propri errori. I test tardivi e le ripetizioni tardive sono altrettanto negativi. Immagina una situazione in cui lo sviluppatore A commette un errore e introduce una vulnerabilità. A causa dei test in fase di staging, è lo sviluppatore B che ha il compito di correggere la vulnerabilità diverse settimane dopo. Lo sviluppatore A non ha idea di cosa abbia sbagliato (e introdurrà la stessa vulnerabilità la prossima volta in un codice simile).
Se ciò non fosse già abbastanza grave, pensiamo alla ripetizione manuale tardiva. Sarà lo sviluppatore C che avrà il compito di correggere la correzione introdotta dallo sviluppatore B. Pertanto, lo sviluppatore B non ha idea del bug e probabilmente commetterà lo stesso errore in una correzione futura. Di conseguenza, due dei tre sviluppatori pensano di aver fatto tutto bene e continueranno a introdurre le stesse vulnerabilità.
Questo non è sicuramente un buon modo per creare applicazioni web sicure.
Si potrebbe pensare che la scansione delle vulnerabilità sia il modo migliore per garantire che tutte le correzioni vengano automaticamente ritestate, ma anche questo non è ovvio. La maggior parte degli scanner di vulnerabilità web sono strumenti manuali. Li punti all'applicazione web, esegui la scansione, salvi il report, lo invii agli sviluppatori. Non esiste un processo per assicurarsi che le vulnerabilità vengano nuovamente testate.
Tuttavia, gli scanner avanzati di vulnerabilità di classe aziendale dispongono di funzionalità di gestione delle vulnerabilità integrate. Ciò significa che una volta identificata una vulnerabilità, puoi creare automaticamente ticket, anche in tracker di problemi esterni come Jira, quindi, dopo che il problema è stato chiuso dallo sviluppatore, puoi ripetere il test della vulnerabilità per vedere se la correzione è stata efficace. Con soluzioni di classe enterprise, puoi persino iniziare a ripetere il test automaticamente una volta risolto il problema in Jira.
Ancora meglio, i moderni scanner di vulnerabilità funzionano all'interno di pipeline CI / CD. Ciò significa che lo sviluppatore originale non può introdurre affatto una vulnerabilità perché la compilazione fallisce se viene rilevata una vulnerabilità. Devono affrontare immediatamente ciò che hanno fatto di sbagliato e quindi rieseguire la build, quindi ritestando automaticamente la correzione e imparando dai propri errori. Non esiste una situazione in cui siano coinvolti tre diversi sviluppatori e il problema persiste per mesi.
Ovviamente, gli scanner di vulnerabilità non saranno in grado di gestire ogni singola vulnerabilità e ci saranno casi in cui nuove vulnerabilità verranno scoperte da tester manuali. Tuttavia, la maggior parte dei problemi derivanti dalla mancanza di ripetizione del test verrà risolta se si introduce un'automazione efficiente e si sposta la sicurezza il più possibile.