PRÁCTICA No. 3: XSS - Secuencias de Comandos en Sitios Cruzados A. Objetivo de aprendizaje El alumno comprenderá la importancia de corregir los defectos de programación mediante la práctica de la técnica de XSS Secuencias de Comandos en Sitios Cruzados B. Conceptos teóricos XSS, del inglés Cross-site scripting es un tipo de inseguridad informática o agujero de seguridad típico de las aplicaciones Web, que permite a una tercera parte inyectar código JavaScript o en otro lenguaje script similar, evitando medidas de control. XSS es un vector de ataque que puede ser utilizado para robar información delicada, secuestrar sesiones de usuario, y comprometer el navegador, subyugando la integridad del sistema. Esta situación es usualmente causada al no validar correctamente los datos de entrada que son usados en cierta aplicación, o no sanear la salida adecuadamente para su presentación como página web. Esta vulnerabilidad puede estar presente de las siguientes formas: Indirecta (también llamada Reflejada): este tipo de XSS consiste en modificar valores que la aplicación web utiliza para pasar variables entre dos páginas y sucede cuando hay un mensaje o una ruta en la URL del navegador, en una cookie, o cualquier otra cabecera HTTP. Directa (también llamada Persistente): este tipo de XSS comúnmente filtrado, y consiste en insertar código HTML peligroso en sitios que lo permitan. PARTE 1. XSS indirecto 1. El primer paso será encontrar un sitio vulnerable ante este tipo de técnicas (El 80% de los sitios web son vulnerables en alguna u otra medida). Nos dirigimos al buscador Google y colocamos este tipo de búsquedas: inurl:"search.php?q=" inurl: búsqueda.php? Aparecerán diversos sitios con dos controles web: una caja de texto y un botón, con los cuales se realiza una búsqueda de información dentro de la base de datos de la página.
Para efectos prácticos, en el resto de este ejercicio haremos uso de la siguiente URL: http://www.scielo.org/php/index.php?lang=es La cual contiene una caja de texto y un botón de búsqueda como se puede observar en la siguiente imagen: 2) Para cotejar que la página web es vulnerable, será necesario introducir un término de búsqueda y cotejar que la página de resultados muestre la cadena sin modificaciones. En caso de que la cadena no se muestre de la misma forma en que la ingresamos será necesario probar con otra página. 3) Una vez que se ha cotejado que la página web es vulnerable pruebe ingresando un script de tipo javascript para verificar que el sitio es capaz de ejecutar instrucciones de este tipo 4) Para tomar control del sitio y que pueda ejecutar código con una URL directamente, deberá leer el código fuente de la página origen (página donde se realiza la búsqueda) y pasar los valores por GET a la página destino (página donde se muestra el resultado) de la siguiente forma:
En este ejemplo, el formulario de búsqueda tiene dos variables que pasan a la página destino: expression que corresponde a la caja de texto y pequisar que corresponde al botón de enviar. Probaremos estas variables directamente en la página destino como parámetros GET de la siguiente forma: Dos de los ataques más comunes que se llevan a cabo con esta técnica, consisten en la captura de sesiones y la inserción de formularios de captura apócrifos mediante la creación del script en una URL y la compartición de la misma. a) CASO 1: Captura de sesiones (Mostrar en pantalla) Para este caso, la expresión a buscar es sustituida por un script que da lectura al comando JavaScript document.cookie mediante el cual un usuario es capaz de dar lectura al archivo de variables tipo COOKIE almacenadas en su equipo de cómputo. Sin embargo, un atacante podría leer este archivo de forma remota e incluso guardarlo dentro de su servidor. Un ejemplo para acceder a las variables tipo COOKIE es el siguiente: searchbytitle.php?expression=<h1>hi,i get your cookies</h1> <script> document.write(document.cookie); </script>&pesquisar=; Obteniendo el siguiente resultado en pantalla:
Con lo cual se obtienen datos como la ubicación del usuario, su sesión, etc. b) CASO 2: Inserción de formularios apócrifos En este segundo caso, el objetivo es crear una URL maliciosa que al ser distribuida, pueda pasar por una real dado que el inicio de la misma proviene desde un sitio legítimo, pero que sin embargo contiene un formulario que nos permitiría obtener datos sensibles del usuario final. Un ejemplo simple para crear un formulario puede ser el siguiente: searchbytitle.php?expression=<h2>enviar resultados a correo</h2> <div id="c">pagina</div> <script>document.getelementbyid("c").innerhtml="login form <br><br> User:\u0026nbsp; <input type=text size=20> <br><br> Password: \u0026nbsp; <input type=text size=20> <br><br> <input type=submit value=enviar>"; </script>&pesquisar=; Obteniendo el siguiente resultado en pantalla:
Por último, para el caso en que realmente quisiera distribuir una URL maliciosa, está podría ser codificada en código Hexadecimal para evitar ser reconocida por el usuario final, esto se logra con la ayuda de herramientas en línea disponibles tal como http://www.swingnote.com/tools/texttohex.php En este caso, la URL final del caso 1 quedaría de la siguiente forma: http://www.scielo.org/applications/scielo-org/php/searchbytitle.php?expression= %3c%68%31%3e%48%69%2c%49%20%67%65%74%20%79%6f%75%72%20%63%6f%6f%6b%69%65%73% 3c%2f%68%31%3e%20%3c%73%63%72%69%70%74%3e%20%64%6f%63%75%6d%65%6e%74%2e%77%7 2%69%74%65%28%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%29%3b%20%3c%2f%73% 63%72%69%70%74%3e&pesquisar=; EJERCICIO 1: Ejecute los pasos anteriores y encuentre al menos otro sitio vulnerable en la red. Registre sus resultados PARTE 2. XSS Directo 1. Este tipo de ataques es mucho más peligroso que el anterior y sus efectos pueden llegar a ser fatales para el sitio que logra ser vulnerado mediante esta técnica. En el año 2012 fue reportada una vulnerabilidad XSS dentro de los sistemas que corrían bajo el CMS WORDPRESS, a continuación los datos del ataque: # Type: XSS Vulnerability # Exploit: http://site.com/{path}/wp-content/plugins/wp-password/login.php?err={your Text} # Google Dork: inurl: /wp-content/plugins/wp-password/login.php Si realiza una búsqueda del Google Dork en el buscador de Internet, podrá cotejar que casi el 100% de los sitios expuestos se encuentran vulnerados. Para realizar una prueba de cómo llevar a cabo este tipo de ataques se realizará en un entorno controlado para lo cual se instalará una aplicación PHP vulnerable (DVWA) de origen sobre la cual se llevará a cabo el ejercicio. Para poder realizar la práctica deberá configurar la aplicación con el nivel de seguridad más bajo. Este nivel se puede configurar en el menú DVWA Security
Al ingresar al menú XSS Stored se muestra una aplicación que pretende hacer las veces de un formulario para firmar un libro de visitas de un sitio Web, la cual es una situación que comúnmente puede ser vulnerable a este tipo de ataques. A diferencia del XSS de tipo indirecto, en el XSS directo el ataque pretende que el código malicioso permanezca en la página Web atacada, logrando que todos los visitantes puedan visualizar dicho código. Ingrese los siguientes comentarios dentro de las casillas NOMBRE y COMENTARIO. Nombre: Usuario1 Comentario: <script>alert("hola");</script> Nombre: Usuario2 Comentario: <img src= http://i.ytimg.com/vi/vqzy88tfan4/0.jpg> Nombre: Usuario3 Comentario: <iframe src=" http://mexico.cnn.com/ "></iframe> Nombre: Usuario4 Comentario: <script>alert(document.cookie)</script> EJERCICIO 2: Analice cuidadosamente cada uno de las entradas al libro de vivitas y explique el código malicioso y la consecuencia que cada uno podría tener sobre un visitante.