È possibile utilizzare un carattere di regex di spazi bianchi per eseguire un'iniezione di javascript?

In pratica, è molto improbabile che questo permetta un attacco di iniezione.

Tuttavia ... In teoria, ci sono situazioni fantastiche in cui gli spazi bianchi potrebbero potenzialmente portare ad un attacco di iniezione. Ad esempio, supponiamo che il programma esegua un comando simile al seguente:

echo Something bad happened: code $n >> logfile

dove $n è il parametro della richiesta che hai sterilizzato sopra. Se l'attaccante utilizza un valore come 42\n17 (dove \n rappresenta una nuova riga), questo si trasformerà in due comandi:

echo Something bad happened: code 42
17 >> logfile

Il primo comando verrà eseguito, ma il suo output non verrà salvato. Il secondo comando attiverà un errore command not found (non esiste un programma chiamato 17 ), quindi non verrà eseguito. La conseguenza è che nessun messaggio non verrà aggiunto al file di registro, contrariamente a quanto previsto dal programmatore.

Questo è molto improbabile, in quasi tutti i programmi che potresti incontrare. Quindi, probabilmente puoi ignorarlo. Ma ... in teoria, suppongo che potrebbe accadere.

P.S. La tua espressione regolare sembra discutibile. Come dice @Rook, corrisponde solo a un singolo carattere. Inoltre, a seconda di come viene utilizzato, potrebbe essere necessario ancorarlo. Forse intendevi qualcosa del genere:

/^[0-9\s]+$/

Sì.

Really vecchie versioni di SpiderMonkey seguivano una parte della specifica che diceva che tutti i caratteri di controllo del formato (Cf) venivano rimossi dal testo del programma prima dell'inizio del parsing.

Questo significava che

"\CF\",alert(1337)//"

dove CF è un carattere di controllo di formato invisibile apparso come una singola stringa ma in realtà è stato trattato dal parser come equivalente a

"\",alert(1337)//"

o per separare i token analizzati con spazi bianchi

"\" , alert ( 1337 ) //"

Se un parser JSON scritto male ha assunto \ seguito da qualsiasi carattere era una sequenza di escape, prima di inoltrare la stringa a eval , quindi un utente malintenzionato che controlla l'input potrebbe ottenere codice JavaScript arbitrario su eval .

Questo attacco è solo di interesse storico ora, ma non presumere che errori simili non verranno fatti di nuovo.

I programmatori scrivono spesso filtri di espressioni regolari che includono . , ma dimentica che non corrisponde alle nuove righe.

Le modalità di recupero degli errori complicate nei parser (come i parser CSS) spesso usano interruzioni di riga come punti per tentare di riavviare l'analisi, quindi le nuove linee potrebbero essere utili per interpretare il contenuto quotato come codice quando un parser riavvia l'analisi perché ha visto cosa sembra essere un letterale stringa non chiuso.

Lista bianca in modo che eventuali usi ampi di caratteri invisibili vengano gettati via.