Confronterei l'accettazione di espressioni regolari fornite dall'utente con l'analisi della maggior parte dei tipi di input utente strutturato, come stringhe di data o markdown, in termini di rischio di esecuzione del codice. Le espressioni regolari sono molto più complesse delle stringhe di data o del markdown (sebbene produrre in modo sicuro html da un markdown non attendibile abbia i suoi rischi) e quindi rappresenta più spazio per lo sfruttamento, ma il principio di base è lo stesso: lo sfruttamento implica la ricerca di effetti collaterali inaspettati dell'analisi / processo di compilazione / corrispondenza.

La maggior parte delle librerie di espressioni regolari sono mature e fanno parte della libreria standard in molte lingue, il che è un indicatore abbastanza buono (ma non certo) che è privo di problemi importanti che portano all'esecuzione del codice.
Questo è per dire, aumenta la superficie di attacco, ma non è irragionevole prendere la decisione misurata di accettare quel rischio relativamente minore.

Gli attacchi Denial of Service sono un po 'più complicati. Penso che la maggior parte delle librerie di espressioni regolari siano progettate pensando alle prestazioni, ma non considerano la mitigazione dell'input intenzionalmente lento tra i loro obiettivi di progettazione principali. L'opportunità di accettare espressioni regolari fornite dall'utente dal punto di vista DoS dipende maggiormente dalla libreria.
Ad esempio, la libreria regex .NET accetta un timeout che potrebbe essere utilizzato per mitigare gli attacchi DoS.
RE2 garantisce l'esecuzione in un tempo lineare rispetto alla dimensione dell'input che può essere accettabile se sai che il tuo corpus di ricerca rientra in un limite di dimensione ragionevole.

In situazioni in cui la disponibilità è assolutamente critica o stai cercando di ridurre al minimo la superficie di attacco il più possibile, ha senso evitare di accettare espressioni regolari dell'utente, ma penso che sia una pratica difendibile.

La principale minaccia nell'accettare espressioni regolari sarà nel tuo motore di esecuzione regex piuttosto che accettare l'espressione regolare stessa. Mi aspetto che la minaccia sia molto, molto bassa in qualsiasi motore ben implementato. Il motore non dovrebbe aver bisogno di accedere a nessuna risorsa di sistema privilegiata e dovrebbe solo eseguire la logica sull'input fornito direttamente al motore. Ciò significa che anche se qualcuno trova un exploit nell'interprete, il danno che può essere fatto dovrebbe essere minimo.

Nel complesso, tutte le espressioni regolari è progettato per fare è cercare modelli all'interno di un valore. Finché viene seguita una protezione adeguata sui valori rispetto a cui si effettua il controllo, non c'è motivo per cui il motore stesso debba avere accesso per modificare i valori. Lo classificherei come generalmente abbastanza sicuro.

Detto questo, lo fornirei anche solo in situazioni in cui ha senso farlo. Regex è complesso, potenzialmente richiede tempo per essere eseguito e utilizzato nei posti sbagliati potrebbe avere alcuni impatti indesiderati su un'applicazione al di fuori di un contesto di sicurezza, ma nel giusto caso d'uso sono estremamente potenti e immensamente preziosi. (Sono un architetto di software che refactoring centinaia di migliaia di righe di codice regolarmente utilizzando regex.)

Come hanno sottolineato le altre risposte, il vettore di attacco sarebbe molto probabilmente il motore regex.

Anche se si presume che questi motori siano abbastanza maturi, robusti e accuratamente testati, è successo nel passato:

CVE-2010-1792 Esecuzione di codice arbitrario in Apple Safari e iOS. Citazione dalle note sulla patch:

Esiste un problema di danneggiamento della memoria nella gestione delle espressioni regolari da parte di WebKit. Visitare un sito web pericoloso può portare alla chiusura inaspettata dell'applicazione o all'esecuzione di codice arbitrario.

Ma ovviamente, l'argomento di una libreria potenzialmente difettosa vale per tutto, anche fornito dall'utente File JPEG.

L'altro aspetto, anche se non intrinsecamente tecnico, sarebbe il caso (. +) che hai citato: il prodotto dovrebbe consentire il recupero arbitrario dei dati?

Il problema è che i motori regex "tornano indietro". Quando hai un'operazione di regex (es. + O *) nella tua regex, il motore di regex proverà a confrontarla con la maggior parte possibile della stringa di input. Se la corrispondenza in seguito fallisce, tornerà indietro e proverà ad abbinare la tua ripetizione a una parte più piccola della stringa di input.

Operazioni di ripetizioni multiple possono portare a un backtracking annidato e questo può portare al tempo di valutare l'espressione regolare che soffia in modo massiccio, soprattutto se gli operatori di ripetizione sono annidati.

https://www.regular-expressions.info/catastrophic.html

No, ReDoS non richiede che l'attaccante crei risultati di ricerca innaturali.

L'idea di base di ReDoS è che hai una sottoespressione che può corrispondere in più modi e corrispondere quasi ovunque nel campo di ricerca stringa tranne la fine, e si itera quella sottoespressione per ottenere un backtracking catastrofico. Quindi, ad esempio, se la descrizione del tuo negozio è Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. , puoi semplicemente usare qualcosa come ([^ q] | [^ q] [^ q]) + (o costrutti più complessi con ad esempio lookaheads).

Se questo è un problema dipende - come altre risposte hanno spiegato, puoi semplicemente limitare il tempo a disposizione del motore regex.

Risposta breve ... No. Indipendentemente dal fatto che si tratti di una regex o meno, si tratta comunque di dati forniti dall'utente e non dovrebbero MAI essere attendibili. La pratica standard è convalidare correttamente tutti i dati forniti dall'utente ... SEMPRE!”

Se desideri consentire l'uso di regex dall'utente, allora l'espressione regolare dell'utente deve essere confrontata con una lista bianca delle espressioni regolari consentite che desideri rendere disponibile per lo script. In questo modo non utilizzi mai direttamente la regex inviata dall'utente e, se non corrisponde a una regex nella whitelist, puoi uscire dallo script. L'unico modo sicuro per consentire regex come input dell'utente a cui posso pensare.