DOMXSS - ¿Es el contenido del campo de entrada un Vector de ataque?

0

Un ejemplo típico para DOMXSS es que el código vulnerable procesa descuidadamente la parte después de la marca hash como en https://www.example.org/path/param1=val1&...#PAYLOAD_HERE sin validación. Por ejemplo, la cadena podría asignarse a través de innerHTML a algún elemento DOM. (O uno de los muchos métodos de jQuery, como html() , before() , prepend() y varios más).

Ahora, en comparación con Reflected XSS, donde los parámetros de URL, los parámetros de formulario u otros parámetros (por ejemplo, como parte de un cuerpo con formato JSON) pueden contener la carga útil, a menudo son entradas que se pueden ingresar en los campos de formulario. Por ejemplo, la URL https://www.example.org/?search=query es prácticamente siempre el resultado de que el usuario ingrese query en un campo de búsqueda. (Al menos, ese es el caso de uso previsto). Ahora, es posible omitir el proceso de ingresar la cadena de consulta en el campo de formulario enviando la URL de consulta directamente. Similar para POST, aunque esto es un poco más complejo (lo que no es el punto aquí; por el bien de la discusión, doy por sentado que es posible).

Por lo tanto, si la aplicación es vulnerable a Reflected XSS a través de un campo de entrada, prácticamente siempre es posible crear una URL maliciosa que, al hacer clic en ella, explote la vulnerabilidad.

Sin embargo, me parece que esto no es válido para DOMXSS. Si una aplicación tenía un campo de entrada que usa su contenido sin cuidado para actualizar algún elemento DOM sin ninguna validación, entonces claramente se podría inyectar scripts arbitrarios en el DOM. Considere, por ejemplo, una aplicación hipotética que tiene un campo de entrada con id input_field y un elemento de destino como p , div , span o lo que sea con id target , y código JavaScript con una línea como esta :

document.getElementById("target").innerHTML =
    document.getElementById("input_field").value;

Aquí el contenido del campo de entrada no se envía ni se devuelve como se haría para Reflected XSS.

La pregunta para mí es: ¿podría ser explotado por un atacante (sin explotar un ataque XSS anterior)?

    
pregunta countermode 28.09.2018 - 09:50
fuente

1 respuesta

1

Eso sería difícil de explotar sin combinarlo con otra vulnerabilidad. ¿Cómo entraría el código de explotación en la entrada? Supongo que combinarlo con la corrección de UI o algo así podría haber funcionado, pero no veo ninguna forma clara de explotarlo. Podría ser visto como un auto-XSS.

    
respondido por el Erlend 29.09.2018 - 08:25
fuente

Lea otras preguntas en las etiquetas