XSS reflejado a través de JSON ejecutado con Burp, pero ¿cómo hacerlo en condiciones realistas?

2

Estoy probando un escenario con proxy Burp.

  1. Estoy ubicado en un sitio web https://website.com/web

  2. Hay una opción allí para eliminar un elemento, al hacer clic en él, se envía una determinada solicitud POST ( XMLHttpRequest , no se realiza ninguna actualización de la página) donde puedo insertar una etiqueta <script> :

    POST /web/deleteItem HTTP/1.1
    Host: website.com
    
    returnParameter=<script>alert('xss')</script>
    
  3. El método

    deleteItem devuelve lo siguiente:

    HTTP/1.1 200 OK
    Date: Tue, 31 Jan 2017 22:18:54 GMT
    X-XSS-Protection: 1; mode=block
    Content-Type: application/json;charset=UTF-8
    ...
    
    {"status":"SUCCESS","result":"<script>alert('xss')</script>"}
    
  4. En un sitio web del paso # 1 hay funciones de JavaScript que analizan el JSON y muestran su valor de resultado en la pantalla

  5. alert se muestra en https://website.com/web , por lo que el XSS reflejado se ejecutó con éxito.

Pero este escenario no es realista, ya que necesito atraer a un usuario al sitio web y ejecutar el XSS de alguna manera.

He intentado esto haciendo un formulario HTML POST simple y enviando los parámetros a https://website.com/web/deleteItem . Digamos que usaría phishing y el usuario enviaría el formulario.

La acción fue ejecutada, pero solo recibí una respuesta JSON . No había ninguna página en el paso # 1, por lo que en realidad no se mostraba nada como XSS, porque el usuario no estaba ubicado en https://website.com/web donde debería ejecutarse alert('XSS') . No estoy seguro de que sea posible enviar al usuario a la página # 1 y enviarlo a este JSON con XSS de alguna manera.

¿Podría haber una manera de ejecutar este escenario en condiciones realistas?

    
pregunta fing 01.02.2017 - 00:39
fuente

1 respuesta

1

La vulnerabilidad XSS reflexiva propuesta es completamente y totalmente no explotable por los navegadores modernos debido al siguiente tipo de contenido:

Content-Type: application/json;charset=UTF-8

El tipo de contenido debe ser HTML, o un tipo de contenido faltante haría el truco. Tener una aplicación de tipo de contenido / json o plano / texto son mitigaciones fuertes contra XSS.

la detección de contenido puede ser utilizada por los navegadores antiguos para ejecutar JavaScript a pesar del contenido definido -tipo. Como atacante, si el navegador de destino aún usa el rastreo de contenido, entonces el navegador también es vulnerable a errores más graves, como la ejecución remota de código drive-by.

Como señaló @Jeroen, este es un problema de validación de entrada insegura y, aunque podría no ser vulnerable al XSS reflexivo, podría dar lugar a otros problemas como las inyecciones de código de segundo orden y el XSS persistente.

    
respondido por el rook 01.02.2017 - 01:05
fuente

Lea otras preguntas en las etiquetas