Cross-Site Scripting: Poor Validation

Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.

El uso de determinadas construcciones de codificación como, por ejemplo, la etiqueta <c:out/> con el atributo escapeXml="true" (el comportamiento predeterminado), impide algunos de los ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que excedan los básicos <, >, & y " que estén codificados en código HTML, y aquellos que excedan <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas construcciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen de forma estática los datos, Fortify Static Code Analyzer informa sobre las detecciones de ataques de Cross-Site Scripting incluso cuando se realiza la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, un origen que no es de confianza suele ser una solicitud web y, en el caso de XSS persistente (también conocido como almacenado), es el resultado de una consulta de base de datos.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Example 1: The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user via the <c:out/> tag.

Employee ID: <c:out value="${param.eid}"/>

El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Example 2: The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name via the <c:out/> tag.

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <c:out value="${name}"/>

Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Example 3: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.

...
        WebView webview = (WebView) findViewById(R.id.webview);
        webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(URLEncoder.encode(url));
...

Si el valor de url comienza por javascript:, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 3, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Struts 2). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.