El CERT publica un informe en el que se señalan los riesgos de la generación dinámica de páginas con contenido bajo el control del usuario. Aunque estos problemas son conocidos desde «siempre», existen multitud de servidores y servicios vulnerables.
La inclusión de código HTML o «scripts» javascript en formularios y foros de discusión es un hecho conocido y explotado desde siempre. Se utiliza habitualmente, de forma inocua, para poder introducir caracteres en itálica o negrita, o para introducir imágenes. No obstante, la misma idea puede ser utilizada para atacar tanto a otro usuario como al propio servidor.
Ataques al servidor:
Aunque es poco habitual, es posible que la generación dinámica de una página se emplee para alimentar otro generador dinámico, lo que puede ocasionar problemas, por ejemplo, si un usuario utiliza directivas SSI (Server Side Include) de forma maliciosa. Si la programación del sistema no es cuidadosa, es posible ejecutar código arbitrario en el servidor.
Ataques de un usuario a otro:
Con los numerosos fallos de seguridad que se encuentran cada d¡a en los servidores web, es trivial introducir c¢digo que mate un navegador o cuelgue una m quina. Todos los usuarios con navegador vulnerable que accedan a la p gina con el c¢digo malicioso sufrir n el ataque.
Lo m s interesante de este ataque es que es desencadenado por el propio usuario, por un lado, y que el c¢digo malicioso est albergado en un servidor en el que el usuario conf¡a (por ejemplo, un servicio de noticias o foros de discusi¢n).
Tambi’n se puede utilizar a un usuario inocente para atacar a una tercera entidad. Por ejemplo, un enlace como:
en un sitio popular, puede provocar miles de ataques al servidor indicado (un ataque «real» supondr¡a la utiilizaci¢n de JavaScript o similar para que cada atacante realizase un ataque inteligente e informase del resultado al atacante original).
Ataques de un cliente a s¡ mismo
Este ataque se desencadena, t¡picamente, cuando un usuario sigue un enlace que le proporciona un atacante. Por ejemplo:
Pulse aqu¡ para ver lo que «ejemplo.com» dice de HispaSec
Otra posibilidad ser¡a injectar en un sitio «confiable» en el que se nos identifique por «cookie», c¢digo como:
http://www.ejemplo.com/cgi-bin/test-cgi?a=
Cuando un usuario sigue ese enlace, estar haciendo una petici¢n a «malvado.com» con una URl que refleja sus cookies para «www.ejemplo.com». Las cookies, por consiguiente, estar n disponibles en los logs de acceso de «malvado.com»
Utilizar a un usuario inocente para subvertir la seguridad ajena:
Un atacante puede conseguir que un usuario inocente, con determinados privilegios en una red, ejecute ¢rdenes invocando esos privilegios.
Por ejemplo:
Si el administrador de este hipot’tico servidor accede a una p gina con una URL como la anterior, podr¡a perder su propio servicio. El atacante no puede ejecutar el programa «apagar», pero el administrador, autentificado con su IP, s¡ podr¡a.
En general, esta vulnerabilidad permite que un atacante ejecute c¢digo (java o scripts) en la m quina del usuario con los privilegios del servidor que env¡a la informaci¢n lo que puede, entre otras cosas, hacer que el navegador del usuario realice acciones sensibles. Este ataque, adem s, es perfectamente desplegable a trav’s de SSL, ya que los datos maliciosos los env¡a un servidor «confiable».
Una variedad interesante del ataque es aquel que aprovecha el hecho de que, en muchas ocasiones, los servidores web muestran una p gina por defecto cuando se introduce una URL inexistente. Si dicha p gina se genera de forma din mica, es posible inyectar contenidos esporeos dentro suya.
Este tipo de ataques es posible tambi’n a trav’s de correo electr¢nico y news, si se visualizan mensajes HTML.
Soluci¢n:
– Inhabilitar la ejecuci¢n de Java y JavaScript en los navegadores ayuda, aunque no soluciona todos los problemas.
– Los programadores de p ginas din micas deben filtrar convenientemente todos los datos bajo control del usuario. Ello inlcuye no solo la URL, sino tambi’n cookies, «referer», etc.
– Todas las p ginas generadas deben especificar un «charset» de forma expl¡cita, de forma que se pueda reconocer claramente los caracteres especiales (recordemos, por ejemplo, que Unicode utiliza c¢digos de 16 bits que son alias de «<"). Una posibilidad es codificar al principio de cada p gina: content=»text/html; charset=ISO-8859-1″>
– Filtrar adecuadamente los caracteres especiales: «<", ">«, «&», «%», comillas, etc. Hay que tener en cuenta que en numerosas ocasiones los caracteres especiales dependen del contexto. Es preferible tener una lista de caracteres seguros, m s que una lista de lo que no se debe aceptar. El problema se agrava porque muchos navegadores son relajados a la hora de interpretar documentos HTML, dado que en muchas ocasiones se codifican a mano y suelen contener errores.
M s Informaci¢n:
CERT Advisory CA-2000-02
Malicious HTML Tags Embedded in Client Web Requests
http://www.cert.org/advisories/CA-2000-02.html
K-021: Malicious HTML Tags Vulnerability
http://ciac.llnl.gov/ciac/bulletins/k-021.shtml
Understanding Malicious Content Mitigation for Web Developers
http://www.cert.org/tech_tips/malicious_code_mitigation.html
Frequently Asked Questions About Malicious Web Scripts Redirected by Web Sites
http://www.cert.org/tech_tips/malicious_code_FAQ.html
Cross Site Scripting Info
http://www.apache.org/info/css-security/
Cross Site Scripting Info: Encoding Examples
http://www.apache.org/info/css-security/encoding_examples.html
Parche para Apache 1.3.11
http://www.apache.org/info/css-security/apache_1.3.11_css_patch.txt
Web Application Developer Security Advisory
http://developer.iplanet.com/docs/technote/security/cert_ca2000_02.html
Cross Web Site Scripting Vulnerability
http://developer.iplanet.com/docs/technote/security/cert_404.html
Information on Cross-Site Scripting Security Vulnerability
http://www.microsoft.com/technet/security/crssite.asp
Quick Start: What Customers Can Do to Protect Themselves from Cross-Site Scripting
http://www.microsoft.com/technet/security/crsstQS.asp
Cross-Site Scripting Security Exposure Executive Summary http://www.microsoft.com/technet/security/ExSumCS.asp Cross-site Scripting Overview
http://www.microsoft.com/technet/security/CSOverv.asp
Cross-Site Scripting: Frequently Asked Questions
http://www.microsoft.com/technet/security/crsstFAQ.asp
HOWTO: Prevent Cross-Site Scripting Security Issues
http://www.microsoft.com/technet/support/kb.asp?ID=252985
How Active is Active Content in Email?
http://www.ntbugtraq.com/default.asp?sid=1&pid=47&aid=56
Outlook and IE
http://www.jmu.edu/info-security/engineering/issues/apps/outlook.htm
DHTML makes HTTP_REFERER an unreliable sanity check
http://www.securiteam.com/securitynews/DHTML_makes_HTTP_REFERER_an_unreliable_sanity_check.html
Jesos Cea Avi¢n
jcea@hispasec.com
