regex para protegerse de varios ataques

[gAb1]

He estado leyendo sobre distintos tipos de ataques, sobre todo xss. En muchos sitios dicen que es bastente dificil protegerse de este tipo de ataques, sin embargo yo lo encuentro bastante facil:

Código [Seleccionar] Expandir

input=<script>alert(/xss/);</script>
input=>"><script>alert("XSS")</script>&
input=etc...

Código (php) [Seleccionar] Expandir

echo preg_replace('/\W/', '', $_GET['input'])

Adios XSS... ¿Hay algún otro tipo de ataque que pueda pasar ese regex?

Tambien he leido sobre ataques con codificación utf-16, que no lo he entendido, pero si yo tengo el siguiente regex que permite caracteres internacionales como acentos ñ ç, etc, ¿sería vulnerable a algún tipo de ataque?

Código [Seleccionar] Expandir

~[^\pL\d]+~u

¿De verdad es tan facil protegerse? No creo que se pueda hacer XSS sin los tags <>, comillas dobles " o los dos puntos : usados en otro lenguaje (que no recuerdo el nombre).

Gracias.

[engel lex]

el problema de ese metodo es que eliminas todo posible caracter que no es letra... adios espacios, acentos, comas, guiones, puntos, eñes... todo... si quieres hacer un foro, quiero verte arreglandotelas sin espacios ni saltos de linea... o sin acentos, o por lo menos bbcode...

[gAb1]

Ah no, era un ejemplo, está claro que ese tipo de carácteres que no supone ningún riesgo se puede añadir sin ningún problema y seguiría siendo igual de seguro.

Por ejemplo para nombres:

Código (php) [Seleccionar] Expandir

'~[^\pL\d\r\']+~u'

Si no me equivoco \r era espacio normal y comillas simples. Las eñes, ç y demás carácteres internacionales van incluidos.

Si es un comentario se cambia \r por \s y para los demás simplemente se añade el carácter con \.

Pero lo que me interesa es el tema seguridad, ¿que más hay que tener en cuenta?

[xiruko]

Hola,

Para evitar ataques XSS yo utilizo la función htmlspecialchars. Básicamente sustituye los carácteres peligrosos como >, <, ' y " por sus códigos HTML.

Se puede crear una función para hacer un echo seguro muy fácilmente:

Código (php) [Seleccionar] Expandir

function safe_echo($msg, $return=false)
{
    $msg = htmlspecialchars($msg, ENT_QUOTES, 'UTF-8');
    if ($return) return $msg;
    echo $msg;
}

Saludos!

[gAb1]

He leido que si está malformado se ejecuta el código, por eso no me he querido arriesgar. Tambien he leido que hacer una lista blanca con los carácteres permitidos es más seguro. Prefiero ir a lo seguro.

¿Podeis decirme por qué el siguiente regex para emails me da error "catastrophic backtracking"?

Código (php) [Seleccionar] Expandir

/^([\w]+(?:[\.\-][\w]+)*){1,64}@([\w]+(?:[\.\-][\w]+)*){1,64}\.([a-zA-Z]{2,7})$/

Lo he hecho yo y me parece eficiente... no sé que puede pasar. Además el limite de 64 no fuciona, poniendo más se sigue validando, el del tercer grupo si que funciona... que raro.

Gracias!

[xiruko]

He leido que si está malformado se ejecuta el código, por eso no me he querido arriesgar. Tambien he leido que hacer una lista blanca con los carácteres permitidos es más seguro. Prefiero ir a lo seguro.

Podrías poner algún ejemplo de un código malformado?

Ahora mismo no se me ocurre ningún ataque XSS posible si:

1. Usas la función que he puesto para imprimir todo lo que venga del usuario.
2. No imprimes nada que venga del usuario dentro de un bloque <script>.
3. No imprimes nada que venga del usuario en atributos en un elemento de HTML. Esto no me preocupa ya que nunca mezclo JS y HTML, me parece una práctica bastante sucia y prefiero tener el código bien ordenado.

Respecto a lo de la expresión regular, no soy moderador pero creo que sería mejor que abrieras otro tema con ello.

Saludos!

[gAb1]

No soy un experto en este tipo de cosas, pero creo que este es un ejemplo: http://downloads.securityfocus.com/vulnerabilities/exploits/37389.php

De eso hablan aquí en el foro (hace 6 años ya) https://foro.elhacker.net/nivel_web/php_htmlspecialcharacters_malformed_multibyte_character_xss-t281271.0.html
y aquí también hablan de esto (en ingles pero mejor explicado): http://stackoverflow.com/questions/19584189/when-used-correctly-is-htmlspecialchars-sufficient-for-protection-against-all-x

Pero al parecer solo afecta a versiones viejas, o eso creo haber entendido... (que a estas horas...  )

Si, abriré mejor otro tema para el regex del email.

Tengo que leer sobre otros ataques del tipo user input, ¿conoces alguno más? Quiero hacer mis aplicaciones web más seguras (o lo mínimo por lo menos).

EDITO: ¿Entonces es seguro usar codificación UTF-16 para user input? Me refiero al flag /u de regex para poder usar \pL

[xiruko]

Respecto a los enlaces que me pasas, comentan que htmlspecialchars no es suficiente si se imprimen cosas que vengan del usuario en atributos de algún elemento HTML, por el tema de poder usar los eventos onclick, etc. Por eso en mi anterior post puse como restricción no imprimir nada en atributos, porque además de crear un código sucio (a mi gusto), puede plantear problemas de seguridad.

En cuanto a otro tipo de ataques, si tienes cubierto el lado del cliente por el tema de los XSS, y tienes cubierto el lado de la BBDD usando sentencias preparadas para evitar SQL injections entonces no deberías tener más problemas. Bueno, podrías capar el número de intentos de login para imposibilitar ataques por fuerza bruta, validar siempre el tipo de archivos subidos a tu servidor y nunca darles permisos de ejecución, usar algún hash que identifique el navegador del usuario y/o su IP para intentar hacer que sea más difícil el robo de sesiones (aunque no imposible), restringir el acceso a ciertos directorios mediante los archivos .htaccess... Y ahora mismo no se me ocurre ninguna medida más.

Respecto a lo de la codificación UTF-16, ni idea, yo lo he usado en algún proyecto para validar los inputs de los formularios con regex unicodes pero nunca me he planteado si eso presentaba algún problema de seguridad. A ver si alguien con más conocimiento nos saca de la duda.

Saludos!

[gAb1]

Hmmm imprimir dentro de los atributos es necesario en algunos casos, por ejemplo yo lo estoy haciendo para que el usuario pueda modificar sus datos personales, o para que se puedan cambiar datos anteriormente guardados en la DB (que es lo mismo), imprimirendo dentro del atributo value="". Entonces validando con los regex que solo se permitan ciertos carácteres me evito que se pueda guardar código ejecutable en la DB.

Lo básico creo que lo tengo cubierto: el XSS, prepared statements y un servidor estático (sin PHP, donde alojo el css, jscripts...) donde se suben imágenes (el nombre se genera con el número del for y la extensión solo jpg) y .htaccess configurado para que no se pueda navegar por ningún directorio. Para lo de los ataques de fuerza bruta, estoy terminando una clase (flood_detection) que detecte este tipo de ataques y de paso me aseguro que ningún graciosillo sature el servidor con peticiones.

He comentado lo de UTF-16 por casualidad, porque buscando una manera de aceptar carácteres internacionales en regex, me encontré con este post en stackexchange hablando de anonymus que habia cerrado una web de pornográfia infantil en la red tor usando este tipo de codificación.

Por lo que he podido entender es un problema de que php no soportaba utf-16 y el filtro lo deja pasar, normalizando los carácteres y siendo interpretados... Supuestamente lo deberían haber arreglado en php 7.

Gracias!