Hoy he encontrado un sitio interesante que emite su valor de cookie directamente a la página, por lo que si modifico el valor de la cookie, puedo XSS por mi cuenta.
por ejemplo, <span id=statistics>Last visit: Cookie_Value_Of_Something</span>
Entonces, mi pregunta es, ¿crees que esto es vulnerable o puedo explotar esto?
Me parece inútil hasta ahora.
Para explotar esta falla, el atacante tendría que manipular la cookie del usuario. Y esto solo es posible si es capaz de explotar otra vulnerabilidad que le permite configurar la cookie con la carga útil XSS como uno solo puede establecer cookies dentro del dominio desde el que Set-Cookie se originó :
El agente de usuario rechazará las cookies a menos que el atributo Dominio Especifica un ámbito para la cookie que incluiría el origen. servidor. Por ejemplo, el agente de usuario aceptará una cookie con una Atributo de dominio de "example.com" o de "foo.example.com" de foo.example.com, pero el agente de usuario no aceptará una cookie con una Atributo de dominio de "bar.example.com" o de "baz.foo.example.com".
Y además de comprometer al servidor, hay dos posibles vectores de ataque para manipular el valor de la cookie: o el atacante logra inyectar el exploit en el valor que se establece como el valor de la cookie por el script del autor del sitio, por ejemplo, algún usuario lo proporcionó Los valores se utilizan para el valor de la cookie. O el atacante tiene acceso a un subdominio y puede configurar una cookie para el superdominio en el que reside el script vulnerable que imprime el valor de la cookie. Ambos vectores pueden ejecutarse usando falsificación de solicitudes entre sitios .
No es explotable en sí mismo, pero es una ruta de escalada potencial para que un atacante pase de la corrección de cookies al XSS completo.
Notablemente:
Si el sitio se está ejecutando en un nombre de host que tiene dominios vecinos, cualquier ataque XSS a esos vecinos significa que se puede escribir una cookie en el dominio primario compartido, escalando a un ataque XSS en el sitio. p.ej. desde untrusted-uploads.example.com pueden escribir una cookie con el dominio example.com , que será leído por trusted-www.example.com .
Si el sitio se está ejecutando en https://www.example.com/ , un atacante aún puede falsificar un sitio en http://www.example.com/ . Cualquier cookie que se establezca desde allí será legible desde https ; el script en https no detectará que la cookie no se creó con secure . Así que cookie-XSS hace que el HTTPS sea inefectivo (excepto cuando Strict Transport Security lo anula, pero eso no es una defensa completa).
Realmente no es posible (*) que un script (ya sea del servidor o del lado del cliente) detecte que las marcas domain , path , secure o httponly en la cookie coincidan con los valores esperados, lo que significa no puede detectar de manera confiable la inyección de cookies desde fuera de su sitio.
(*: hay posibles hacks en los que intentas anular una cookie configurando una nueva con las marcas que deseas, pero en última instancia no es completamente confiable ya que la secuencia de comandos del atacante podría estar ejecutándose al mismo tiempo).
Érase una vez que el flash era vulnerable a la inyección de CRLF (IE también era vulnerable), y Esto podría haberse utilizado para establecer el encabezado de solicitud HTTP Cookie: para explotar XSS basado en cookies. Pero esto ya no es el caso. No es posible establecer una cookie en otro dominio. Si pudiera establecer cookies para otros dominios, haría que la fijación de sesión sea muy difícil de prevenir (si no es imposible).
Es inútil. Debido a la política del mismo origen, el texto de una página no puede ser leído por otros sitios, al igual que las cookies.
Es legible por un atacante que ejecuta un ataque MITM, pero también lo son las cookies (a menos que la conexión sea HTTPS).
El único vector de ataque real existiría en una situación en la que exista otra vulnerabilidad. Por ejemplo, si pudiera cargar un script ejecutable como un código PHP, podría manipular la cookie usando ese script para inyectar algo de JavaScript en la sesión de los usuarios. También deberías realizar la ingeniería social habitual para que el usuario visite tu script cargado.
Depende de qué cookie se haya generado.
Algunos sitios escriben datos de terceros en valores de cookies (eche un vistazo a la cookie reg_ext_ref de Facebook para usuarios anónimos, es la referencia completa). Puede creer que algunos sitios almacenan la última consulta de búsqueda en la que el usuario escribió o algo así (y, a veces, puede falsificar esa última consulta con GET-params). Por lo tanto, si al menos una de esas cookies similares se está generando, debe intentar explotar esto.
No estoy diciendo que tu caso sea un buen vector de ataque, simplemente vale la pena una investigación.