Il DoS basato su espressioni regolari (ReDoS) è un rischio crescente all'interno sicurezza delle applicazioni modernePoiché sempre più team si affidano alla convalida dell'input e alla corrispondenza dei modelli, un'espressione regolare mal progettata può introdurre vulnerabilità prestazionali che gli aggressori possono sfruttare per rallentare i servizi o causare interruzioni. Infatti, OWASP ReDoS viene descritto come un attacco denial of service che sfrutta il fatto che molte implementazioni di espressioni regolari possono diventare estremamente lente, a volte con tempi di esecuzione che crescono esponenzialmente con la dimensione dell'input.
Allo stesso tempo, gli attacchi ReDoS sono particolarmente pericolosi negli ambienti cloud-native e CI/CDambienti basati su ReDoS, dove una singola espressione regolare vulnerabile in un'API, un gateway o un flusso di autenticazione può avere un impatto sulla disponibilità su larga scala. Per questo motivo, i team dovrebbero considerare gli attacchi ReDoS come un rischio reale per la disponibilità, non solo come un caso limite di nicchia.
Ancora più importante, queste vulnerabilità spesso rimangono inosservate durante lo sviluppo, poiché gli approcci tradizionali si concentrano sulla sintassi piuttosto che sul comportamento di esecuzione. Di conseguenza, pattern di espressioni regolari inefficienti possono facilmente raggiungere l'ambiente di produzione senza generare alcun allarme.
È qui che entrano in gioco le moderne piattaforme di sicurezza delle applicazioni come Xygeni. Integrando i controlli di sicurezza direttamente nei flussi di lavoro di sviluppo, contribuiscono a individuare tempestivamente questi problemi e a dare priorità ai rischi effettivamente raggiungibili e significativi, anziché generare semplicemente ulteriore rumore di fondo.
Cos'è ReDoS (Regular Expression DoS)?
ReDoS (Regular Expression Denial of Service) è una vulnerabilità che si verifica quando un pattern di espressione regolare causa un eccessivo backtracking, con conseguente aumento esponenziale del tempo di esecuzione.
In parole semplici, un input dannoso può costringere la tua applicazione a impiegare un tempo eccessivo per valutare un'espressione regolare, bloccando il sistema e compromettendo le prestazioni.
Ad esempio, modelli con quantificatori annidati come:
(a+)+può diventare estremamente inefficiente nell'elaborazione di determinati input, soprattutto se creati intenzionalmente da un malintenzionato.
Sebbene possa sembrare un caso limite, è sorprendentemente comune nelle applicazioni reali, in particolare nella logica di validazione, nell'inserimento di dati nei moduli e nella gestione delle richieste API.
Come funzionano gli attacchi ReDoS
Un attacco ReDoS non necessita di tecniche di sfruttamento avanzate. Sfrutta invece il comportamento prevedibile dei motori di espressioni regolari.
Ritorno catastrofico
L'attaccante prende di mira un'espressione regolare che può assumere più percorsi corrispondenti. Quindi fornisce un input che costringe il motore a esplorare la maggior parte o tutti i percorsi.
Input creato dagli aggressori
Gli aggressori solitamente inviano:
- Lunghe stringhe con caratteri ripetuti.
- Input che corrispondono quasi, ma poi falliscono alla fine.
- Carichi utili che si concentrano sulla parte più ambigua dello schema.
Degrado delle prestazioni
Poiché ogni richiesta può consumare CPU, l'effetto si accumula rapidamente:
- Latenza più elevata tra gli endpoint.
- Esaurimento del pool di thread.
- Il ciclo degli eventi si blocca nei runtime a singolo thread.
Questi attacchi non richiedono exploit complessi. Al contrario, sfruttano l'inefficienza del pattern matching, il che li rende difficili da individuare se i vostri strumenti controllano solo la sintassi o le vulnerabilità CVE note.
Impatto reale delle vulnerabilità di ReDoS
ReDoS colpisce la "A" della triade CIA: la disponibilità. Può sembrare un problema di stabilità, non un incidente di sicurezza, finché non si collegano i punti.
Rallentamento dell'API
Un singolo endpoint che utilizza un'espressione regolare vulnerabile può causare un picco di utilizzo della CPU durante la convalida dell'input, l'instradamento delle richieste o i controlli di autenticazione.
Interruzione del servizio
Sotto carico, un hotspot ReDoS può causare il riavvio dei pod, compromettere l'autoscaling e innescare guasti a cascata.
Esaurimento delle risorse
ReDoS può consumare:
- CPU sui nodi dell'applicazione.
- Memoria dovuta allo stato di backtracking.
- Thread di lavoro che bloccano altre richieste.
Poiché ReDoS si concentra sulle prestazioni piuttosto che sull'esposizione dei dati, molti team ne sottovalutano l'impatto. Tuttavia, la disponibilità è un elemento fondamentale della sicurezza delle applicazioni e le interruzioni possono tradursi rapidamente in rischi per l'azienda.
I cambiamenti improvvisi rappresentano il vero problema di fiducia.
Quando gli sviluppatori affermano di non fidarsi di Autofix, spesso intendono una cosa ben precisa: temono che non causi problemi.
Questo problema di fiducia è particolarmente evidente negli interventi di recupero dalle dipendenze.
Un pacchetto vulnerabile potrebbe avere una versione patchata disponibile, ma ciò non significa che l'aggiornamento sia sicuro. La versione patchata potrebbe rimuovere un metodo utilizzato dalla tua applicazione, rinominare un'API, rendere più stringente un contratto di tipo o modificare il comportamento in modo tale da superare i test unitari ma causare regressioni in produzione. In molti team, il costo effettivo della risoluzione non è l'applicazione della patch, bensì l'analisi del raggio d'azione del problema.
Consideriamo un semplice esempio in Java. Un codice sorgente dipende da una libreria in cui un metodo comune esiste nella versione 1.x ma viene rimosso nella versione 2.x.
Attacchi ReDoS e incidenti di sicurezza nel mondo reale
ReDoS non è solo una vulnerabilità teorica. È stata sfruttata in applicazioni reali, colpendo librerie ampiamente utilizzate e sistemi di produzione.
Ecco alcuni esempi significativi che evidenziano l'impatto di modelli di espressioni regolari inefficienti:
Vulnerabilità ReDoS in Moment.js
Una delle vulnerabilità ReDoS più note ha colpito Moment.js, una libreria JavaScript per la gestione delle date ampiamente utilizzata.
- Un modello di espressione regolare mal progettato ha causato un backtracking eccessivo
- Gli aggressori potrebbero innescare un elevato utilizzo della CPU con input appositamente creati
- Le applicazioni che utilizzano Moment.js sono diventate vulnerabili agli attacchi denial-of-service.
Questo problema ha dimostrato come anche librerie considerate affidabili possano introdurre vulnerabilità legate alle prestazioni in migliaia di applicazioni.
Libreria di validazione per Node.js (validator.js)
Un altro esempio coinvolto validatore.jscomunemente utilizzato per la convalida dell'input.
- Alcune funzioni di validazione si basavano su espressioni regolari inefficienti
- Input dannosi potrebbero ritardare significativamente l'esecuzione
- Ciò ha interessato le API e i servizi di backend che si basano sulla convalida dell'input dell'utente.
Dato l'ampio utilizzo di validator.js, l'impatto si è esteso a numerose applicazioni e servizi.
Interruzione del servizio Cloudflare (errore basato su espressioni regolari)
Un incidente di alto profilo ha coinvolto Cloudflare, dove un pattern regex errato ha causato un'interruzione di servizio di grandi dimensioni.
- Un'espressione regolare implementata in produzione ha causato un utilizzo eccessivo della CPU.
- I sistemi sono diventati non responsivi a livello globale
- Ampie porzioni di Internet sono state temporaneamente interessate
Sebbene non si tratti di un attacco doloso, questo incidente dimostra chiaramente come le inefficienze delle espressioni regolari possano avere conseguenze concrete su larga scala.
Perché gli strumenti di sicurezza tradizionali non riescono a sfruttare ReDoS
Questa è la sezione di conversione perché spiega il divario che la maggior parte dei team percepisce: gli scanner funzionano, dashboards riempiono, e ReDoS riesce comunque a passare.
Gli strumenti statici si concentrano sulla sintassi
Molti scanner sono in grado di segnalare "pattern di espressioni regolari pericolosi", ma spesso non hanno la certezza che il pattern sia effettivamente sfruttabile nel contesto specifico.
Nessun contesto di esecuzione
ReDoS riguarda il comportamento a runtime. OWASP osserva che molte implementazioni di espressioni regolari possono raggiungere situazioni estreme e funzionare molto lentamente, a volte in modo esponenziale rispetto alla dimensione dell'input.
Se uno strumento non ragiona sulla forma dell'input, sulle condizioni di errore di corrispondenza o sui percorsi di esecuzione, non rileverà il rischio o vi sommergerà di falsi positivi.
Nessuna analisi di sfruttabilità
Un'espressione regolare può essere "teoricamente rischiosa" ma irraggiungibile nella pratica. Al contrario, un validatore "di poco conto" in un endpoint pubblico può rappresentare un incidente reale. Senza il giusto contesto, i team o ignorano gli avvisi o intervengono in modo eccessivo per correggerli.
Gli scanner tradizionali spesso non riescono a rilevare gli attacchi ReDoS perché non valutano il comportamento delle espressioni regolari in fase di esecuzione o in condizioni di input dannose. È qui che piattaforme come Xygeni fanno la differenza combinando l'analisi con valutazione del rischio contestuale, aiutando i team a capire se una debolezza è effettivamente raggiungibile e ha un impatto significativo.
Come individuare le vulnerabilità di ReDoS
È possibile rilevare gli attacchi ReDoS combinando rigore nella progettazione e test approfonditi. Inoltre, è consigliabile eseguire controlli continui, non solo durante una revisione della sicurezza.
Progettazione sicura delle espressioni regolari
Iniziate con schemi che riducano al minimo l'ambiguità. Evitate quantificatori annidati e alternative sovrapposte.
Fuzzing e test
Verifica i pattern delle espressioni regolari con:
- Input molto lunghi.
- Input quasi mancati che falliscono in un secondo momento.
- Token ripetuti progettati per innescare il backtracking.
Analisi statica
Utilizzare analisi che segnalino costrutti e modelli rischiosi noti allineati con CWE-1333.
Convalida in fase di esecuzione
Quando possibile, applica limiti di lunghezza all'input e timeout alla valutazione delle espressioni regolari. Linee guida di OWASP per la convalida degli inpute avverte esplicitamente riguardo a ReDoS e sottolinea l'importanza di definire la lunghezza minima e massima dell'input.
Le soluzioni AppSec avanzate come Xygeni vanno oltre il rilevamento dei modelli analisi del codice nel contesto del flusso di lavoro e aiutando i team a concentrarsi sui problemi che hanno maggiori probabilità di essere rilevanti in scenari reali, riducendo così i falsi positivi e accelerando la risoluzione.
Come prevenire gli attacchi ReDoS
La prevenzione è una combinazione di modelli più sicuri, input più sicuri e scelte più sicure in fase di esecuzione.
Evitare i quantificatori annidati
La ripetizione annidata spesso crea le peggiori esplosioni di backtracking.
Limita la dimensione dell'input
Questa è la misura di mitigazione più semplice e affidabile. Imposta limiti di lunghezza massimi per gli input che superano la convalida tramite espressioni regolari. OWASP sottolinea l'importanza dei limiti di lunghezza come elemento chiave per una convalida sicura degli input.
Utilizzare motori di espressioni regolari sicuri ove possibile
Quando è possibile scegliere il motore, è preferibile optare per uno progettato per evitare ritorni di fiamma catastrofici. RE2 di Google si posiziona come un'alternativa sicura ai motori di espressioni regolari con backtracking.
Convalida gli input con controlli a più livelli
Non affidarti a una singola espressione regolare per tutte le convalide. Combina:
- liste di caratteri consentiti,
- controlli rigorosi sulla lunghezza,
- e schemi più semplici per ciascun campo.
Prevenire gli attacchi ReDoS richiede pratiche di codifica sicure e validazione continua lungo tutto il ciclo di sviluppo, soprattutto con l'aumentare delle dimensioni delle applicazioni e delle dipendenze.
Come Xygeni aiuta a rilevare e prevenire gli attacchi ReDoS
Xygeni aiuta i team DevSecOps a rilevare e prevenire le vulnerabilità ReDoS combinando più livelli di analisi.
Le capacità chiave includono:
- Rilevamento di pattern regex vulnerabili durante lo sviluppo
- Analisi dei flussi di dati e dei percorsi di esecuzione
- Identificazione delle vulnerabilità sfruttabili, non solo di quelle teoriche.
- Integrazione in CI/CD pipelines per la scansione continua
- Linee guida pratiche per la risoluzione dei problemi, destinate agli sviluppatori.
Invece di sovraccaricare i team con avvisi, Xygeni dà priorità a vulnerabilità effettivamente raggiungibili e di impatto.
Ciò consente ai team di risolvere i problemi reali più rapidamente, senza rallentare lo sviluppo.
Migliori pratiche per i team DevSecOps
Sicurezza Maiusc-sinistra
Integra i controlli ReDoS nella stessa routine di revisione del codice e test unitari.
Scansione automatizzata
Eseguire controlli su ogni pull request Pertanto, il rischio delle espressioni regolari non attende le revisioni periodiche.
Monitorare le dipendenze
Le vulnerabilità delle espressioni regolari si presentano anche nelle dipendenze e nelle librerie di analisi dell'input, quindi è fondamentale mantenere un controllo rigoroso delle dipendenze.
Convalidare continuamente gli input
Applica limiti di lunghezza e regole di input ai margini, quindi convalida nuovamente all'interno dei servizi critici.
Integrando la sicurezza direttamente nei flussi di lavoro di sviluppo, i team possono prevenire vulnerabilità basate sulle prestazioni come ReDoS prima che raggiungano l'ambiente di produzione.
La prevenzione degli attacchi ReDoS inizia con una visibilità senza ombre.
Il ReDoS viene spesso sottovalutato, eppure può avere un impatto significativo sulle prestazioni e sulla disponibilità delle applicazioni. OWASP definisce il ReDoS come un rischio di negazione del servizio radicato in un comportamento estremo delle espressioni regolari in fase di esecuzione.
Ciò significa che non basta una semplice scansione. Servono contesto, definizione delle priorità e automazione.
Se tratti le espressioni regolari come codice che può fallire in presenza di input controllati da un attaccante, individuerai gli attacchi ReDoS prima e rilascerai sistemi più sicuri. Con Xygeni, i team possono ridurre il rumore, dare priorità al rischio reale e rafforzare i controlli di sicurezza delle applicazioni all'interno CI/CD flussi di lavoro.
Conclusione
Le vulnerabilità ReDoS sono facili da introdurre e difficili da rilevare senza il contesto adeguato.
Mentre gli strumenti tradizionali si concentrano sull'identificazione dei problemi, la sicurezza delle applicazioni moderna richiede la comprensione di quali vulnerabilità siano effettivamente rilevanti.
Pertanto, per rimanere competitivi, i team necessitano di visibilità, definizione delle priorità e automazione che collaborino lungo tutto il ciclo di sviluppo.
È qui che Xygeni fa la differenza. Concentrandosi sui rischi sfruttabili, aiuta i team a individuare i problemi in anticipo, a ridurre il rumore e a proteggere le applicazioni dallo sviluppo alla distribuzione.
In definitiva, oggi sviluppare software sicuro significa andare oltre la semplice scansione e adottare un approccio alla sicurezza contestuale e in tempo reale.
Inizia a creare applicazioni sicure e resilienti con Rilevamento in tempo reale e sicurezza contestuale.
Domande frequenti (FAQ)
Che cos'è un attacco ReDoS?
Un attacco ReDoS (Regular Expression Denial of Service) è un tipo di vulnerabilità in cui è possibile sfruttare pattern di espressioni regolari inefficienti per causare tempi di elaborazione eccessivi, con conseguente degrado delle prestazioni o arresto anomalo dell'applicazione.
Perché ReDoS è pericoloso nelle applicazioni moderne?
Gli attacchi ReDoS possono compromettere la disponibilità delle applicazioni consumando risorse della CPU e rallentando i servizi. Negli ambienti cloud-native, questo può rapidamente degenerare in problemi di prestazioni a livello di sistema.
Come possono gli sviluppatori prevenire le vulnerabilità ReDoS?
Gli sviluppatori possono prevenire gli attacchi ReDoS evitando modelli regex complessi, limitando le dimensioni dell'input, utilizzando motori regex sicuri e integrando controlli di sicurezza in CI/CD pipelines.
Gli strumenti di sicurezza tradizionali sono in grado di rilevare gli attacchi ReDoS?
La maggior parte degli strumenti tradizionali fatica a rilevare gli attacchi ReDoS perché non analizza il comportamento in fase di esecuzione o la vulnerabilità. Le soluzioni AppSec avanzate offrono una rilevazione più efficace valutando come il codice viene eseguito in scenari reali.
In che modo Xygeni aiuta a prevenire gli attacchi ReDoS?
Xygeni rileva modelli regex vulnerabili, analizza i percorsi di esecuzione e assegna priorità ai rischi sfruttabili. Si integra in CI/CD pipelinee fornisce indicazioni pratiche di bonifica agli sviluppatori.
L'autore
Co-fondatore e CTO
Fatima Said è specializzato in contenuti pensati per gli sviluppatori per AppSec, DevSecOps e software supply chain securityTrasforma segnali di sicurezza complessi in indicazioni chiare e fruibili che aiutano i team a stabilire le priorità più rapidamente, a ridurre il rumore e a rilasciare codice più sicuro.
