Carga útil XSS con restricción de longitud de diez caracteres

3

Hay un campo de entrada que no se codifica en el lado del servidor. Pero si le das a un script completo, por ejemplo, <img src=a onerror=alert(1)> , muestra un error como: <img src=a....' no es un valor válido.

No tengo conocimiento de ninguna carga útil que sea lo suficientemente corta como para explotar esto.

  • ¿Es posible llevar a cabo un ataque XSS?
  • Si no es así, ¿cómo debo reportar esta vulnerabilidad al propietario de la aplicación?
pregunta one 18.06.2016 - 21:45
fuente

2 respuestas

5
  

¿Es posible llevar a cabo un ataque XSS?

No, 10 caracteres no son suficientes para explotar esto. Si desea ingresar un contexto de JavaScript, como mínimo, necesitará:

  • 1 < para entrar en un contexto de etiqueta
  • 1+ [a-z] para el nombre de la etiqueta
  • 1 espacio
  • 1+ [a-z] para el atributo (en la práctica, el atributo de evento más corto que existe actualmente es onload, que tiene 6 caracteres)
  • 1 =
  • su carga útil

Eso significa que incluso en una situación ideal, solo tiene 5 caracteres para su carga útil. Incluso si algo como jQuery ya está cargado, cargar un script remoto requiere más caracteres que eso.

En realidad, ni siquiera tienes 5 caracteres. El atributo más corto es de 6 caracteres, pero onload no funciona con img sin un src válido, por lo que onerror es más corto, lo que le da <img onerror=[] src=a> (20 caracteres). Con una etiqueta de cuerpo, podría reducir esto un poco: <body onload=[]> (14 caracteres), que todavía es demasiado largo. Y aún necesita su carga útil, que tendrá un mínimo de ~ 25 caracteres (por ejemplo, $.getScript('http://x.c') ).

Esto significa que en su situación, las etiquetas de secuencia de comandos serían en realidad las más cortas. Pero solo obtendrías a <script sr con 10 caracteres.

Ni siquiera puedes inyectar un enlace, que posiblemente se pueda usar para el phishing, ya que también se corta una etiqueta: <a href=ht

  

Si no es así, ¿cómo debo reportar esta vulnerabilidad al propietario de la aplicación?

¿Es configurable la longitud del texto? En ese caso, esta sería una vulnerabilidad válida.

Si no es configurable, no lo consideraría una vulnerabilidad explotable, pero aún así lo informaría (al menos si me estoy comunicando con ellos debido a otros problemas), ya que puede convertirse en un problema en el futuro en En caso de que el vendedor decida mostrar más caracteres.

    
respondido por el tim 18.06.2016 - 23:10
fuente
3

Dependerá, pero si hay otro lugar donde se inserta la entrada del usuario, estos 10 caracteres serían suficientes para engañar al navegador para que lo analice en otro contexto.

Supongamos que hay una imagen debajo (por ejemplo, un avatar) que puede ser controlada por un atacante, incluido el texto alternativo. Un atacante podría establecer:

<img src="myimage.jpg" alt="--><script>alert(1);</script>" />

Sería seguro no codificar este texto alternativo, ya que solo aparece en un parámetro.

Sin embargo, si el texto no codificado en el mensaje de error era " <!-- ", entonces todo hasta el --> en el parámetro se trata como un comentario, y se ejecuta la alerta ().

Otra opción sería un texto sin filtrar como « <b c=" », aunque el resto de la carga útil tendría que estar mucho más cerca.

El parámetro podría ser cualquier cosa (por ejemplo, la url de la imagen), en la medida en que no se realizó el escape "redundante" en él, y aparece después del texto sin filtrar (la explotabilidad real dependerá de las etiquetas intermedias).

    
respondido por el Ángel 19.06.2016 - 00:24
fuente

Lea otras preguntas en las etiquetas