Vectores de ataque del HTML 5
Brevísimo resumen del HTML
Corria el año 1995 cuando un organismo llamado IETF (Internet Engineering Task Force), logró organizar a un grupo de trabajo con el fin de publicar un estándar para un lenguaje de marcado, inventado por Tim Berners-Lee años antes. Fue el 22 de septiembre de ese año cuando vio la luz el primer estándar del, hoy ya famoso, HTML. Curiosamente, a esta primera revisión oficial del lenguaje, se la denominó HTML 2.0.
Un año más tarde, HTML “cambió de manos” y paso a ser la W3C (World Wide Web Consortium), la encargada de los nuevos estándares.
El 24 de Abril de 1998 se publicó una versión corregida, de una publicación original del 18 de Diciembre de 1997, llamada HTML 4.0. Esta supuso un gran salto desde las versiones anteriores. Entre sus novedades más destacadas se encontraban las hojas de estilos CSS, la posibilidad de incluir pequeños programas o scripts en las páginas web, mejora de la accesibilidad, tablas complejas y mejoras en los formularios.
A partir de ahí, y hasta la salida del HTML5, se han ido realizando modificaciones y revisiones del estándar, convirtiendo la web en lo que conocemos hoy en día, como dice Oscar Campos (genbetadev.com): “Hoy en día, la web es un sitio maravilloso donde procrastinar como campeones y navegar como jamás Chanquete lo hubiera siquiera imaginado.”
¿Porqué HTML 5?
Como he comentado anteriormente, este estándar tiene ya unos añitos y no tiene en cuenta muchas de las funcionalidades a las que estamos acostumbrados hoy en día. Han tenido que ser los desarrolladores, usando plugins de terceros (cómo Macromedia/Adobe Flash) o los extraordinarios Framework de JavaScript, los que han convertido un simple escaparate de documentos, en verdaderas aplicaciones web.
Las últimas versiones de la mayoría de los navegadores que conocemos (Internet Explorer, Firefox, Safari, Chrome y Opera) incorporan ya la posibilidad de usar las nuevas etiquetas y propiedades de HTML5, pero como cada uno lo implementa a su manera, pueden aparecer “bugs”, más propios del navegador que lo implementa, que del lenguaje en si.
¿Dónde está el peligro?
Parte del peligro radica en que se delegan ciertas comprobaciones de seguridad al desarrollador web, y como todos los que estamos en esto sabemos, lo urgente nunca deja tiempo a lo importante. Esto me recuerda cierta frase que escuché hace algún tiempo, cuando un desarrollador web se excusaba por un fallo grave de seguridad: “A nosotros nos han dicho que funcione, no que sea seguro”.
Cross-Document Messaging
HTML5 integra una nueva API llamada postMessage que permite a un script de un dominio, pasar datos a uno que corre en otro (HTML 4 no permite que páginas de midominio.com pase datos a páginas/scripts que estén en tudominio.com). Para asegurar que las peticiones no son maliciosas, postMessage incluye varias propiedades, que el desarrollador puede usar para verificar el origen de la petición, pero este chequeo no es obligatorio pudiendo dejar scripts expuestos a peticiones maliciosas.
Local Storage
Desde HTML5, se puede acceder a una base de datos local SQL. Este almacenamiento offline (y en local) puede acelerar notablemente las aplicaciones web, especialmente si estas necesitan un acceso a datos constante. Está claro que no todo son ventajas, y como muestra de ello, leer el post de Jose Miguel Holguín en este mismo blog (evercookie never forget), en el que nos detalla como usar esta característica para fijar cookies de navegador de manera persistente.
Nuevas etiquetas
Gran parte de la funcionalidad multimedia que en HTML4 proporcionaban los plugins de terceros, se pueden usar ahora de forma nativa (<audio>, <video> y <svg>), sin necesidad de éstos, que consumen recursos extra y, en ocasiones, causan inestabilidad en el navegador. Este paso delega en los navegadores la implementación de esos elementos, que resulta en posibles “bugs” explotables.
Nuevos atributos
En esta nueva especificación tenemos nuevos atributos muy interesantes, que nos pueden aportar grandes ventajas en las aplicaciones web. Pero, como siempre, pueden ser usados por personas con poco trabajo maliciosas. Por ejemplo, el nuevo atributo autofocus centra de forma automática el navegador en un elemento específico. Esto podría ser aprovechado para evitar que el usuario maneje el navegador a su antojo, ofreciendo sólo acceso a una ventana con código malicioso. Otros atributos, como poster (muestra una imagen en lugar del video si este no se encuentra disponible) y srcdoc (especifica directamente el código HTML en un iframe) permitirían que elementos ejecuten recursos externos, dando vía libre al malware.
Client-side input validation
Hasta que se extendió el uso del AJAX, los desarrolladores web hacían la validación de los datos de entrada en el servidor (me váis a permitir la licencia de no llamar desarrolladores web a aquellos que sólo delegan la validación de lado del cliente, porque eso es lo que pasa cuando dejas que los diseñadores hagan webs), justo después de llamar al método submit() del formulario, pero este método no ofrece una buena experiencia de usuario.
HTML5 ofrece la posibilidad de client-side input validation, lo que permite que las aplicaciones trabajen de manera más eficiente de cara al usuario. Sin embargo, definiciones de validación erróneas pueden hacer que los usuarios se salten los chequeos de validación (o en algunos casos provoquen denegaciones de servicio).
En mi humilde opinión, y puedo equivocarme, esto puede ser una mejora y sirve ahorrarnos rutinas de validación JavaScript, haciendo el código más sencillo y entendible, pero nunca se han de delegar dichas comprobaciones únicamente al cliente.
Conclusiones
Existen muchas más novedades en las especificaciones del HTML5, y lo que está claro es que HTML5 es una mejora considerable con respecto a su antecesor, pero como dentro de todo lo bueno siempre hay algo malo, por lo que habrá que estar atentos a cómo protegernos de los villanos de la web.
Por Guillermo Mir en http://www.securityartwork.es/2011/07/07/vectores-de-ataque-del-html-5/
