 Autor
|
Tema: regex para protegerse de varios ataques (Leído 4,060 veces)
|
gAb1
 Desconectado
Mensajes: 731
|
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: input=<script>alert(/xss/);</script>
input=>"><script>alert("XSS")</script>&
input=etc...
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? ~[^\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.
|
|
|
|
|
En línea
|
|
|
|
|
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...
|
|
|
|
|
En línea
|
El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.
|
|
|
gAb1
Desconectado
Mensajes: 731
|
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? |
|
|
|
|
En línea
|
|
|
|
xiruko
Desconectado
Mensajes: 438
|
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: function safe_echo($msg, $return=false) { if ($return) return $msg; echo $msg; }
Saludos! |
|
|
|
|
En línea
|
|
|
|
gAb1
Desconectado
Mensajes: 731
|
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! |
|
|
|
|
En línea
|
|
|
|
xiruko
Desconectado
Mensajes: 438
|
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!
|
|
|
|
|
En línea
|
|
|
|
|
|
xiruko
Desconectado
Mensajes: 438
|
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!
|
|
|
|
|
En línea
|
|
|
|
gAb1
Desconectado
Mensajes: 731
|
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! |
|
|
|
|
En línea
|
|
|
|
|
| Mensajes similares |
|
Asunto |
Iniciado por |
Respuestas |
Vistas |
Último mensaje |
|
|
|
Como protegerse de ataques xss??
Desarrollo Web
|
gatocano
|
5
|
5,022
|
21 Julio 2011, 20:11 pm
por gatocano
|
|
|
|
Japón quiere reforzar su ciberseguridad tras varios ataques y en medio de la ...
Noticias
|
wolfbcn
|
0
|
1,349
|
27 Septiembre 2011, 17:28 pm
por wolfbcn
|
|
|
|
Sobre IP Spoofing y ataques varios.
Redes
|
kub0x
|
0
|
1,869
|
21 Octubre 2012, 23:09 pm
por kub0x
|
|
|
|
¿Cómo debe protegerse un pequeño comercio de los ataques informáticos?
Noticias
|
wolfbcn
|
0
|
1,304
|
27 Enero 2014, 14:01 pm
por wolfbcn
|
|
|
|
Rising Sword: una 'vacuna' gratuita para protegerse de ataques como el de ....
Noticias
|
wolfbcn
|
0
|
1,973
|
21 Mayo 2017, 03:12 am
por wolfbcn
|
 |
)