¿Se puede aprovechar una vulnerabilidad xss sin autenticación?

Question

¿Se puede aprovechar una vulnerabilidad xss sin autenticación?

#1 de Polynomial (1 votos)
#2 de CBHacking (0 votos)

0

Estoy confundido acerca de la superficie de ataque posible gracias a una vulnerabilidad XSS. Supongamos que tengo una aplicación web simple que no implica autenticación (tal vez un tipo de cosa "la palabra del día"). Si está escrito de forma ingenua y permite la inyección creando un enlace malicioso, ¿qué tipo de daño puede causar la inyección?

Para concretar las cosas, aquí hay un script PHP (qué más) que está abierto al ataque, ya que enviará cualquier tontería agregada a la URL de la solicitud.

<html><body>
<p>
  <?php echo 'Access denied:' . $_SERVER["PHP_SELF"] ; ?>
</p>
</body></html>

¿Qué tan malo sería tener este problema en mi servidor? ¿Qué puede pasar exactamente? Mi script no recopila ni almacena ningún dato, por lo que no hay posibilidad de una inyección persistente en mi servidor.

Si el usuario que hace clic en el enlace malicioso confía en mi dominio, podría ser engañado para que haga o acepte cosas que de otra manera no harían. Pero si mi dominio no tiene una confianza especial, ¿sigue habiendo peligro? El atacante ya ha tenido acceso al usuario / víctima para engañarlos para que me visiten a través del enlace manipulado, ¿así que mi sitio web realmente representa un peligro adicional?
Dado que el código reflejado parece originarse en mi dominio, ¿podría el atacante acceder a mi intranet? Supongo que en este caso no es necesario ningún engaño: el atacante puede ejecutar las solicitudes maliciosas directamente en mi servidor, ¿no?

Debo estar perdiendo algo aquí, ayúdame a entender de qué se trata.

xss

pregunta alexis 11.11.2018 - 01:18

fuente

2 respuestas

Lea otras preguntas en las etiquetas xss

Conexión segura de un cliente wifi a un AP usando una contraseña generada Encabezado de respuesta del equilibrador de carga de AWS Apache Server Disclosure

score 1 · Answer 1

Si el usuario que hace clic en el enlace malicioso confía en mi dominio, podría ser engañado para que haga o acepte cosas que de otra manera no harían. Pero si mi dominio no tiene una confianza especial, ¿sigue habiendo peligro? El atacante ya ha tenido acceso al usuario / víctima para engañarlos para que me visiten a través del enlace manipulado, ¿así que mi sitio web realmente representa un peligro adicional?

El atacante no necesariamente tiene acceso al usuario. Es posible que hayan enviado un correo electrónico no deseado con un enlace o hayan creado un perfil de redes sociales falso para enviarles ese enlace. Ya que su sitio parece ser lo suficientemente benigno (incluso pueden conocer el sitio y confiar en él) es más probable que hagan clic en el enlace.

Tienes razón en que hay un menor impacto en la forma en que tu dominio no tiene ningún secreto ni autenticación. Esto es ciertamente cierto para los usuarios en general, al menos. Pero tenga en cuenta que, por ejemplo, si tenía un panel de administración de CMS en su sitio para administrar el contenido o un blog, el atacante podría engañarlo para que haga clic en un enlace malicioso y active XSS para acceder a ese panel.

Aunque es poco probable, también puede ser posible que un atacante aproveche su sitio como un dominio de confianza para ofrecer una vulnerabilidad de navegador a través del XSS. Un ejemplo común de esto es cuando un atacante escribe una secuencia de comandos que revela información de identificación sobre alguien que está navegando a través del navegador Tor y engaña al usuario para que habilite las secuencias de comandos en lo que parece ser un dominio confiable y benigno.

Dado que el código reflejado parece originarse en mi dominio, ¿podría el atacante obtener acceso a mi intranet? Supongo que en este caso no es necesario ningún engaño: el atacante puede ejecutar las solicitudes maliciosas directamente en mi servidor, ¿no?

Si por "intranet" se refiere a otros sitios en su LAN local, no en general. Las solicitudes de origen cruzado se rechazan a menos que el servidor de destino les permita utilizar un encabezado CORS. Los subdominios tampoco son accesibles debido a la misma política de origen a menos que anule esto: http://foo.com no puede alcanzar http://x.foo.com o http://y.foo.com , y http://x.foo.com no puede alcanzar ni http://y.foo.com ni http://foo.com sin una política CORS permisiva aplicada por dominio de destino.

No estoy seguro de lo que quiere decir con "ejecutar las solicitudes maliciosas directamente en mi servidor": XSS da como resultado la ejecución del script del lado del cliente, no del lado del servidor.

score 0 · Answer 2

Si el sitio vulnerable no comparte un dominio con operaciones sensibles a la seguridad, y no es un sitio "confiable", los usuarios tienen alguna razón especial para creer que es legítimo (por ejemplo, donde los usuarios pueden creer que ingresar credenciales porque se esperaría algo), entonces el XSS no es un riesgo significativo.

Si el dominio (incluidos los subdominios de nivel superior) se utiliza para algo sensible, existe un riesgo, ya que un atacante podría acceder o manipular cookies o secuestrar sesiones incluso si esa página en particular no está autenticada. Si el dominio es de confianza (por ejemplo, una aplicación web interna corporativa), entonces es probable que la gente desconfíe si, por ejemplo, les pide que inicien sesión con sus credenciales corporativas. Finalmente, algunos sitios aún pueden tener sesiones que deben mantenerse seguras, incluso sin autenticación. Considere un sitio de reserva de boletos que no requiera que los usuarios tengan una cuenta antes de comprar un boleto, pero donde un XSS aún podría robar la información de pago del usuario o algo similar.