Voy a intentar recopilar un poco los conceptos básicos sobre Xss, que tanto vemos en todas las listas de fallos, y que espero nadie confunda con una nueva talla para modelos anoréxicas ( yo sin embargo gasto en casi todo la xxxxl xD). El objetivo del comentario es el de explicar de manera sencilla que son estos fallos, y de las consecuencias o vectores de ataque habituales.
Según OWASP, el Xss es la vulnerabilidad mas presente en todas las aplicaciones.
¿Por qué no es Css? Sencillo, por no confundir con las hojas de estilo.
El concepto es easy. En un campo de entrada en una Web (busqueda,url, variables, logins,etc) se realiza una entrada no válida o no esperada, para aprovechar ese comportamiento "indeseado".
Una de las cosas que debemos tener en cuenta, tanto si atacas o si no quieres ser atacado, es filtrar los caracteres "raros", usando un condicionante para expresiones regulares, para protegerse, y usando una codificación para atacar, por ejemplo inyectando parametros en hexadecimal ( suele estar ya muy controlado).
En cada tipo intentaré documentar los ataques y evasivas.
Me excuso un poco de publicar este contenido tan newbie ( como yo) y que lleva desde principios de siglo ( me encanta usar esta expresión) pero que hoy en día, como empieza el post, es el objetivo principal de ataques sobre aplicaciones web.
Reflected Cross Site Scripting (OWASP-DV-001)
El XSS no persistente, es una inyección de código simple, que se presenta en el navegador cliente, y suele usarse para redirigir a otra web, que infecte al cliente. También se usa para robar cookies, historial de visitas, etc, si sabes programar scripts, el límite es el cielo. Añado que un script que se recargue, y que no deje al usuario interactuar con el navegador, a no ser que mate el proceso, es una forma de ataque DOS (si encima tenia pestañas con información útil, lo fríes).
Ejemplo en claro
http://www.webvictima.com/index.php?user=<script>alert(document.cookie);</script>
ejemplo quitando <> y en hexadecimal
%3C%2Fscript%3
Como es normal, vosotros que sois expertos informáticos leéis la URL y sospecháis, pero y si es un link con un acortador tupo tiny, en un tweet o Factbook?
Stored Cross Site Scripting (OWASP-DV-002)
Misma inyección de código, pero con la característica que se ejecuta en todos los navegadores de todos los clientes que acceden a la url. Por qué? Sencillo, guardando los parámetros en el servidor. En que aplicaciones web vamos a poder ESCRIBIR en el servidor ( imaginamos que los admins de los servidores web tienen controlada la escritura directa, ya que para que querríamos usar XSS pudiendo “delete *” ) pues por ejemplo en post sobre foros, información de perfiles, carritos de compra, aplicaciones que permiten configurar rutas de carpetas…
Por ejemplo, en un comentario de un articulo de una web suelen estar controladas las etiquetas HTML, pero si empezamos así: “><script>document.alert(XSS)</script> posiblemente el navegador lea esto: <input type="text" name="comentario" id="anotaciones" value="”><script>document.alert(XSS)</script>
Otra manera menos cantosa, inyectando un iframe oculto: ”><iframe frameborder=0 height=0 width=0
Vectores posibles, muchos, pero secuestrar las sesiones de todos los navegadores para hacer redes zombies, o simplemente aumentar las visitas de un sitio… los que te imagines.
DOM Cross Site Scripting (OWASP-DV-003)
Lo primero, qué es DOM? http://es.wikipedia.org/wiki/Document_Object_Model
El DOM Xss es una inyección de código que no devuelve unos datos en el navegador, sino que inyecta parámetros ( javascript muy vulnerable, como ya saben) para que actúen sobre elementos DOM. Por ejemplo así:
/index.html#user=<script>alert(document.cookie)<script>
Cambiamos el? por #
Qué pasa? Que el navegador ejecuta el script, sin que haya transito hacia el Server, por lo que es complejo mitigar por partes de los sysadmin, a no ser que hagan test ( si no viajan peticiones, no pueden analizarlas)
Cross Site Request Forgery (CSRF)
También denominado XSRF. En todos los tutoriales compara Csrf con Xss diciendo que, en el segundo caso, el fallo reside en la confianza que tiene el usuario sobre un sitio Web (si todos los días entras a la Web de un banco, si alguien mete un formulario o redirección a login, confías en tu Web) mientras que en Csrf, es la web la que confía en las acciones de un usuario.
Básicamente, el atacante publica un código, embebido en un fragmento HTML por ejemplo en un foro, que al ser ejecutado por la víctima, ejecuta dicho código con sus privilegios dentro del aplicativo. Puede ser que en este ejemplo, de un foro, tanto el atacante como la víctima tengan los mismos permisos para publicar, pero quizás sea mucho más dañino usar el nombre de la víctima para publicar información…
Las recomendaciones generales para el usuario sobre como mitigar el impacto son:
Cerrar la sesión y no cerrar la ventana al salir de aplicaciones. No guardar las contraseñas para ninguna aplicación, por mucho que la usemos. No usar el mismo navegador para ver porno ( hay porno en Internet?) y en otra pestaña la web del banco o la empresa.
Respecto a los desarrolladores, usar la cookie de sesión, enfuscada, en todas las peticiones a las url´s. por ejemplo, si tenemos un sitio tal que así www.miempresa.com/nominas/mi nómina.aspx sería muy fácil para un atacante conocer la estructura, y redirigir al atacante hacia esa web, y a su vez redirigir el resultado hacia el atacante. Si en la url aparecería la validación de sesión enfuscada, el atacante tendría mas problemas para conocer la estructura de ficheros a enviar.
Un ejemplo bien explicado por parte de Ms. http://msdn.microsoft.com/en-us/security/Video/bb977433
En la próxima entrega, intentaré hablar mas sobre estos fallos, y :
Cross Frame Scripting, Cross Zone, Cross Agent,Cross Referer y demás.
gracias !!!
Os recomiendo que no pase ni un minuto desde que leéis esto, a que leais:
Como probar estas técnicas sin ir a la cárcel, pues hay muchos sitios y proyectos, pero encuentro muy interesante y fácil de instalar en entornos ventana: http://sourceforge.net/projects/mutillidae/