¿Se puede usar un carácter de expresión regular de espacio en blanco para realizar una inyección de javascript?

En la práctica, es muy poco probable que esto permita un ataque de inyección.

Sin embargo ... En teoría, hay situaciones inverosímiles en las que los espacios en blanco podrían llevar a un ataque de inyección. Por ejemplo, supongamos que el programa ejecuta un comando como el siguiente:

echo Something bad happened: code $n >> logfile

donde $n es el parámetro de solicitud que has saneado anteriormente. Si el atacante usa un valor como 42\n17 (donde \n representa una nueva línea), esto se convertirá en dos comandos:

echo Something bad happened: code 42
17 >> logfile

El primer comando se ejecutará, pero su salida no se guardará. El segundo comando activará un error command not found (no hay ningún programa llamado 17 ), por lo que no se ejecutará. La consecuencia es que no se agregará ningún mensaje al archivo de registro, contrariamente a la intención del programador.

Esto es muy poco probable, en casi todos los programas con los que es probable que se ejecuten. Entonces, probablemente puedas ignorarlo. Pero ... en teoría, supongo que podría suceder.

P.S. Su expresión regular se ve dudosa. Como dice @Rook, solo coincide con un solo personaje. Además, dependiendo de cómo se use, es posible que deba anclarlo. Tal vez quisiste decir algo como esto:

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

Sí.

Las versiones realmente antiguas de SpiderMonkey siguieron una parte de la especificación que decía que todos los caracteres de control de formato (Cf) se eliminaron del texto del programa antes de que se iniciara el análisis.

Esto significa que

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

donde CF es un formato de control de formato invisible, el carácter parece ser una sola cadena, pero el analizador lo trató como equivalente a

"\",alert(1337)//"

o para separar tokens analizados con espacios en blanco

"\" , alert ( 1337 ) //"

Si un analizador JSON mal escrito suponía que \ seguido de cualquier carácter era una secuencia de escape, antes de reenviar la cadena a eval , entonces un atacante que controla la entrada podría obtener un código JavaScript arbitrario a eval .

Este ataque solo tiene interés histórico ahora, pero no asuma que no se volverán a cometer errores similares.

Los programadores a menudo escriben filtros de expresiones regulares que incluyen . pero olvidan que no coincide con las nuevas líneas.

Los modos de recuperación de errores complicados en los analizadores (como los analizadores CSS) a menudo usan saltos de línea como lugares para intentar reiniciar el análisis, por lo que las nuevas líneas pueden ser útiles para hacer que el contenido citado se interprete como un código como cuando un analizador reinicia el análisis porque vio qué parece ser una cadena literal no cerrada.

Lista blanca para que cualquier uso amplio de caracteres invisibles se deseche.