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:

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?


¿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.

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:

'~[^\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?

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"?

/^([\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!

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

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!