HTML5 en una especificación muy conocida que permite a los desarrolladores crear aplicaciones del tipo RIA (Rich Internet Applications) y aunque incluye características que se encuentran soportadas en prácticamente todos los navegadores modernos, algunas de dichas características pueden representar problemas de seguridad muy serios que en versiones previas de HTML5 no se presentaban. HTML5 ahora es una combinación de varios elementos que permiten mejorar la navegabilidad y la experiencia de usuario gracias al uso de componentes como XMLHttpRequest2 (XHR-Level2), Web Sockets, Cross Origin Resource Sharing (CORS), localstorage, webSQL y otras mejoras relacionadas con el renderizado de componentes HTML en el navegador web. Muchas de estas nuevas características recaen directamente sobre el navegador del cliente y habilitan un espectro de ataque mucho más amplio que con versiones antiguas de la especificación, algo que los atacantes en Internet ahora buscan y explotan diariamente.
Algunos de los escenarios de ataque más comunes en navegadores y aplicaciones que soportan HTML5 y que no se encuentran debidamente aseguradas se listan a continuación.

CORS y ataques CSRF

SOP (Same Origin Policy) es una política que ha sido bastante efectiva a la hora de impedir que un dominio concreto pueda acceder a recursos de un dominio distinto. Por este motivo, gracias a SOP un dominio determinado no puede acceder directamente a los recursos (tales como cookies, árbol DOM, comunicaciones, etc) de un dominio distinto del suyo. En la especificación de HTML5, se ha implementado una característica interesante llamada CORS (Cross Origin Resource Sharing), la cual relaja un poco la política SOP y permite que los recursos de un dominio concreto se puedan compartir con otros dominios. Para hacer uso de esta característica, solamente es necesario utilizar algunas cabeceras HTTP que un navegador con soporte a CORS, entenderá y utilizará adecuadamente. El problema con este mecanismo, es que si no se configura adecuadamente, podría permitirle a un atacante acceder a recursos sensibles de un dominio concreto (como cookies de sesión) y llevar a cabo un ataque típico del tipo CSRF. Las cabeceras HTTP que le dan sentido CORS y que permiten una potencial brecha de seguridad son las siguientes:
Petición
Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Respuesta
Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Expose-Headers, Access-Control-Allow-Max-Age, Access-Control-Allow-Allow-Methods, Access-Control-Allow-Allow-Headers

Estas cabeceras son específicas para el funcionamiento de CORS y en el caso de que se encuentren incluidas en las respuestas devueltas por un servidor web, indica que CORS es soportado y que posiblemente, un atacante puede acceder a recursos compartidos a los que normalmente no debería tener autorización.

Ejemplo:
Suponiendo que la víctima tiene abierto en su navegador varias pestañas con sitios web en los que se encuentra navegando. Uno de dichos sitios tiene CORS habilitado y las respuestas a las peticiones incluyen la cabecera “Access-Control-Allow-Origin” con el valor “*” y otro de dichos sitios web es controlado por un atacante en Internet.
El atacante enviará un script malicioso al navegador de la víctima que se encargará de utilizar el objeto XMLHttpRequest para ejecutar una petición POST hacia el dominio que tiene CORS habilitado, es un dominio *distinto* del dominio del atacante y dicha petición será silenciosa y pasará inadvertida para el usuario, ya que su navegabilidad no se verá afectada y los componentes HTML que se encuentra visualizando no han tenido ningún tipo de cambio.
Con las condiciones descritas anteriormente, el atacante podrá acceder a datos sensibles del usuario que se encuentra autenticado en la aplicación web vulnerable, accediendo de esta forma a recursos tan importantes como la cookie de sesión del sitio web en el que el usuario se ha identificado, dando lugar a una fuga de información y posteriormente a un ataque de suplantación de identidad utilizando la información de acceso (cookie de sesión) del usuario identificado. En efecto, estamos hablando de un ataque clásico del tipo CSRF.
La siguiente imagen enseña un sitio web con CORS habilitado y como se puede apreciar, la cabecera “Access-Control-Allow-Origin” tiene el valor “*”

Si el usuario se encuentra logueado y navega a un sitio web controlado por un atacante, el cual contiene un script como el que se enseña a continuación, el atacante podrá acceder a información sensible que le permitirá suplantar la identidad del usuario.

[sourcecode language=»javascript»]
<script language= “javascript” type= “text/javascript">
function corsrequest() {
var http;
http = XMLHttpRequest();
http.open(“POST”, “http://vulncors-site.com/”, true);
http.setRequestHeader(“Content-Type”, “text/plain”);
http.withCredentials= “true”;
http.onreadystatechange = function() {
if (http.readyState == 4) {
var response = http.responseText
document.getElementById(“responseFromVictim”).innerHTML = response;
}
}
http.send(null)
}
</script>
[/sourcecode]

Como se puede apreciar, el atacante realizará una petición “POST” al sitio web vulnerable con el fin de recuperar información sobre el usuario identificado en el sistema, para tal fin incluye el atributo “withCredentials” con el valor “true” para que el servidor web replique en la respuesta el contenido de la cookie de sesión del usuario. Hasta este punto, el atacante tiene todos los elementos necesarios para suplantar la identidad del usuario sin mayores dificultades, produciendo una vulnerabilidad del tipo CSRF.

CORS y CORJacking
Continuando con la explicación sobre las posibles brechas de seguridad que pueden incluirse con CORS, otro tipo de vulnerabilidad que se presenta en las aplicaciones web RIA con HTML5 es la conocida como CORJacking, la cual consiste en la capacidad que tiene un atacante de modificar dinámicamente la estructura DOM de un sitio web con CORS habilitado y mal configurado. De esta forma, el atacante podrá modificar algunos atributos de los elementos cargados en el árbol DOM del sitio web con CORS habilitado e incorrectamente configurado, para controlar la interacción del usuario con los contenidos del sitio web vulnerable.

Ejemplo:
Suponiendo que una aplicación web con CORS habilitado y mal configurado tiene un elemento dinámico como por ejemplo un fichero Flash, SilverLight o un fichero de vídeo o audio. Un atacante puede suplantar dicho contenido navegando por la estructura DOM y modificar la ubicación de dicho recurso por otra ruta que apunte a un recurso cuidadosamente creado por el atacante. Si el contenido dinámico servido por el atacante, tiene la misma apariencia visual que el contenido original de la aplicación web, el usuario no notará la diferencia y creerá que interactúa con el elemento original. Más grave aun, cuando se trata de contenidos Flash o similares que intervienen en operaciones de negocio de la aplicación, como por ejemplo un componente en Flash para recibir las credenciales de acceso de los usuarios.

Etiquetas, atributos y eventos HTML5 inseguros

Algunos etiquetas de las especificaciones anteriores de HTML contienen atributos y eventos muy interesantes que permiten que un usuario pueda interactuar de una forma mucho más amigable con dichos elementos, sin embargo, muchos de los nuevos atributos y etiquetas en HTML5 permiten la ejecución de código JavaScript, algo de lo que se podría aprovechar un atacante para producir vulnerabilidades XSS o CSRF.

Ejemplo:
Hay varios atributos y etiquetas nuevas en HTML5 que permiten la ejecución de código JavaScript de forma nativa. Una de las más comunes, es la etiqueta “video” y su atributo “onerror” que se activará automáticamente cuando el recurso que debe cargar la etiqueta “video” no puede cargarse.

[sourcecode language=»javascript»]
<video source onerror="javascript:alert(‘XSS’)">
[/sourcecode]

El atributo “autofocus” que en HTML5 se encuentra disponible en todos los elementos HTML de entrada, también puede representar un problema cuando no se valida adecuadamente el valor del atributo “onfocus” en el momento en el que se recarga la página.

[sourcecode language=»javascript»]
<input autofocus onfocus= alert(‘XSS’)>
<select autofocus onfocus= alert(‘XSS’)>
<textarea autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= write(‘XSS’)>
[/sourcecode]

Otro atributo potencialmente peligroso es “formaction” de la etiqueta “form”, el cual también admite la ejecución de código JavaScript.

[sourcecode language=»javascript»]
<input autofocus onfocus= alert(‘XSS’)>
<select autofocus onfocus= alert(‘XSS’)>
<textarea autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= write(‘XSS’)>
[/sourcecode]

Existen varias etiquetas y atributos que son consideradas peligrosas si no se aplican las validaciones de datos adecuadas, para ver una lista mucho más completa, se recomienda visitar el sitio HTML5 Security Cheatsheet: https://html5sec.org/

En una próxima entrada, más sobre riesgos y vulnerabilidades cuando en el uso de las nuevas características implementadas en HTML5

Un saludo y Happy Hack!