Este documento proporciona una introducción a los ataques de scripting HTML, incluyendo diferentes tipos como Cross-Site Scripting (XSS) reflejado y persistente. Explica cómo los ataques XSS explotan las vulnerabilidades cuando los datos del usuario no son validados antes de mostrarlos. También discute técnicas para identificar y mitigar estas vulnerabilidades, como validar y codificar todo el input y output.

1. Protegiendo mi Identidad Si no soy yo, ¿sos vos? Hernán M. Racciatti SICLabs (at SICinformática) http://www.sicinformatica.com.ar [email_address] HTML Scripting Attack

2. http://creativecommons.org/licenses/by-nc-sa/2.5/ar/ Ud. puede: Copiar, distribuir, exhibir, y ejecutar la obra Hacer obras derivadas Bajo las siguientes condiciones: Atribución. Debe atribuir la obra en la forma especificada por el autor No Comercial. No puede usar esta obra con fines comerciales. Compartir Obras Derivadas Igual. Si altera, transforma, o crea sobre esta obra, sólo podrá distribuir la obra derivada resultante bajo una licencia idéntica a ésta. Licencia de uso: Creative Commons 2.5 Argentina

3. Temario Antes de Comenzar… HTML Scripting Attacks Por qué Hablar de HTML Scripting Attacks? Cross-Site Scripting Reflected Cross Site Scripting (XSS) Los POST también son explotables? Persistent Cross Site Scripting (XSS) Reflected Cross Site Scripting (Local Files) Cien por ciento seguro? Cómo identificar vulnerabilidades de XSS? Contramedidas Referencias y Lectura Complementaria

4. Antes de comenzar… Web Server Cliente/Browser El Browser conecta con el servidor y requiere una página El Server responde el requerimiento enviando la página (archivo) solicitada

5. Antes de comenzar… Cliente/Browser

6. Antes de comenzar… Cliente/Browser

7. Antes de comenzar… Cliente/Browser

8. HTML Scripting Attacks En palabras sencillas, los ataques de HTML Scripting, tienen por propósito inyectar código (Visual Basic Script, ActiveX, Flash, etc.) con el objeto que el mismo sea retornado como parte del output de una aplicación, modificando de este modo su normal comportamiento.

9. HTML no solamente es utilizado en la web Mails - Help Files - GUIs HTML rendering engines ricas en funcionalidades: Running Scripts - Plug-ins – Applets Ventajas para el desarrollador a la hora de crear aplicaciones más atractivas -> Nuevas posibilidades de explotación para el atacante. Por qué hablar de HTML Scripting Attacks?

10. Por qué hablar de HTML Scripting Attacks? Del mismo modo en que HTML no se encuentra restringido a la web, los ataques de HTML Scripting tampoco. A pesar de que este tipo de ataques son extremadamente comunes en aplicaciones web, aplicaciones cliente que no realicen rendering HTML de tipo server-side , pueden también ser vulnerables.

11. HTML Scripting Attacks Cross-site scripting (XSS) Reflected Cross-Site Scripting (Non-persistent) Persisted Cross-Site Scripting (Script Injection)

12. Cross-Site Scripting El script HTML que suele devolverse a un navegador web desde un servidor, normalmente fue colocado allí por alguien que tiene la capacidad de autoría de páginas HTML en dicho servidor (Ej. Webmaster) Un ataque de Cross-Site Scripting (XSS), se produce cuando un atacante logra hacer que el servidor web devuelva un Script HTML, sin contar con el nivel de permisos en el servidor para realizar dicha acción. De hecho, el atacante NO modifica nada en el servidor. El ataque ocurre cuando el código del servidor (server side-code) toma el input suplido por el usuario y repite el mismo de modo tal que los datos sean ejecutados como Script HMTL en la máquina cliente. En otras palabras, mediante este tipo de ataques se busca forzar a un sitio web a repetir el código ejecutable suministrado por un atacante, de modo tal que el mismo sea cargado en el navegador del usuario y por ende ejecutado en dicho contexto.

13. En pocas plabras Ataque del lado del cliente T écnica por medio de la cual se fuerza a un sitio web a repetir el código ejecutable suministrado por un atacante, el cual se carga en el navegador del usuario. El código normalmente está escrito en HTML o JavaScript, pero también puede extenderse a VBScript, ActiveX, Java, Flash, o cualquier otra tecnología soportada por el navegador. Objetivos probablemente Vulnerables a XSS Web bulletin boards, Weblogs, Chat rooms, Libros de Visita, Clientes de Web Mail, Formularios de Confirmación en diferentes aplicaciones. “ Cualquier aplicación que refleje el input del usuario sin validar su contenido (Input/Output).” Cross-Site Scripting (Cont.)

14. Reflected Cross-Site Scripting Se produce cuando datos provistos por un cliente web, son usados inmediatamente por el server-side script a efectos de generar una página de resultados para el usuario. Si los datos suplidos por el usuario, terminan formando parte de la página de resultado mostrada al cliente, sin que los mismos hayan sido correctamente validados/encodeados, podría resultar que dicho código sea inyectado dentro de la pagina generada dinámicamente. Ejemplos básicos: <script> document.documentElement.innerHTML=&quot;Owned by My&quot;; </script> <script>alert(document.cookie)</script> <script>while(1)alert(“DoS Exploit&quot;);</script> <EMBED SRC=http://www.pedofilia.com/movies/video.mov> <iframe src=http://mipagina.com/pagina.htm>

15. Reflected Cross-Site Scripting Demo #1

16. Reflected Cross-Site Scripting (Cont.) Que tan serio es el problema? El verdadero problema, es que el browser termina viendo un script que le es enviado a través del propio webserver, originado en el website al cual el propio browser envió su requerimiento!!! Los navegadores web y otros clientes web, a menudo se basan en un modelo de seguridad el cual permite que sólo el sitio web que emitió ciertos datos al cliente obtenga datos del mismo. Por ejemplo, si www.greatsecure.com emite una cookie a un navegador, greatsecure.com puede leer esta cookie, pero microsoft.com no. Ahora.. Suponiendo que www.greatsecure.com se encuentra hosteando una página de búsqueda que presenta un bug de XSS. Si el script es presentado a través de http://www.greatsecure.com/search.aspx y el mismo intenta acceder a la cookie generada por www.greatsecure.com ,podrá hacerlo. Esto se debe a que el navegador del cliente interpreta que el script fue originado por www.greatsecure.com .

17. Reflected Cross-Site Scripting (Cont.) Que tan serio es el problema? (Cont.) Básicamente XSS habilita acciones que son normalmente prohibidas. Cookie Access Object Model Access User Data Access Bypassing SiteLock restrictions Zone Elevation Etc.

18. Website Vulnerable Servidor que el Atacante Controla Atacante Víctima Click me!! Reflected Cross-Site Scripting (Cont.) Script SendCookieToAttacker{} /Script

19. Los POST también son explotables?

20. Los POST también son explotables? (Cont.)

21. Persistent Cross-Site Scripting Variante a menudo referida como script injection , html injection , stored o second-order injection . Casi idéntico en cuanto a su funcionalidad a los ataques de tipo Reflected Cross-Site Scripting, excepto que en este caso, los datos suplidos por el atacante son almacenados por el servidor (Ej: Database, File System, etc.) En este caso, en lugar de obligar a la víctima a realizar una petición que contiene la carga de datos maliciosa (script), el atacante almacena dicho script , para luego simplemente esperar que la víctima visite la URL en donde finalmente se mostrará el script almacenado en el servidor. Si los datos suplidos por el usuario, son almacenados por la aplicación sin que los mismos hayan sido correctamente validados/encodeados y terminan formando parte de una página ha ser mostrada cada vez que sea requerida, sin validar/encodear correctamente el output, podría resultar que dicho código sea ejecutado con cada nueva visualización.

22. Persistent Cross-Site Scripting Demo #2

23. Reflected Cross-Site Scripting (Local Files) Con frecuencia, tanto aplicaciones como sistemas operativos, instalan varios archivos HTML , adicionalmente a otros tantos archivos temporales usados por el propio navegador web. Archivos de Ayuda, templates usados para generar interfaces de usuario en forma dinámica dentro de una aplicación, etc. Estos archivos no se limitan a aquellos con extensión .htm o .html, de hecho archivos HTML también pueden ser encontrados “dentro” de otros archivos como por ejemplo: Archivo Binario de Windows (“HTML Resources”) res://D:/HTMLResExample.dll/102#<SCRIPT>alert(&quot;Hi!&quot;)</SCRIPT> . Archivos CHM (Compiled Help Module) ms-its:c:\xss\CHMDemo.chm::/searchResults.htm#<SCRIPT>alert('Hi!');</SCRIPT> Estos tres tipos de archivos pueden contener bugs de XSS.

24. Reflected Cross-Site Scripting (Local Files) Pero… los archivos locales, no son ejecutados a través de un interprete del lado del servidor tal como sucede con lenguajes tales como Perl, ASP o PHP. Como puede entonces un archivo HTML local contener un bug de tipo reflected XSS?? Los archivos HTML pueden contener scripts que “re-escriban” su propio contenido y reproduzcan los datos suplidos por el usuario. El envío de datos a un archivo HTML local, usualmente es llevado a la práctica agregando un signo numeral (#) al nombre del archivo, seguido por los datos que este se encuentra preparado para recibir como parámetro.

25. Reflected Cross-Site Scripting (Local Files) Demo #3

26. Reflected Cross-Site Scripting (Local Files) El nombre ingresado no se observa en el HTML resultante… La variable conteniendo el nombre, ha sido seteada con el valor hash del browser (location.hash) El nuevo contenido es escrito en el HTML mostrado en pantalla (A través de DOM) usando el método document.write El bwowser muestra el contenido HTML modificado permitiéndonos visualizar el nombre ingresado (Hernan) Datos No confiables están siendo mostrados sin ser filtrados y/o encodeados

27. Ciento por ciento seguro? Cuando de prevenir ataques XSS se trata, a menudo suele ser aplicado un enfoque del tipo “encodear y filtrar”, lo cual toma lugar sobre el servidor, antes de que este retorne los datos ingresados al browser del cliente. Uno de los desafíos respecto de construir un filtro efectivo del lado del servidor, radica en habilitar al servidor para que reconozca los datos de la misma forma que el cliente (browser) lo haría. Una manera de bypasear algunos filtros del lado del servidor, es enviar datos al mismo, usando un tipo de “ encoding/character set ” diferente al utilizado por el servidor.

28. Ciento por ciento seguro? (Cont.) Unicode Transformation Format 7 (UTF-7)

29. Ciento por ciento seguro? (Cont.)

30. Cómo Identificar vulnerabilidades de XSS? Identifique todos los lugares donde datos provistos por el usuario, pueden ser enviados a la aplicación. Envíe datos validos a la aplicación y observe su comportamiento. Identifique cualquier punto donde los datos enviados sean retornados al navegador o almacenados para ser mostrados en otra instancia. Lleve adelante una auditoría de código fuente.

31. Contramedidas Asuma que todo INPUT es malicioso Valide todo INPUT (Todo es TODO…) Establezca Validaciones Efectivas (Tipo, Largo, Formato y Rango) Codifique ( Encode ) el OUTPUT

32. Referencias y Lectura Complementaria Hunting Security Bugs – Microsoft Press - by Tom Gallagher, Bryan Jeffries and Lawrence Landauer - ISBN:073562187X http://ha.ckers.org/xss.html http://www.webappsec.org/projects/articles/071105.shtml http://www.microsoft.com/downloads/details.aspx?FamilyId=EFB9C819-53FF-4F82-BFAF-E11625130C25&displaylang=en http://msdn2.microsoft.com/en-us/library/ms998274.aspx http://www.bindshell.net/tools/beef/ http://www.gnucitizen.org/backframe http://xssworm.com/ http://blogged-on.de/xss/ http://ferruh.mavituna.com/xss-tunnelling-paper-and-xss-tunnel-tool-oku/ http://xss-proxy.sourceforge.net/ http://www.hernanracciatti.com.ar - http://www.sicinformatica.com.ar http://www.cert.org/tech_tips/malicious_code_mitigation

33. ¡Gracias por su Atención! Hernán M. Racciatti mailto:hracciatti@sicinformatica.com.ar http://www.sicinformatica.com.ar http://www.hernanracciatti.com.ar