¿Qué puede hacer un archivo javascript inyectado localmente?

1

Estaba haciendo algunas pruebas en mi pequeño proyecto de foro. Descubrí que es posible inyectar un archivo javascript a través de un pequeño agujero de seguridad. Básicamente, el hacker puede inyectar cualquier código javascript que desee. Ahora, al contrario de los problemas de seguridad bien conocidos, este hack solo funciona en el lado de los piratas informáticos, porque no se muestran datos a otros usuarios, excepto al pirata informático.

El truco funciona en la página de configuración del usuario, donde cada usuario tiene acceso solo a su propia configuración. Por lo tanto, solo se mostrará una alerta en la computadora de los hackers.

Ya he solucionado esto, pero:

Todavía tengo curiosidad acerca de si este truco podría ser peligroso para el proyecto en sí. ¿Puede un pirata informático hacer más daño con él de lo que creo?

    
pregunta dkb 22.04.2018 - 21:57
fuente

2 respuestas

0

¿Tiene protección CSRF en sus inicios de sesión? Si no, propondría lo siguiente:

  • Cree una cuenta y almacene allí la carga útil de XSS.
  • Engaña a la víctima para que haga clic en un enlace que:
    • Los inicia sesión en la cuenta anterior usando CSRF.
    • Redirige a la página con el XSS almacenado.
  • La carga útil registra a la víctima con una solicitud AJAX y puede modificar la página como mejor le parezca, por ejemplo. mostrar un formulario de inicio de sesión.
  • Voila, está ejecutando JavaScript arbitrario y puede registrar contraseñas o lo que sea.

Por supuesto, esto requiere mucha interacción del usuario y otra vulnerabilidad para funcionar. Pero en mi experiencia, si hay una vulnerabilidad XSS, puede ser explotada sin importar dónde esté.

    
respondido por el Anders 23.04.2018 - 10:50
fuente
1

Si está realmente seguro de que el código inyectado solo puede ser ejecutado por la misma persona que lo inyectó, entonces podría clasificarse como "self-XSS", como se menciona en un comentario a tu pregunta. Al parecer, para aprovechar que un atacante necesita confiar en la ingeniería social, intenta engañar a otros usuarios para que inyecten el código ellos mismos y lo ejecuten.

EDITADO PARA AGREGAR ESCENARIO CSRF

La respuesta de Anders sugiere un escenario CSRF pero no estoy de acuerdo con eso (y aún no tengo suficiente reputación para comentar allí). Sin embargo, me acabo de dar cuenta de que una vulnerabilidad CSRF puede ayudar al atacante a explotar su XSS. Anders sugirió usar CSRF para iniciar sesión como el atacante y redirigir a su página que había sido infectada previamente. De esta manera te encontrarás ejecutando js arbitrarios, pero estás registrado como el atacante y ejecutando js en la página privada del atacante. Eso me parece inútil. La opción supuestamente correcta sería utilizar CSRF para inyectar el código malicioso directamente en la página de la víctima. Funcionaría de esta manera:

  1. la víctima ha iniciado sesión en tu sitio web
  2. la víctima visita un sitio web malicioso que usa CSRF para inyectar el XSS en su propia página privada (por ejemplo, una solicitud POST a un formulario que cambia su configuración de perfil y coloca js en el campo vulnerable)
  3. la víctima visita su propia página privada y ... ahora hay js inyectados allí

Por supuesto, esto requiere que el formulario en su sitio web utilizado para inyectar js sea vulnerable a CSRF (por ejemplo, porque el formulario no requiere un token secreto oculto), por lo que un atacante puede forzar a la víctima a realizar una solicitud a su Sitio web con graves consecuencias sin el consentimiento de la víctima, por ejemplo, cambiar la configuración, las contraseñas o, en este caso específico, inyectar js. Lea sobre CSRF si necesita comprender más.

    
respondido por el reed 22.04.2018 - 23:18
fuente

Lea otras preguntas en las etiquetas