Regex como primera línea de defensa contra XSS

Question

Tuve una expresión regular como primera línea de defensa contra XSS.

public static function standard_text($str) 
{ 
    // pL matches letters 
    // pN matches numbers 
    // pZ matches whitespace 
    // pPc matches underscores 
    // pPd matches dashes 
    // pPo matches normal puncuation 
    return (bool) preg_match('/^[\pL\pN\pZ\p{Pc}\p{Pd}\p{Po}]++$/uD', (string) $str); 
} 

De hecho, es de Kohana 2.3.

Esto se ejecuta en el texto público ingresado (nunca HTML), y niega la entrada si no pasa esta prueba. El texto siempre se muestra con htmlspecialchars() (o más específicamente, Kohana's flavour, agrega el conjunto de caracteres entre otras cosas). También puse un strip_tags() en la salida.

El cliente tuvo un problema cuando quería ingresar texto con paréntesis. Pensé en modificar o extender el ayudante, pero también tuve una idea secundaria: si permitía las comillas dobles, ¿hay realmente alguna razón por la que deba validar?

¿Puedo confiar en el escape en la salida?

Answer 1

Nunca es seguro confiar en Regexes para filtrar ataques XSS peligrosos. Y aunque no confíe en ellos, el escapado de salida y el filtrado de entrada, cuando se usan correctamente, matarán todo tipo de ataques. Por lo tanto, no tiene sentido tener Regexes como una "primera línea de defensa" cuando su ayuda no es realmente necesaria. Como usted y su cliente han descubierto, solo complican las cosas cuando se usan de esta manera.

Relativamente breve: si utiliza html_entities o htmlspecialchars para escapar de su salida, no necesita expresiones regulares ni tampoco realmente necesita strip_tags.