Oltre ad avere una lunghezza di input eccessiva, esiste un modo per eseguire un exploit con un'espressione regolare (supponendo che la lingua / piattaforma sottostante sia sicura)?
In pratica mi chiedevo se la seguente soluzione in StackOverflow per l'utilizzo di query simili a come in MongoDB sarebbe sicuro in particolare:
var query = { Zip: new RegExp('^' + zipCode) };
collection.find(query);
So che possono inserire query non valide ma non pertinenti.
Se il buffer contenente l'espressione regolare è di lunghezza sufficiente e il parser di espressioni regolari viene implementato utilizzando un linguaggio normale e non utilizzando una lingua completa di Turing (più accuratamente, utilizzando il sottoinsieme di istruzioni della lingua regolare di una lingua completa di Turing), dovrebbe essere impossibile fare l'iniezione di codice. Una caratteristica dei linguaggi regolari è che casi molto semplici e il flusso di controllo sono sufficienti per implementare il parser. Se implementato con questi semplici strumenti di programmazione, gli hack dovrebbero essere molto difficili.
Si prega di tenere presente che una delle maggiori vulnerabilità è l'attacco di iniezione del codice sovraccarico del buffer. Il modo per evitare questo attacco è scrivere un codice veramente stretto e accurato. Controlla la lunghezza del buffer in modo maniacale per evitare problemi.
Non penso che la tua domanda abbia dettagli sufficienti per una risposta definitiva. Il codice che pubblichi sembra creare una mappa con una chiave di Zip e un valore che è un'espressione regolare. Tutto quello che possiamo dire è che l'espressione regolare inizierà con "^". Sembra che il ^ sia aggiunto alla "regexp" reale, chiamata zipCode, ma non possiamo determinare che cosa è o cosa corrisponderà da ciò che viene fornito . Sospetto che sarà una classe numerica con una specifica di conteggio con il numero di cifre consentito per un codice di avviamento postale, ma è un'ipotesi.
In generale, non c'è nulla di speciale nelle espressioni regolari di per sé che garantirà una query sicura o sicura. Puoi usare un'espressione regolare per disinfettare o scappare l'input in modo che sia sicuro, ma il modo in cui funziona dipende dal modo in cui è scritta l'espressione regolare. La mia esperienza mi ha insegnato che ci sono espressioni regolari scritte molto più male di quelle ben scritte.
Tuttavia, questo potrebbe essere un punto di silenzio a seconda di come viene eseguita la query del database reale. Se l'espressione regolare viene utilizzata semplicemente per pulire o convalidare l'input E quell'input è usato solo come parametri in un'istruzione preparata, allora probabilmente non c'è un problema. Tuttavia, se l'espressione regolare viene utilizzata per pre-analizzare una stringa che viene poi aggiunta a una stringa che viene poi eseguita come query, si potrebbero avere grossi problemi.
In generale, l'iniezione di SQL e l'iniezione di codice nei linguaggi di scripting sono molto simili. In SQL, si è vulnerabili quando si crea una query dinamica utilizzando stringhe e concatenazione e una delle stringhe viene fornita dall'utente. Questo è un modo molto semplice per avere istruzioni SQL molto dinamiche che sono allettanti a causa della flessibilità che offre all'utente finale. il problema è che l'utente può inserire codice dannoso e causare tutti i tipi di problemi. Allo stesso modo, nei linguaggi scriptati, lo stesso problema può verificarsi con l'infame istruzione "eval", che consente di definire il codice da valutare in fase di esecuzione.
La correzione di base per SQL non è quella di utilizzare istruzioni SQl generate dinamicamente. Invece, usa istruzioni preparate che accettano argomenti. Con le istruzioni preparate, gli argomenti forniti non vengono "eseguiti" nello stesso senso in cui sono concatenati su un'istruzione SQl. I motori SQl ben scritti prenderanno i parametri ed eseguiranno vari controlli per assicurarsi che siano validi. questo non accade con un'istruzione SQL dinamica creata da stringhe concatenate.
Se non hai altra opzione che usare un'istruzione SQl dinamica, puoi usare un'espressione regolare per disinfettare i valori che l'utente fornisce, ad esempio, l'escape o la rimozione di caratteri che potrebbero causare problemi. Se fatto correttamente, dovrebbe funzionare bene. Tuttavia, è difficile da fare correttamente. La regexp può diventare rapidamente complessa e la complessità significa che è più facile fare un errore sottile. L'approccio si basa anche sulla persona che scrive l'espressione per essere consapevole di tutti i trucchi di iniezione sottili. Ho visto alcune tecniche di iniezione Oracle SQL che erano davvero sorprendenti e non qualcosa che avrei pensato (come l'uso di una combinazione di impostazioni di variabili d'ambiente relative a formati di data e stringhe di formato di data SQL abilmente elaborate che sulla superficie sembrano essere piuttosto Per questo motivo, eviterei di fare affidamento su un approccio di espressione regolare per la protezione dall'iniezione di codice e preferirei utilizzare invece procedure come stored procedure e istruzioni preparate, con il vantaggio di semplificare ulteriormente il test dell'applicazione e verificare le cose come le prestazioni.Perché le query dinamiche, anche se l'input è sterilizzato, può essere un incubo per quanto riguarda le prestazioni. Si può facilmente finire con un problema di negazione del servizio se un utente si trova a entrare in una risorsa legale, ma estremamente lunga e in esecuzione query intensiva Nei sistemi di produzione, è molto raro che si desideri che i propri clienti siano in grado di eseguire qualsiasi tipo di query - di solito sono r educabile a un sottoinsieme, che può essere grande o complesso, ma che può essere mappato a stored procedure e dichiarazioni preparate.
Ci sono altri possibili problemi con regexp, come le vulnerabilità nel motore regexp, le vulnerabilità di buffer overflow, ecc. Non li sto sollevando perché penso che siano molto meno probabili della semplice esposizione attraverso espressioni regex male scritte. Saranno anche specifici per l'implementazione.
Leggi altre domande sui tag exploit