È sicuro che un utente digiti un'espressione regolare come input di ricerca?

Vorrei confrontare le espressioni regolari fornite dall'utente per analizzare la 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 o del markdown della data (anche se la produzione sicura di html da markdown non attendibile ha i suoi rischi) e quindi rappresenta più spazio per lo sfruttamento, ma il principio di base è lo stesso: lo sfruttamento comporta la scoperta di effetti collaterali inattesi / compilazione / processo di abbinamento.

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 di codice.
Vale a dire, fa aumenta la superficie di attacco, ma non è irragionevole prendere la decisione misurata per accettare quel rischio relativamente minore.

Gli attacchi di tipo denial of service sono un po 'più complicati. Penso che la maggior parte delle librerie di espressioni regolari siano progettate tenendo conto delle prestazioni, ma non contano la mitigazione dell'input intenzionalmente lento tra i loro obiettivi principali di progettazione. L'opportunità di accettare le espressioni regolari fornite dall'utente dalla prospettiva DoS dipende più dalla libreria.
Ad esempio, la libreria regex .NET accetta un timeout che potrebbe essere usato per mitigare gli attacchi DoS.
RE2 garantisce un'esecuzione in tempo lineare alle dimensioni dell'input , che può essere accettabile se si sa che il proprio corpus di ricerca rientra in un limite di dimensioni ragionevoli.

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

La principale minaccia nell'accettare le espressioni regolari sarà nel motore di esecuzione delle espressioni regolari piuttosto che accettare la regex stessa. Mi aspetto che la minaccia sia molto, molto bassa in qualsiasi motore ben implementato. Il motore non dovrebbe avere bisogno di accedere a risorse di sistema privilegiate 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 si può fare dovrebbe essere minimo.

Nel complesso, tutte le regex sono progettate per cercare i modelli all'interno di un valore. Fintanto che viene rispettata la sicurezza corretta sui valori controllati, non c'è motivo per cui il motore stesso debba avere accesso a modificare i valori. Lo classificherei come abbastanza sicuro.

Detto questo, l'avrei anche fornito solo nelle situazioni in cui aveva senso ragionevole farlo. Il Regex è complesso, richiede potenzialmente molto tempo per essere eseguito e utilizzato in posti sbagliati potrebbe avere degli effetti indesiderati su un'applicazione al di fuori di un contesto di sicurezza, ma nel caso di utilizzo corretto sono estremamente potenti e di enorme valore. (Sono un architetto di software che rifiuta regolarmente centinaia di migliaia di righe di codice usando regex.)

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

Mentre si presume che questi motori siano abbastanza maturi, robusti e accuratamente testati, è accaduto in passato:

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

A memory corruption issue exists in WebKit's handling of regular expressions. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution.

Ma naturalmente, l'argomento di una libreria possibilmente difettosa vale per tutto - anche file JPEG forniti dall'utente .

L'altro aspetto, sebbene non inerentemente tecnico, sarebbe il caso (.+) che hai menzionato: il prodotto dovrebbe consentire il recupero arbitrario dei dati?

Il problema è che i motori regex "backtrack". Quando si esegue un'operazione di rettifica (ad es. + O *) nella regex, il motore regex proverà a farlo corrispondere il più possibile alla stringa di input. Se in seguito la partita fallisce, tornerà indietro e cercherà di abbinare la tua replica a una parte più piccola della stringa di input.

Le operazioni di ripetizione multiple possono portare a un backtracking annidato e questo può portare al tempo necessario per valutare la regex che esplode in modo massivo, specialmente se gli operatori di ripetizione sono nidificati.

link

No, ReDoS non richiede che l'autore dell'attacco realizzi risultati di ricerca innaturali.

L'idea di base di ReDoS è che si ha una sotto-espressione che può corrispondere in più modi e corrisponde quasi ovunque nella stringa cercata tranne la fine, e si itera la sottoespressione per ottenere un backtrack catastrofico. 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 utilizzare qualcosa come ([^q]|[^q][^q])+ (o costrutti più complessi con ad esempio lookaheads).

Dipende se questo è un problema - come hanno spiegato altre risposte, puoi solo limitare il tempo a disposizione del motore regex.

Risposta breve ... No. Indipendentemente dal fatto che si tratti di espressioni regolari o no, sono comunque dati forniti dall'utente e dovrebbe MAI essere considerato attendibile. La pratica standard consiste nel convalidare correttamente tutti i dati forniti dall'utente ... SEMPRE!

Se si desidera consentire l'uso della regex da parte dell'utente, l'espressione regolare dell'utente deve essere confrontata con una lista bianca di espressioni regolari consentite che si desidera rendere disponibili per lo script. In questo modo non usi mai direttamente la regex inviata dall'utente, e se non corrisponde a una regex nella whitelist, puoi uscire dallo script. Solo un modo sicuro per consentire regex come input dell'utente che posso pensare.