¿Es posible engañar a una persona para que vaya a un sitio web y ejecute JavaScript, sin que ellos lo sepan? (sin marcos)

Question

¿Es posible engañar a una persona para que vaya a un sitio web y ejecute JavaScript, sin que ellos lo sepan? (sin marcos)

#1 de SilverlightFox (1 votos)
#2 de hmrojas.p (0 votos)

2

Mi sitio web es W. Si realizas una solicitud GET a mi sitio web, te da JavaScript y si ejecutas el JS, realizas alguna acción (si estás conectado y tienes una cookie de sesión).

¿Puede alguien engañar a otros para que ejecuten el JS? Podrían engañar a otros para que hagan una solicitud GET incluyendo un <img> por ejemplo. Supongamos que W tiene el encabezado X-Frame-Options establecido en sameorigin , por lo que no podemos incrustarlo.

Es decir, pueden simplemente vincularse al sitio y, si haces clic en él, realizarás la acción, pero te darás cuenta de inmediato porque el navegador muestra que la pestaña ha cambiado a W. ¿Hay alguna forma de hacerlo? ¿Para que la víctima no se dé cuenta?

javascript csrf iframe code-execution

pregunta quantumtremor 26.05.2016 - 10:11

fuente

2 respuestas

Lea otras preguntas en las etiquetas javascript csrf iframe code-execution

¿Se adoptará ampliamente la API de administración de credenciales ahora disponible en Chrome 51? ¿Qué es un método raíz y cómo se logra?

score 1 · Answer 1

Esto parece ser lo mismo que CSRF , excepto que la carga útil es ejecutada por JavaScript.

Dado que X-Frame-Options está configurado para evitar el encuadre, JavaScript solo se puede ejecutar si la solicitud GET se abre en una nueva ventana (o pestaña).

Las etiquetas

<img> no funcionarán porque el navegador no interpretará ningún HTML o script devuelto en la respuesta.

Si su JavaScript está en un archivo separado, entonces <script src= podría usarse en un dominio de terceros. Si la secuencia de comandos hace que la solicitud con efectos secundarios se realice solo mediante URL absolutas, también podrían provocar la vulnerabilidad CSRF. Sin embargo, tenga en cuenta que las solicitudes que realiza este JavaScript podrían simplemente tener el exploit CSRF aplicado directamente a ellos, a menos que el propio JavaScript sea dinámico y contenga tokens CSRF incrustados.

Si el JavaScript utiliza direcciones URL relativas, la vulnerabilidad no se activará. p.ej. example.org incrusta su secuencia de comandos <script src="http//example.com/foo.js">,perodebidoaquesehacereferenciaalasURLrelativas,lassolicitudessubsiguientesvanalejemplo.orgenlugardeasuejemplo.com.

Esdecir,puedensimplementevincularsealsitioy,sihaceclicenél, realizaráslaacción,peroinmediatamentetedaráscuentadequetienes porqueelnavegadortemuestraquelapestañahacambiadoaW.¿Hayalgunamanera ¿Paraquelavíctimanosedécuenta?

Paramí,comosedijoanteriormente,sihayunavulnerabilidadenwww.example.com/page.php?javascript_action=fooquehacequeseejecutealgodeJavaScript,querealizalaacciónfoo,ydicequeestaacciónsevalidaparaquesolopuedaserfooyotrafuncionesdeconfianza(esdecir,no eval ), entonces es probable que pueda crear la acción de lado. -fectos que foo hace simplemente solicitando ese controlador directamente.

Sin embargo, si este controlador está protegido por los controles CSRF (por ejemplo, page.php contiene un token anti CSRF), tendrá que abrir la página a simple vista, pero podría hacer algo astuto como abrir una ventana emergente / emergente , e inmediatamente cierre la página antes de que la víctima se dé cuenta:

<script>
var foo;

function bar() {
  foo.close();
}

foo = window.open('http://www.example.com/page.php?javascript_action=foo');
setTimeout(bar, 3000);
</script>

Tenga en cuenta que lo anterior generalmente activará el bloqueador de ventanas emergentes del navegador (si está habilitado), es solo un ejemplo para explicar mi punto.

score 0 · Answer 2

En primer lugar, puedo ver que esto es una vulnerabilidad CSRF, si su sitio web tiene un JS que ejecuta una solicitud GET, entonces veo el siguiente escenario:

1.-Un atacante puede ver y analizar su código JS y usarlo para sus propósitos.

2.-El atacante podría construir un sitio web que incluya su JS.

<script src="http//:victimdomain/js/myscript.js"></script>

3.-ElsitiowebcontieneunaetiquetaqueejecutaJSparaqueelusuariofinalnosedécuenta.

<bodyonload="sendRequest("Bob");">

4.-Un problema podría ser si el código JS redirigir a otro sitio, la víctima sabría que algo malo ha sucedido. El atacante necesita saber cómo maneja la respuesta el código JS y tratar de modificarlo para mantener a la víctima en el sitio web actual, tal vez necesite escribir una función JS para este propósito.

5.-Finalmente, el atacante simplemente envía su exploit (sitio web malicioso) a las víctimas y no pueden darse cuenta de lo que sucedió.

De esta manera, un ataque CSRF podría ser fácil de explotar. Ahora, si no tuviera un código JS para ejecutar una solicitud GET y el atacante tendría más opciones para explotar, por ejemplo, como dijo, un atacante podría hacer algo como esto:

<img src="http//:victimdomain/action?param=Bob"/>

Pero,comomencionéanteriormente,lasolicitudGETpodríaredirigirseaotrositio,entoncesestapodríaserunabuenasoluciónparaunatacante:

1.-Construyeunsitiowebcondosiframes,algocomoesto:

<html><head><title>ejemploCSRF</title></head><framesetcols="1%, 99%">
            <frame src="exploit.html">
            <frame src="empty.html">
        </frameset>
 </html>

2.-exploit.html contendrá la solicitud de obtención.

<img src="http//:victimdomain/action?param=Bob"/>

3.-empty.htmlcontendráelsiguientecódigo:

<html><head><title>ejemploCSRF</title><script>functionpeticion(){setTimeout(function(){if(top!=self)top.location.href="http://attackerdomain/falsewebsite";
                }, 1000);
            }
        </script>
    </head>
    <body onload="redirect();">
    </body>
</html>

4.-La función JS valida la ventana actual, si la ventana superior es diferente de la ventana actual (en este caso, el empty.html), entonces redirige al sitio web de un atacante y, por último, la víctima no se dará cuenta. lo que pasa.

Entonces, creo que su sitio web podría ser vulnerable a CSRF y hay maneras de explotarlo (no solo mis ejemplos), por lo que debería proteger su sitio web. Mis recomendaciones son:

Use un token impredecible para cada solicitud.
Si su código JS contiene parte de la lógica comercial de su sitio web, debe protegerlo, aplicar el control de acceso, solo los usuarios autorizados pueden usar ese código JS y ofuscarlo.

Espero que esta información te ayude.