Secuencias de comandos entre sitios en una clave única

1

¿Es posible realizar un ataque de secuencias de comandos entre sitios ingresando mi secuencia de comandos en un campo que es necesario para que coincida con un valor específico?

Estoy escaneando una aplicación en busca de vulnerabilidades, y mi herramienta de escaneo (OWASP ZAP) está devolviendo varias vulnerabilidades de secuencias de comandos entre sitios. Los resultados devueltos incluyen una ruta para una solicitud REST, el método asociado (GET o POST) y el parámetro utilizado para incluir el script.

El problema es que para cada vulnerabilidad, el parámetro utilizado es un ID para un valor único. Por ejemplo, una solicitud getUserPrivileges GET muestra una vulnerabilidad al usar el parámetro 'userId'. Si intentara realizar esta solicitud en SoapUI, utilizando un ID de usuario no válido, obtendría una respuesta de "Solicitud incorrecta". Tampoco hay ningún lugar en la interfaz de usuario que me permita ingresar mi propio valor para este parámetro.

Mi suposición es que temas como estos son todos falsos positivos, pero, como no tengo mucho conocimiento sobre este tema, quería verificar mi suposición.

Si tengo razón en este supuesto, ¿habría alguna razón por la que surgiría un falso positivo? ¿Hay algo que pueda hacer que mi herramienta de escaneo confunda esto con un problema?

Editar: Aquí hay dos solicitudes de ejemplo. Uno de ellos que creo que realmente puede ser un problema es el Ejemplo 2. Observo que el texto "" en ese ejemplo está presente en la respuesta sin formato, pero no en la respuesta html.

(Cuando digo que no se acepta el contenido html, me refiero al contenido en la respuesta de la solicitud. Las configuraciones para esto están en el lado del servidor. En Spring, esto parece aparecer con la ausencia de algo como " produce = MediaType.TEXT_HTML_VALUE "en la declaración del método y su sustitución con algo como" produce = MediaType.APPLICATION_JSON_VALUE ".)

Ejemplo 1:

Request:
GET http://###.##.##.###:####/AAAAAAAA/BBBBBBBB/CCCCCCCC?    requestId=%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E&comments=%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E HTTP/1.1
Accept-Encoding: gzip,deflate
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d

Response (Raw):
HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
Content-Type: application/json;charset=UTF-8
Content-Length: 167
Date: Wed, 22 Aug 2018 ##:##:## GMT
Connection: close

{"timestamp":#############,"status":400,"error":"Bad Request","exception":"java.lang.NumberFormatException","message":"For input string: '<script>alert(1);</script>'"}

Response (HTML):
unsupported content-type [application/json;charset=UTF-8]

Ejemplo 2:

Request:
GET http://###.##.#.###:####/AAAAAAAA/BBBBBBBB/CCCCCCCC?requestId=%3Cscript%3Ealert%28%22hello%22%29%3B%3C%2Fscript%3E HTTP/1.1
Accept-Encoding: gzip,deflate
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
Host: ###.##.#.###:####
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Response (raw):
HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
Content-Type: text/html;charset=UTF-8
Content-Length: 173
Date: Wed, 22 Aug 2018 ##:##:## GMT
Connection: close

{"timestamp":#############,
"status":400,
"error":"BadRequest",
"exception":"java.lang.NumberFormatException",
"message":"For input string: '<script>alert('hello');</script>'"}

Response (HTML):
{"timestamp":#############,
"status":400,
"error":"Bad Request",
"exception":"java.lang.NumberFormatException",
"message":"For input string: ''"}
    
pregunta harrys 20.08.2018 - 22:50
fuente

1 respuesta

4

Como es habitual cuando utiliza escáneres automáticos, deberá realizar algunas pruebas manuales para confirmar esta vulnerabilidad o rechazarla como un falso positivo.

¿Por qué ZAP etiquetaría esto como XSS?

De la documentación de ZAP (gracias @SimonBennetts) :

  

Secuencias de comandos entre sitios (reflejadas)

     

Esta regla comienza enviando un valor 'seguro' y analizando todas las ubicaciones en las que aparece este valor en la respuesta (si corresponde). A continuación, realiza una serie de ataques dirigidos específicamente a la ubicación en la que se produce cada una de las instancias, incluidos los atributos de etiquetas, los atributos de URL, los atributos de las etiquetas que admiten atributos src, comentarios html, etc.

Eso significa que la tasa de falsos positivos de ZAP para el XSS reflejado es probablemente bastante baja, es decir, la mayoría de lo que informa es real, ya que solo informa cosas donde la entrada se refleja de nuevo en la fuente de la página de una manera que parece vulnerable a uno de los mecanismos estándar de XSS.

Todo lo que informe es digno de una investigación manual adicional.

¿Qué pasa si no hay lugar en la interfaz de usuario para ingresar?

No importa.

Los tipos de XSS más peligrosos son aquellos en los que la carga maliciosa se encuentra en un parámetro GET URL, por ejemplo:

http://server/cgi-bin/testcgi.exe?usedid=<script>alert("Hello!")</script>

porque luego puedo poner ese enlace en un correo electrónico de suplantación de identidad y una vez que haga clic en él, ¡está ejecutando mi código!

Entonces, aunque no hay ningún elemento de la interfaz de usuario, ZAP ha encontrado algún parámetro en el que puede insertar código y el servidor lo devolverá como parte de la página HTML.

Haz algunas pruebas manuales

Aquí es donde deberá ir a inspeccionar la fuente de la página / comenzar a jugar con ella hasta que haya generado una ventana emergente de alerta o convencerse de que los desarrolladores hicieron el escape de salida adecuado.

Para comenzar, OWASP tiene una excelente guía de pruebas de XSS:

enlace

Como lo señala @AndrolGenhald, la página de "Solicitud incorrecta" probablemente le devuelva la entrada a usted sin que se escape correctamente. Si llego a su servidor con usedid=<script>alert("Hello!")</script> , supongo que me devolverá una página de error que dice

Bad Request: "<script>alert("Hello!")</script>" is not a valid user.

Si miras en la fuente de la página, espero que veas este escape correctamente:

Bad Request: &quot;&lt;script&gt;alert(&quot;Hello!&quot;)&lt;/script&gt;&quot; is not a valid user.

que le dice a su navegador que muestre esto como texto, en lugar de tratarlo como parte del código HTML. Si no aparece escapado en la fuente de la página, entonces con un poco de tiempo de reproducción, probablemente puedas hacer que se muestre como:

Bad Request: "

lo que significa que en realidad ejecutó el script en lugar de mostrarlo como texto (y probablemente tendrás una ventana emergente agradable para acompañarlo). Hola reflejado vector de ataque XSS !! (Acaba de encontrar una vulnerabilidad, abra un ticket de error y vaya a tomar una cerveza)

    
respondido por el Mike Ounsworth 20.08.2018 - 23:44
fuente

Lea otras preguntas en las etiquetas