Diventa Autore per CoreTech | Scopri di più





L'importanza della convalida delle correzioni: lezioni da Google

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.

Le conseguenze della mancata convalida delle correzioni

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ù.

Perché le correzioni non sono efficaci?

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.

Sii più intelligente di Google: automatizza bene

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.


Articoli su Acunetix

Trovare le vulnerabilità dei siti web prima degli HackerL'importanza della convalida delle correzioni: lezioni da GoogleSDLC agile e sicuro - Best practiceIn che misura le aziende gestiscono la sicurezza delle applicazioni Web?Cross-Origin Resource Sharing (CORS) e intestazione Access-Control-Allow-OriginCosa sono i reindirizzamenti aperti?DevSecOps: come arrivarci da DevOpsIl bigino su SQL Injection per sviluppatoriSfruttare SSTI in ThymeleafSicurezza nginx: come proteggere la configurazione del serverRafforzamento del sistema Web in 5 semplici passaggiCos'è la sicurezza del sito Web - Come proteggere il tuo sito Web dall'hackingRapporto sulle vulnerabilità delle applicazioni Web Acunetix 2020Perché l'elenco delle directory è pericoloso?Cosa sono gli hack di Google?Cosa è l'attacco BEASTWeb Shells in Action - Rilevazione e prevenzione - parte 5Web Shells in Action - parte 4Mantenere le Web Shells sotto copertura - parte 3Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Debunking 5 miti sulla postura della sicurezza informaticaIniezioni di NoSQL e come evitarleConfigurazione passo passo di Acunetix con JenkinsCosa sono i riferimenti a oggetti diretti non sicuriAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallAcunetix rilascia Business Logic RecorderCome recuperare un sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle password comuni e come evitarleTutto quello che devi sapere sugli attacchi Man-in-the-MiddleChe cosa sono le iniezioni HTMLRed Teaming – 5 consigli su come farlo in modo sicuroTesta le tue competenze XSS utilizzando siti vulnerabiliPerché hacker malintenzionati hanno messo gli occhi sugli ospedaliPratiche di codifica sicura – I tre principi chiaveLa maledizione delle vecchie librerie JavaMutation XSS nella ricerca GoogleIgnorare SOP utilizzando la cache del browserCome e perché evitare reindirizzamenti e inoltri non convalidati?Dirottamento di sessione e altri attacchi di sessioneCome abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionVulnerabilità delle entità esterne XML in Internet ExplorerCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!