Encontré xss en un campo de área de texto. Cuando ingresa un carácter en este campo, éste lo genera en tiempo real, de modo que cuando ingrese el siguiente código:
<input onclick=alert(document.cookie)>
no hay validación de entrada ni ningún filtro, por lo que puedo hacer clic en el campo de entrada y bam xss.
Mi pregunta es si existe una vulnerabilidad real en esta falla. No puedo pensar en una vulnerabilidad real porque no puedo enviar a la víctima este enlace con el código inyectado.
Si no puede enviar el enlace, sería un caso de self-xss que involucra a la víctima inyectando fragmentos maliciosos de JavaScript, lo cual es una no vulnerabilidad en Las fuentes de error que he encontrado o incluso para evaluaciones profesionales. Sin embargo, se han informado ataques de ingeniería social en el pasado, en los que un atacante convence a alguien para que pegue un javascript malicioso que promete algún resultado, pero en realidad termina causando daño a la víctima . Dado que, esto implica una gran cantidad de interacción del usuario , es principalmente una no vulnerabilidad. Pero, se debe poner protección adecuada para que la entrada no se refleje de todos modos.
Más sobre self-xss en: enlace
A veces, tiene suerte y la aplicación está construida de manera que retenga el lado del servidor de estado de entrada y la refleje si ve errores. Este comportamiento puede no ser obvio de manera predeterminada porque la validación de javascript puede impedirle ver esa devolución de datos (pero se agrega para hacer que los navegadores que no son js funcionen).
Intente ver si la entrada tiene un parámetro de nombre y un enlace a la página (solicitud GET) con el nombre de las entradas como parámetro de consulta (prueba = nuevo nombre aquí). Si todo es POST, simplemente desactive javascript en su navegador e intente ingresar su XSS, y en otro campo, deje en blanco o ingrese los datos que sepa que no validarán del lado del servidor. El servidor puede reflejar con los formularios ya preparados con la entrada anterior (lo que le permite reflejar su XSS con una publicación CSRF). Si se implementan tokens CSRF, lo único que tiene de suerte es que la validación del token es posterior a la validación de entrada (probablemente no), o que los tokens se pueden reutilizar. Pero si CSRF está permitido, probablemente puedas encontrar un montón de otras cosas.
no puedo enviar a la víctima este enlace con el código inyectado
Esto podría ser posible si encuentra que alguna entrada llenará el campo.
Intente las solicitudes POST y GET para la página e intente rellenar el campo usando su nombre (si tiene uno), pero también intente id y otras variaciones. Eche un vistazo al resto de la aplicación y vea si hay algún parámetro de uso común que pueda probarse aquí. La herramienta Target de Burp Suite es excelente para esto porque le permite ver el mapa del sitio de un vistazo, junto con los parámetros enviados a cada página.
Si encuentra que necesita utilizar el método POST para completar este campo, para hacer posible la vinculación, debe crear un formulario en su propio sitio para enviarlo al sitio vulnerable:
<form method="post" action="https://example.com/submit">
<input type="hidden" name="textarea1" value="<input onclick=alert(document.cookie)>" />
</form>
Puedes enviar esto automáticamente
<script>
document.forms[0].submit();
</script>
y simplemente envías el enlace de tu página a tu víctima para que se active el XSS reflejado.
Lea otras preguntas en las etiquetas exploit xss javascript known-vulnerabilities