XSS: Cross Site Scripting – ¿Cómo evitarlo?
En un post anterior, hablaba de tipos básicos de ataques de XSS, la pregunta que normalmente aparece en la mente después de leer eso es ¿cómo lo evito?En general, y dada la importancia de estos ataques, la mejor defensa es una buena prevención. Esto aunque suene quizá a "muy buenas prácticas" es verdaderamente un hecho. La idea fundamental para evitar XSS es:
Todas las entradas proporcionadas por el usuario deben de ser validadas antes de ser utilizadas.
Pero como la idea fundamental habitualmente es olvidada, creo que un checklist es mucho más clarificante. Decir que como siempre, el checklist contiene una serie de puntos que pueden ser comprobados, pero no pretende ser una lista completa ya que muchas cosas dependen de tecnologías web concretas, simplemente unos primeros sitios por donde empezar.
-
Bases de datos
- Evitar que se puedan ejecutar más de una sentencia SQL en un mismo comando.
- Utilización de Prepared Statements: ¿Y eso qué es? Básicamente el término prepared statement hace referencia a un tipo de consultas SQL que no se ejecutan concatenando cadenas de caractares.El funcionamiento es primero construir el esqueleto de la sentencia SQL y luego decir qué parametros van en cada punto.
De esta forma el ejemplo anterior quedaría:
SELECT identificadorFROM usuariosWHERE username = ? AND password = ?Ahora sólo quedaría decir qué es cada uno de los parámetros, lo importante es que en esta operación se dice de qué tipo son los mismos, por lo que por ejemplo introducir un número cuando se espera un cadena daría error. En Java por poner un ejemplo, se realizaría con:
preparedStatementObject.setString(1, "usuario");
preparedStatementObject.setString(2, "contraseña"); - Comprobar las entradas aunque hayan sido comprobadas en la parte cliente. El objetivo sería prevenir posibles problemas relacionados con buffer overflows.
-
Servidores o Aplicaciones Web
- HTTPS no evita XSS. HTTPS es un protocolo que asegurará que la conexión entre el servidor y el cliente es segura, pero no asegura nada de los datos intercambiados.
- Filtrado de código HTML que se permite introducir por los usuarios. Esto es especialmente problemático en componentes encargados de los comentarios en un blog o foro.
- Se puede utilizar un pre-filtrado en código cliente (que será ejecutado en el navegador del usuario), pero sólo como medida adicional de prevención.
- Evitar utilizar sólo parámetros que viajan con la página para autenticar un usuario. El ejemplo más típico es que aunque exista un parámetro &ID=[cadena de caracteres], eso sólo debe ser utilizado como media adicional
- En ocasiones sería recomendable comprobar el campo REFERER de la petición HTTP para saber de dónde viene una petición, pero también hay que tener en cuenta que es un campo opcional.
- Evitar filtrar por codificaciones, este ejemplo quizá parezca bastante absurdo, pero se dan casos donde por ejemplo se filtra por ejemplo un tag que contenga javascript, pero no se filtra
jav[caracter x09]ascripty a efectos prácticos es lo mismo.
Y aquí acaba la introducción a XSS, espero que al menos no haya resultado excesivamente técnico 🙂 Como comentario final, simplemente añadir que al final lo mejor es estar al tanto de los ataques que se realizan. El tema de seguridad, siempre es un mundo que se mueve deprisa y en el que algo que se hacía hace un año o 1 mes, es muy probable que ya no tenga validez.
Referencias:
10 Types Of People 
window.location=»www.google.com»;
alert(«xss this is vulnerable»);
Buen articulo…, sigue asi.. 😉
sadfd
alert(“xss this is vulnerable”);
hola esta es una prueba
alert(“xss this is vulnerable”);
«/>alert(«VULNERBALE»)</
test
javascript:while(1)alert(«Este mensaje saldra indefinidamente»);
//
alert(«ok»);
alert(“xss this is vulnerable”);
alert(“vulnerable”);
alert(‘ataque xss’)
alert(‘dsfsdfsdf’)