[Manual] Ataques XSS, peligros de $_GET

Me encontre un muy buen manual sobre XSS, y pues nos hay mucho que agregar, esta muy digerible y en español.

Aqui lo tienen.


Que es XSS

Sobre XSS, no hay mucho que decir que no se haya dicho antes. Yo definiría a XSS como un ataque que se basa en explotar métodos poco correctos de programación para ejecutar script malicioso de cliente (comunmente JavaScript) al momento que un usuario desprevenido ingresa al sitio víctima del ataque. Que yo, atacante, pueda hacer que en el sitio víctima se ejecute un script JavaScript arbitrario, aunque a algunos les pueda parecer inofensivo, resulta realmente peligroso. Un código JavaScript puede redireccionar usuarios a otras URL’s, puede cambiar la información que se muestra en el sitio y, quizá lo más interesante, puede obtener los valores de las cookies que el navegador del usuario posea en ese momento. Obtener el valor de las cookies equivale a obtener el Session ID (SID a partir de ahora), el cual se utiliza para que el servidor reconozca al usuario “Pepe” como “Pepe” y no como ningún otro. Suponiendo que se utiliza sistema de sesiones nativas de PHP (session_start() y sus secuaces), si yo tengo el SID de “Pepe” que se almacena en sus cookies, puedo ingresar como “Pepe” aunque no lo sea.

Tipos de vulnerabilidades y sus consecuencias

Lo que voy a mostrar aquí es uno de los tipos de vulnerabilidad XSS el cual es llamado “Tipo 1″ o “No persistente”. Una vulnerabilidad no persistente será aquella en la que el script malicioso debe ser enviado explícitamente mediante el navegador del usuario víctima cada vez que el atacante desea ejecutar código maligno en ese navegador. Para enviar script maligno se utilizan las variables $_GET, $_POST y $_COOKIES. Leyendo lo antedicho pueden que estén pensando en que un usuario nunca será tan inocente como para enviar código malicioso desde su navegador existiendo la posibilidad que sus cookies sean vulneradas… el problema es que el atacante puede inducir mediante Ingeniería Social al usuario víctima a hacer click en una URL del tipoindex.php?titulo=%3Cscript%3Ealert%28%22XSS%22%29%3B%3C%2Fscript%3E con lo que ya se estaría logrando la inyección de código malicioso codificado e imperceptible para la visión de un usuario con poco conocimiento.
Por otra parte les comento solo a modo informativo que existen vulnerabilidades XSS “Tipo 2″ o “Persistentes” en las cuales el código malicioso no necesita ser inyectado cada vez mediante el navegador del usuario víctima, sino que este código ha sido previamente guardado por el atacante en la base de datos que utiliza el sitio víctima. De esta forma cada vez que el sitio recupere y muestre registros de su base de datos, el script maligno estará allí y será ejecutado para cualquier usuario visitante. Es sencillo deducir que este tipo de vulnerabilidad puede resultar muchísimo más peligrosa debido a la persistencia del código maligno, pero en este artículo centraremos nuestra atención en el tipo anterior.

Entrando en tema: algunos ataques “inocentes”

Supongamos algo simple: una página que, para mostrar su título se vale de un parámetro recibido por la URL (via $_GET). Su código se vería algó así:

test.php

< ? php ‘.echo $_GET[“title”]; ?>

Pues bien, esto no parece demasiado peligroso y puede que sea algo que comunmente hacemos en nuestros scripts. Pero que tal si nuestro tan odiado atacante mediante Ingeniería Social induce a un pobre usuario víctima a ingresar con:

test.php?title=<script>alert(“¡Este Sitio es un peligro!”)</script>

Para quien no tenga ganas de probar le comento el resultado: en el sitio víctima saldrá un “cartelito” con el mensaje “Este Sitio es un peligro”. Pueden argumentar con cierta razón que la URL anterior se me medio sospechosa, y que nadie en su sano juicio ingresaria al sitio clickeandola, pero siempre el atacante puede codificarla un poco para que se vea algo más inocente:

// Codificación realizada mediante urlencode() de PHP
test.php?title=%3C%2Ftitle%3E%3Cscript%3Ealert%28%22%A1Este+Sitio+es+un+peligro%21%22%29%3C%2Fscript%3E

Ahora ya no se ve tan peligrosa… quizá un usuario ingrese inocentemente llevándose la sorpresa del molesto cartelito.
Hasta ahora los ataques XSS no se ven tan dañinos; al fin y al cabo mostrar un alert() no daña demasiado a nadie. La realidad es que cuando en nuestro sitio dejamos abierta la posibilidad que nos ataquen mediante esta técnica, la gravedad del ataque está limitada únicamente a la imaginación del atacante y las posibilidades que nos brinda JavaScript. Cualquier cosa que JS permita hacer, puede ser realizada en un ataque XSS. Por ejemplo ¿qué pasaría si test.php fuera llamado de la esta manera?:

test.php?title=<script>location.href=”/web/20071117063032/http://www.google.com”</script>

Pueden leer el contenido del articulo completo en Formatoweb XSS

Modificado a petición del autor

Leave a Comment

Your email address will not be published. Required fields are marked *