¿Por qué los escáneres no pueden detectar el XSS almacenado? ¿Hay alguna forma de automatizar la detección de xss almacenados (persistentes)? [cerrado]

Navega tus respuestas
3

Estoy buscando desesperadamente herramientas, preferiblemente con alguna guía, también preferiblemente de código abierto, para detectar vulnerabilidades almacenadas en xss. Se observa que algunos de ellos no dan los resultados esperados con XSS almacenados.

He intentado con ZAP Proxy y xsser , pero solo encontré documentación sobre el XSS reflejado para esas herramientas.

Para XSS almacenados, la página "inyectada" puede ser diferente de la página vulnerable.

Estoy comparando las herramientas de una aplicación vulnerable simple aquí: enlace

La explotación manual tomó segundos, pero hasta ahora no pude usar herramientas automáticas, incluso en un modo "guiado" donde especifico la URL del formulario y dejo que la herramienta encuentre páginas vulnerables.

Sospecho que ambas herramientas citadas son capaces de hacer eso, pero es demasiado trivial o demasiado complicada para ser mostrada en ejemplos / publicaciones de blog. Estaría muy agradecido si alguien pudiera mostrar tal caso de uso.

    
pregunta user2245644 18.10.2016 - 15:35
fuente

1 respuesta

2

Aquí hay algunos problemas con lo que está buscando y por qué prácticamente no existen.

  1. Las herramientas encuentran el XSS reflejado al buscar el fragmento de script inyectado en el origen HTML de la respuesta inmediata a la solicitud que inyectó el script.
  2. Las mismas herramientas detectarán XSS almacenado también si el script se refleja en la respuesta inmediata.
  3. Pero a veces la respuesta inmediata puede no reflejar el script incluso si es vulnerable a XSS. Por ejemplo, un usuario envía un formulario interno a un usuario altamente privilegiado que no será visible para él / ella de inmediato. En este caso, si el formulario es vulnerable a XSS persistente, se ejecutará en el navegador del usuario con privilegios altos.
  4. El XSS persistente ocurre principalmente en la solicitud POST. El escaneo de la solicitud de publicación generalmente lleva al agotamiento de la base de datos.

Qué puedes hacer para automatizar:

En este momento no tengo conocimiento de ninguna herramienta que pueda usarse para la misma. Sin embargo, me gustaría sugerir un trabajo alrededor.

  1. Utilice la versión de prueba de Burp Professional [Les llevará un día o dos enviar la licencia de prueba.]
  2. En Opciones de usuario > Misc en la sección Registro haga clic en la casilla de verificación para registrar todas las respuestas.
  3. Examine la aplicación, ajústela, seleccione las solicitudes que desea escanear y envíelas a la pestaña del escáner. Identificará las vulnerabilidades habituales, pero puede pasar por alto algunos XSS persistentes.
  4. Examine y vuelva a utilizar Spider en toda la aplicación después del escaneo con todos los niveles de privilegio del usuario.

  5. Verifique en el archivo de registro los scripts. Los scripts inyectados de Burp se pueden distinguir, ya que generalmente llevan consigo una firma de caracteres aleatorios. Por ejemplo, el script inyectado podría verse como

    jklmn | script inyectado que stackexchange no me deja publicar | jklmn

  6. Entonces, si identifica los scripts inyectados en el archivo de registro de respuestas, puede identificar la página, el parámetro y la fuente de la reflexión.

respondido por el hax 18.10.2016 - 16:37
fuente

Lea otras preguntas en las etiquetas

¿Es más seguro descargar torrents a través de TOR o un navegador normal? ¿Cómo se encuentra el certificado del emisor para verificar un certificado dado?