Ataques XSS y JavaScript Injection : como evitar los ataques XSS y la Inyección Javascript. Volumen I

Son muchas las webs que cualquier usuario de internet visita hoy en día y muchas de ellas dedicadas o con operaciones financieras de por medio. Por ejemplo una tienda online, un pago de Megaupload o Rapidshare etc. Todas ellas tienen transacciones sensibles de ser objetivo de piratas informáticos y no todas ellas están convenientemente protegidas. En este artículo intentaremos explicar un poco un ataque que suele considerarse benigno: XSS y JAVASCRIPT Injection. En teoría, el ataque por inyección es sencillamente una forma de «colar» sentencias que no suelen pasar de una broma, pero que convenientemente situadas con un poco de malicia, podrían obtener nuestros datos.
Por poner un ejemplo, la web del Banco Santander (Este fallo ya fue notificado y está actualmente corregido). Os recomendamos visitar nuestro tutorial sobre cómo hacer el ataque ARP Poisoning.
Imaginemos el siguiente escenario:
Una persona cualquiera va a ver su saldo en el Banco Santander y a realizar una transferencia. La web del Banco Santander tendría una URL como ésta:
www.bancosantander.com/mirarCuenta?opeowpoe=123
Como al equipo de personas que construyó inicialmente la web no tomó en cuenta validar los datos de entrada (las validaciones constituyen una parte vital para la creación de una web en cuestiones de seguridad y desde el punto de vista de un desarrollador) un atacante podría construir algo así: (la forma del ataque está cambiada para evitar a los Script Kiddies)
www.bancosantander.com/mirarCuenta?opeowpoe=123(javascript:alert(«es usted un ladrón»);)
Y la víctima, a la que previamente se le habría enviado dicho enlace, vería lo siguiente:
Un enlace válido que llevaría de inicio un dominio conocido y en el que confía: www.bancosantander.comy en este caso inocente, un mensaje ridículo que no tienen mayores consecuencias.
Ahora imaginad lo siguiente: el mismo escenario pero esta vez el pirata informático va mas lejos: crea un código por Javascript que muestra una pantalla de login de usuario y contraseña idéntica a la real del Banco Santander y que por debajo envía dichos datos a un correo que previamente será consultado por el pirata y que luego redirige a la verdadera página de login del Banco Santander sin que el usuario perciba nada extraño. Este escenario fue el que se probó (de forma interna) y dio un resultado excelente: muchos usuarios dieron sus datos de inicio de sesión.
Otro escenario real: una conocida tienda online (no diré el nombre porque su error no está corregido) transmitía el precio de sus artículos a su sistema de pedidos automático por la URL de esta manera:
www.todobaratoybonito.com?nombre=televisorPlasma&precio=1000&
Al ver ese tipo de URL, la prueba era sencilla: pusimos en la variable precio el valor que quisimos, es decir:
www.todobaratoybonito.com?nombre=televisorPlasma&precio=1&
Y el resultado fue que en la cesta de la compra del usuario, a falta de darle al botón enviar, existía un televisor de plasma de 1000 euros que pudimos comprar por 1 €.
Como anécdota, un pirata informático que intentó aprovecharse de dicha vulnerabilidad fue arrestado por mandar el paquete al lado de su casa.
¿Como se originaron estos fallos?:
Como ya hemos comentado, las validaciones en una página web son una parte importantísima en lo que a seguridad se refiere. Si los desarrolladores hubieran tenido en cuenta algo tan básico, hubieran validado por ejemplo lo siguiente: que la variable opeowpoe tuviera como valor un número, de no mas de 5 cifras (por ejemplo). Con esa sencilla validación se hubiera evitado este tipo de ataques.
Otro conocido fallo es el de recuperación del usuario y contraseña mediante el la Gestión de Contraseñas del Firefox.
Cualquier usuario que inserta un usuario y contraseña en una página web, puede darle a la conocida opción de «recordar contraseña». Esto es en apariencia inocuo y muy útil; pero tiene sus riesgos:
Rsnake, conocido en el mundo del underground, escribió un hilo en un foro (no diré cual) cuyo tema era discutir acerca de los peligros de recordar los campos en los navegadores.
Un hacker, combinando XSS con la gestión de contraseñas de Firefox pudo averiguar las contraseñas de los usuarios. El proceso fue el siguiente:
Encontró una vulnerabilidad en el foro de XSS que primero cerraba la sesión de la víctima y luego abría una ventana por otra vulnerabilidad XSS que incluía un comando para robar la contraseña, que se insertaba automáticamente y era accesible vía Javascript.
Firefox ya tiene ese fallo cubierto, no es viable el ataque de esta manera.
Hasta aquí llegamos con este Primer Volumen de ataques XSS y Javascript Injection.