Bienvenidos a un nuevo post en Byte Mind, en este caso vamos a explicar en qué consisten las vulnerabilidades basadas en DOM, qué tipos hay, ejemplos de como explotar las mismas y cómo es posible evitar ser vulnerables a las mismas, así que sin más dilación vamos a ello.
Índice
¿Qué es el DOM?
El Document Object Model (DOM) es una representación jerárquica de los elementos existentes en una página web. Los sitios web pueden utilizar Javascript para manipular nodos y objectos del DOM, así como sus propiedades.
La manipulación del DOM en sí no es un problema, de hecho, es una parte integral de cómo funcionan los portales web modernos. Sin embargo, Javascript puede manejar datos de forma poco seguro permitiendo habilitar que sea vulnerable a diferentes tipos de ataques.
Las vulnerabilidades basadas en DOM surgen cuando un sitio web contiene Javascript que toma un valor que el atacante puede controlar, conocido como fuente (source en inglés) y lo pasa a una función peligrosa, conocida como sumidero (sink en inglés).
Para que queden más claros estos conceptos de source y sink vamos a explicarlos en detalle a continuación.
Source
Un source o fuente es una propiedad de Javascript que acepta datos controlados potencialmente por un atacante. Un ejemplo sería la propiedad location.search porque lee la entrada de la cadena introducida, lo que es fácil de controlar por un atacante. En última instancia, cualquier propiedad que pudiese ser controlada por un atacante es una fuente potencial, esto incluiría la URL de referencia (expuesta por la cadena document.referrer), las cookies del usuario (expuestas por la cadena document.cookie) y los mensajes web.
Sink
Un sink o sumidero es una función de Javascript potencialmente peligrosa o un objecto DOM que podría causar efectos no deseados si se le pasan datos controlados por un atacante.
Pongamos un ejemplo para verlo más claro, la función eval() es un sink porque procesa el argumento que se le pasa como Javascript. Por ejemplo un sink HTML sería document.body.innerHTML porque permite que un atacante pueda inyectar HTML malicioso pudiendo con ello la ejecución de código arbitrario.
Vulnerabilidades basadas en DOM
En los siguientes puntos se tratarán las diferentes vulnerabilidades basadas en DOM.
Ajax request-header manipulation
El uso de Ajax permite que un sitio web realice solicitudes asíncronas al servidor para que las aplicaciones web puedan modificar de forma dinámica el contenido de una página sin la necesidad de recargarla por completo. Sin embargo, las vulnerabilidades de manipulación del encabezado de solicitud Ajax surgen cuando un script pinta datos que son controlables por el atacante debido al encabezado de solicitud que se emite utilizando un objecto XmlHttpRequest. En este caso, un atacante, podría utilzar esta vulnerabilidad para construir una URL, que si la visita otro usuario, establezca un encabezado arbitrario en la solicitud posterior, lo que podría utilizar como punto de partida para encadenar otro tipo de ataques, aumentodo con ello la gravedad potencial de la vulnerabilidad.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 2 3 4 5 |
XMLHttpRequest.setRequestHeader() XMLHttpRequest.open() XMLHttpRequest.send() jQuery.globalEval() $.globalEval() |
Client-side JSON Injection
Las vulnerabilidades de inyección de JSON basadas en DOM surgen cuando un script incorpora datos que pueden ser modificados por un atacante en una cadena que se analiza como una estructura de datos JSON, y posteriormente, son procesados por la aplicación. En este caso puede utilizar dicho comportamiento para construir una URL, que si es visitada por otro usuario, provocará que se ejecute código arbitrario en el mismo.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 2 3 |
JSON.parse() jQuery.parseJSON() $.parseJSON() |
Client-side SQL Injection
Las vulnerabilidades de SQLI del lado del cliente surgen cuando una secuencia de comandos incorpora datos que pueden ser modificados por un atacante en una consulta SQL no segura. Un atacante podría aprovecharse de esta vulnerabilidad para construir una URL, que al ser visitada por otro usuario, ejecutase una consulta SQL arbitraria dentro de la base de datos local del navegador del usuario.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 |
executeSql() |
Client-side XPATH Injection
Las vulnerabilidades de inyección de XPath basadas en DOM surgen cuando un script incorpora datos que pueden ser modificados por un atacante en una consulta de XPATH. Un atacante podría aprovecharse de este comportamiento para construir una URL, que al ser visitada por otro usuario de la aplicación, desencadenara la ejecución de una consulta arbitraria, provocando que el sitio web recupere o procese diferentes datos.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 2 |
document.evaluate() element.evaluate() |
Cookie manipulation
En algunos casos hay vulnerabilidades que permiten a un atacante manipular datos que normalmente no controlan, con las cookies, son capaces de transformar los tipos de datos que normalmente son seguros en potenciales fuentes de ataque, en este caso la vulnerabilidad surge cuando el atacante es capaz de escribir en el valor de la cookie de un usuario.
En muchos casos, los sink, son en gran medida inofensivos por sí mismos, pero los ataques de manipulación de cookies basados en DOM demuestran como vulnerabilidades de baja gravedad, en ocasiones, pueden utilizarse como una parte de una cadena de explotación para un ataque altamente dañino.
Por ejemplo, si Javascript escribe datos de un source en document.cookie sin sanear los mismos, un atacante podría modificar el valor de una cookie para inyectar código malicioso:
|
1 |
document.cookie = 'cookieName=' + location.hash.slice(1); |
Si el sitio web refleja de forma insegura los valores de las cookies sin codificarlos en HTML, el atacante podría utilizar estas técnicas para explotar ese comportamiento.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 |
document.cookie |
Denial of service
Las vulnerabilidades de denegación de servicio basadas en DOM ocurren cuando un script pasa datos modificables por un atacante de forma insegura a un API de plataforma mal configurada, lo que podría provocar en un alto consumo de recursos en el servidor. Esto puede tener efectos secundarios si el navegador restringe la funcionalidad del sitio web, por ejemplo, rechazando los intentos de almacenar datos o matando procesos con un excesivo consumo.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 2 |
requestFileSystem() RegExp() |
Document-Domain manipulation
Las vulnerabilidades de manipulación de dominios de documentos surgen cuando una secuencia de comandos utiliza datos modificables por un atacante para establecer un valor a la propiedad document.domain.
Los navegadores utilizan la propiedad document.domain para aplicar la misma política de origen. Si dos páginas de distintos orígenes establecen explícitamente el mismo valor, ambas pueden interactuar sin restricciones. Si un atacante puede hacer que una página del sitio web objetivo y otra página que controla establezcan el mismo valor en dicha propiedad, entonces el atacante podría comprometer completamente la página de destino a través de la página que ya controla. Esto abriría las mismas posibilidades de explotación que las vulnerabilidades de Cross-Site-Scripting (XSS).
Genralmente los navegadores ya imponen algunas restricciones para impedir que puedan llevarse a cabo este tipo de ataques, sin embargo hay dos puntos a tener en cuenta con esto:
- Los navegadores permiten el uso de dominios secundarios o principales, por lo que el atacante podría cambiar el dominio de la página de destino al de un sitio web relacionado con una postura más débil en cuanto a seguridad.
- Algunas peculiaridades del navegador pueden permitir cambiar a dominios que no estén relacionados.
Estas advertencias significan que la capacidad de manipular el valor de la propiedad document.domain representan una vulnerabilidad de seguridad cuya gravedad podría ser similar a un XSS normal.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 |
document.domain |
DOM Clobbering
La vulnerabilidad de DOM Clobbering o destrucción del DOM es una técnica en la que se inyecta HTML en una página para manipular el DOM y, en última instancia, cambiar el comportamiento de JavaScript en la página. El DOM Clobbering es particularmente útil en los casos en que un XSS no es posible, pero puede controlar parte del código HTML en una página donde los atributos id o name están incluidos en la lista blanca por el filtro HTML. La forma más común de DOM Clobbering utiliza un elemento de anclaje para sobrescribir una variable global, que luego es utilizada por la aplicación de forma no segura, como generar una URL de secuencia de comandos dinámica.
El término clobbing proviene del hecho de que está “golpeando” una variable global o propiedad de un objeto y sobrescribiéndola con un nodo DOM o una colección HTML en su lugar.
Por ejemplo, puede usar objetos DOM para sobrescribir otros objetos de JavaScript y explotar nombres no seguros, como submit, para interferir con la función real de un formulario.
Este tipo de ataque es bastante extenso, por lo que dedicaré a futuro un post completo a esta vulnerabilidad, a sus técnicas de explotación y a como evitar que la misma afecte a nuestras aplicaciones.
DOM data manipulation
Las vulnerabilidades de manipulación de datos DOM surgen cuando un script escribe datos que pueden ser modificados por un atacante en un campo existente en el DOM y que se utiliza dentro de la interfaz visible del usuario o la lógica del lado del cliente. En este caso el atacante podría llegar a modificar la apariencia o el comportamiento de la interfaz del usuario, provocando con ello la ejecución de código arbitrario en el navegador del usuario. Este tipo de ataques pueden explotarse mediante ataques basados en DOM reflejado y almacenado.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
script.src script.text script.textContent script.innerText element.setAttribute() element.search element.text element.textContent element.innerText element.outerText element.value element.name element.target element.method element.type element.backgroundImage element.cssText element.codebase document.title document.implementation.createHTMLDocument() history.pushState() history.replaceState() |
DOM XSS
El ataque DOM XSS es aquel que se realiza realizando un ataque de Cross Site Scripting en el DOM de una página web. Una aplicación vulnerable permite ejecutar código malicioso desde su frontend, debido a una falta de validación de las entradas de un usuario.
Toda aplicación web puede ser representada mediante un DOM, al cual se accederá a través de la versión para los desarrolladores de la app, que puede ser vista a través de cualquier navegador.
HTML5 storage manipulation
Las vulnerabilidades de HTML5-storage manipulation ocurren cuando un script almacena datos controlables por un atacante en el almacenamiento del navegador (como localStorage o sessionStorage). Un atacante podría ser capaz de utilizar este comportamiento para construir una URL, que al ser visitada por otro usuario, provocará que el usuario almacene datos controlados por el atacante.
Este comportamiento no formaria una vulnerabilidad como tal por sí mismo, pero si la aplicación lee y procesa datos de una forma poco segura, el atacante podría realizar otro tipo de ataques como un Cross-Site-Scripting o una inyección de javascript.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 2 |
sessionStorage.setItem() localStorage.setItem() |
Javascript injection
Las vulnerabilidades de inyección de código javascript basadas en DOM ocurren cuando un script ejecuta código controlable por el atacante como Javascript. El atacante puede ser capaz de utilizar una vulnerabilidad para construri una URL que pueda povocar la ejecución arbitraria de código cuando un usuario la visitase.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 2 3 4 5 6 7 8 9 10 |
eval() Function() setTimeout() setInterval() setImmediate() execCommand() execScript() msSetImmediate() range.createContextualFragment() crypto.generateCRMFRequest() |
Link manipulation
Las vulnerabilidades de manipulación de enlaces basadas en DOM surgen cuando un script escribe datos controlables por un atacante en un objetivo de navegación dentro de la página actual, como un enlace en el que se puede hacer clic o la URL de envío de un formulario. Un atacante podría usar esta vulnerabilidad para construir una URL que, si la visita otro usuario de la aplicación, modificará el destino de los enlaces dentro de la respuesta.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 2 3 |
element.href element.src element.action |
Local file-path manipulation
La vulnerabilidad de Local file-path manipulation ocurre cuando un atacante es capaz de controlar los datos que se pasan al script cuando la api trabaja con parametros que acceden a ficheros locales. En este caso, el atacante, sería capaz de explotar esta vulnerabilidad para construir una URL, que cuando sea visitada por otro usuario, cargue un fichero arbitrario local.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 2 3 4 5 6 |
FileReader.readAsArrayBuffer() FileReader.readAsBinaryString() FileReader.readAsDataURL() FileReader.readAsText() FileReader.readAsFile() FileReader.root.getFile() |
Open Redirection
La vulnerabilidad de Open Redirection basada en DOM surge cuando un script escribe datos controlables en el destino de una redirección de forma no segura. Un atacante puede usar esta vulnerabilidad para construir una URL que, si la visita otro usuario de la aplicación, provocará una redirección a un dominio externo arbitrario.
Este comportamiento se puede aprovechar para facilitar los ataques de phishing contra los usuarios de la aplicación. La capacidad de usar una URL de aplicación auténtica, dirigida al dominio correcto y con un certificado SSL válido (si se usa SSL), da credibilidad al ataque de phishing porque muchos usuarios, incluso si verifican estas funciones, no notarán la redirección posterior a un dominio diferente.
Taint-flow
Muchas vulnerabilidades basadas en DOM se remontan a problemas en la forma en que el código del lado del cliente manipula los datos que son controlables por el atacante.
Estas vulnerabilidades surgen fundamentalmente cuando un sitio web pasa datos de un source a un sink y que posteriormente maneja dichos datos de forma insegura en el contexto de la sesión del cliente.
El source más común es la URL, a la que normalmente se accede con el objeto location. En este caso, un atacante, podría construir un enlace malicioso para enviar a una víctima a una página vulnerable con un payload en la cadena de consulta y fragmentar partes de la URL. Vamos a verlo en detalle con un ejemplo, visto el siguiente código:
|
1 2 3 4 |
goto = location.hash.slice(1) if (goto.startsWith("https:")) { location = goto; } |
El anterior código sería vulnerable a la redirección abierta basada en DOM porque el source location.hash se maneja de forma insegura. Si la URL contiene un fragmento hash que comienza con https: este código extrae el valor de la propiedad location.hash y lo establece como la propiedad location de window. De esta forma un atacante podría aprovechar la vulnerabilidad construyendo una URL similar a la siguiente:
|
1 |
https://original-website.com/example#https://malicious-website.com |
Cuando la víctima visite esta URL, Javascript establecerá el valor de la propiedad location en https://malicious-website.com, lo que automáticamente redirigirá a la víctima al portal malicioso. Este tipo de comportamiento se podría explotar de forma muy sencilla para construir por ejemplo un ataque de phishing.
Web message manipulation
Las vulnerabilidades de Web message manipulation surgen cuando un script envía datos controlables por un atacante como un mensaje a otro documento dentro del navegador. Un atacante puede utilizar los datos del mensaje como fuente mediante la construcción de una página web que, si la visita un usuario, hará que el navegador del usuario envíe un mensaje que contenga datos que están bajo el control del atacante.
A continuación se muestran algunos de los principales sink que pueden conducir este tipo de vulnerabilidad:
|
1 |
postMessage() |
WebSocket-URL poisoning
El envenenamiento de WebSocket-URL ocurre cuando un script usa datos controlables como la URL de destino de una conexión WebSocket. Un atacante puede usar esta vulnerabilidad para construir una URL que, si la visita otro usuario, hará que el navegador del usuario abra una conexión WebSocket a una URL que está bajo el control del atacante.
Como evitar ser vulnerables a ataques basados en DOM
En verdad no hay una sola acción a tomar para eliminar por completo la amenaza de los ataques basados en DOM, sin embargo, en términos generales, la forma más efectiva de evitarlas es evitar permitir que los datos de cualquier fuente de confianza alteren de forma dinámica el valor que se transmite, realizando una correcta validación de los datos que se envían y se reciben, etc.
Si la funcionalidad deseada de la aplicación significa que este comportamiento es inevitable, las defensas deben implementarse dentro del código del lado del cliente. En muchos casos, los datos relevantes se pueden validar en una lista blanca, permitiendo solo el contenido que se sabe que es seguro. En otros casos, será necesario desinfectar o codificar los datos. Esta puede ser una tarea compleja y, según el contexto en el que se inserten los datos, puede implicar una combinación de escape de JavaScript, codificación de HTML y codificación de URL, en la secuencia adecuada.
Esto ha sido todo por el momento, espero les sea de ayuda en su día a día y si tienen cualquier duda o sugerencia tienen a su disposición la sección de comentarios.
