Quando le espressioni regolari si rivoltano contro le prestazioni
Una singola riga di espressione regolare in C# può mettere in ginocchio un'API di produzione. Pattern scritti male innescano un backtracking catastrofico, bruciando cicli di CPU e bloccando i thread. Questo è il classico Espressione regolare Denial of Service (ReDoS), un vettore di attacco subdolo ma pericoloso nascosto nel codice.
⚠️Esempio non sicuro, solo a scopo didattico. Non utilizzare in produzione.
Questa espressione regolare per C# presenta quantificatori annidati che causano un backtracking esponenziale. Una stringa lunga e dannosa può bloccare un endpoint o un microservizio.
Versione sicura:
Nota didattica: Utilizzare sempre i timeout (OpzioniRegex + Intervallo di tempo) e semplificare i gruppi annidati. In regex c#, la convalida delle prestazioni è un requisito di sicurezza, non un'ottimizzazione.
Perché i modelli Regex di C# diventano vulnerabili
Quantificatori ambigui (.*, .+, o (a+)+) e la ripetizione illimitata rendono le espressioni regolari un obiettivo DoS comune.
Quando questi compaiono in contesti guidati dall'utente, come la convalida dell'input o l'analisi dei log, un singolo payload creato appositamente può monopolizzare la CPU.
⚠️Esempio non sicuro, solo a scopo didattico. Non utilizzare in produzione.
Versione sicura:
Nota didattica: Evitare ripetizioni ambigue, limitare le dimensioni dell'input ed eseguire sempre il benchmark delle prestazioni delle espressioni regolari sotto carico. Frammento funzionale, applica timeout e lunghezza massima degli input come protezioni in produzione.
Impatto reale nelle API e CI/CD Flussi di lavoro
Le espressioni regolari non sicure per C# non si limitano ai moduli di convalida. Gli sviluppatori incorporano modelli nei filtri di log, nei matcher di webhook e nelle scansioni automatiche. CI/CD, un modello non sicuro può bloccare l'intero pipeline.
⚠️Esempio non sicuro, solo a scopo didattico. Non utilizzare in produzione.
Non elaborare mai espressioni regolari fornite dall'utente senza convalida o controllo del timeout.
Versione sicura:
Nota didattica: Convalida l'input regex esterno prima dell'esecuzione. Aggiungi controlli di lunghezza espliciti e applica i timeout in pipelines.
Pratiche sicure per prevenire DoS in C# Regex
La prevenzione ReDoS in regex c# dovrebbe essere integrata nel tuo sviluppo e Flusso di lavoro DevSecOps. Ecco come renderlo sicuro per impostazione predefinita:
Best Practices
- Imposta sempre i timeout su tutte le valutazioni regex.
- Evitare schemi catastrofici, nessun quantificatore annidato o gruppo ambiguo.
- Limita la dimensione dell'input prima di passare all'espressione regolare.
- Precompilare modelli attendibili con OpzioniRegex.Compiled.
- Sanificare le espressioni fornite dall'utente oppure inserisci nella whitelist i modelli consentiti.
Mini checklist preventiva
- Esamina ogni espressione regolare per l'utilizzo in C# nella tua base di codice.
- APPLICA Intervallo di tempo timeout in modo coerente.
- Limita le lunghezze di input sugli input API e CI.
- Testare le prestazioni delle espressioni regolari prima del rilascio.
- Automatizza le espressioni regolari statiche scansione in CI/CD.
Nota didattica: Trattate i pattern regex come codice non attendibile. Meritano la stessa attenzione riservata all'esecuzione di SQL o di comandi.
Come Xygeni rileva l'utilizzo rischioso delle espressioni regolari C#
Xygeni Code Security rileva automaticamente i modelli regex C# non sicuri durante l'analisi statica. Identifica backtracking catastrofici, timeout mancanti e modelli che potrebbero bloccare i servizi. In CI/CD, Xygeni funge da Porta DevSecOps, bloccando le espressioni regolari non sicure per C# prima che vengano unite o distribuite.
Nota didattica: L'integrazione di Xygeni garantisce una gestione sicura delle espressioni regolari in tutte le build e in tutti gli ambienti, prevenendo regressioni ed esposizioni DoS prima della distribuzione.
La tua espressione regolare è potente, assicurati che non venga trasformata in un'arma
Le vulnerabilità ReDoS trasformano le espressioni regolari C# apparentemente innocue in un'arma di negazione del servizio. Le espressioni regolari non sicure per i modelli C# sono una svista comune, finché non bloccano la produzione o non si rompono CI/CD.
Rendi la sicurezza delle espressioni regolari parte integrante della tua igiene di codifica:
- Utilizzare sempre i timeout.
- Evitare quantificatori annidati.
- Limita l'input dell'utente.
- Automatizza i controlli utilizzando Xygeni Code Security.
Le espressioni regolari saranno sempre potenti, ma con una progettazione attenta, i tuoi modelli C# di espressioni regolari non diventeranno il tuo prossimo report di incidente.
