È possibile ingannare una persona per andare a un sito Web e eseguire JavaScript, senza che loro sappiano? (nessun iframe)

Question

È possibile ingannare una persona per andare a un sito Web e eseguire JavaScript, senza che loro sappiano? (nessun iframe)

#1 da (1 voti)
#2 da (0 voti)

2

Il mio sito web è W. Se fai una richiesta GET al mio sito web, ti dà JavaScript, e se esegui il JS, allora fai qualche azione (se sei loggato e hai un cookie di sessione).

Qualcuno può ingannare furtivamente gli altri nell'esecuzione del JS? Potrebbero ingannare gli altri a fare una richiesta GET includendo un <img> per esempio. Supponiamo che W abbia l'intestazione X-Frame-Options impostata su sameorigin , quindi non possiamo incorporarla.

Cioè, possono semplicemente collegarsi al sito e se fai clic su di esso eseguirai l'azione, ma ti accorgerai subito che lo hai perché il browser ti mostra che la scheda è stata modificata in W. Esiste un modo farlo in modo che la vittima non si renda conto?

javascript csrf iframe code-execution

posta quantumtremor 26.05.2016 - 10:11

fonte

2 risposte

Leggi altre domande sui tag javascript csrf iframe code-execution

Che cos'è un metodo di root e come viene realizzato? Router come MITM per rubare i dati

score 1 · Answer 1

Questo sembra essere lo stesso di CSRF , tranne per il fatto che il carico utile viene eseguito da JavaScript.

Poiché X-Frame-Options è impostato per evitare il framing, il JavaScript può essere eseguito solo se la richiesta GET è aperta in una nuova finestra (o scheda).

I tag

<img> non funzioneranno perché qualsiasi HTML o script restituito nella risposta non verrà interpretato dal browser.

Se il tuo JavaScript è in un file separato, <script src= potrebbe essere utilizzato su un dominio di terze parti. Se lo script fa sì che la richiesta con effetti collaterali venga eseguita utilizzando solo URL assoluti, questi potrebbero anche innescare la vulnerabilità CSRF. Tuttavia, tieni presente che le richieste fatte da questo JavaScript potrebbero semplicemente avere l'exploit CSRF applicato direttamente a loro, a meno che lo stesso JavaScript sia dinamico e contenga token CSRF incorporati.

Se il JavaScript utilizza URL relativi, la vulnerabilità non verrebbe attivata. per esempio. example.org incorpora lo script <script src="http//example.com/foo.js">,mapoichégliURLrelativisonoreferenziati,lerichiestesuccessivevannoadesempio.orginvecedell'esempio.com.

Thatis,theycansimplylinktothesiteandifyouclickitthenyou'llperformtheaction,butyou'llimmediatelyrealizeyouhavebecausethebrowsershowsyouthetabhaschangedtoW.Isthereawaytodoitsothevictimdoesnotrealize?

Perme,comedettosopra,seesisteunavulnerabilitàinwww.example.com/page.php?javascript_action=foochecausal'esecuzionedialcuniJavaScriptchefal'azionefoo,edicichequestaazioneèvalidatainmodochepossaesseresolofooealtrofunzioniattendibili(es.no eval ) quindi probabilmente puoi creare l'azione con -effetti che foo fa semplicemente richiedendo direttamente il gestore.

Tuttavia, se questo gestore è protetto da controlli CSRF (ad esempio page.php contiene un token CSRF anti), allora dovrai aprire la pagina in bella vista, ma potresti fare qualcosa di nascosto come aprire una finestra popup / popunder e chiudi immediatamente la pagina prima che la vittima realizzi:

<script>
var foo;

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

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

Nota che quanto sopra di solito attiva il blocco popup del browser (se attivato) - è solo un esempio per spiegare il mio punto.

score 0 · Answer 2

In primo luogo, posso vedere che si tratta di una vulnerabilità CSRF, se il sito Web ha un JS che esegue una richiesta GET, quindi vedo il seguente scenario:

1.-Un utente malintenzionato può vedere e analizzare il tuo codice JS e usarlo per i suoi scopi.

2. L'autore dell'attacco potrebbe creare un sito web che include il tuo JS.

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

3.-IlsitowebcontieneuntagcheesegueilJSinmodochel'utentefinalenonseneaccorga.

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

4.-Un problema potrebbe essere se il codice JS reindirizzasse su un altro sito, la vittima saprebbe che qualcosa di brutto è successo. L'utente malintenzionato deve sapere come il codice JS gestisce la risposta e provare a modificare per mantenere la vittima sul sito Web corrente, forse è necessario digitare una funzione JS per questo scopo.

5. Infine, l'aggressore invia il suo exploit (sito malevolo) alle vittime e non è in grado di rendersi conto di cosa accada.

In questo modo, un attacco CSRF potrebbe essere facile da sfruttare. Ora, se non avessi un codice JS per eseguire una richiesta GET e l'utente malintenzionato avrebbe più opzioni da sfruttare, ad esempio, come hai detto, un utente malintenzionato potrebbe fare qualcosa del genere:

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

Ma,comehodettoprima,larichiestaGETpotrebbereindirizzareaunaltrosito,quindiquestapotrebbeessereunabuonasoluzioneperunutentemalintenzionato:

1.-Costruisciunsitowebcondueiframe,qualcosacomequesto:

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

2.-exploit.html conterrà la richiesta Ottieni.

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

3.-empty.htmlconterràilseguentecodice:

<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 funzione JS convalida la finestra corrente, se la finestra più in alto è diversa dalla finestra corrente (in questo caso il file empty.html), quindi reindirizza al sito Web di un utente malintenzionato e, infine, la vittima non realizzerà cosa succede.

Quindi, penso che il tuo sito web potrebbe essere vulnerabile a CSRF e ci sono modi per sfruttarlo (non solo i miei esempi), quindi dovresti proteggere il tuo sito web. I miei consigli sono:

Utilizza un token imprevedibile per ogni richiesta.
Se il codice JS contiene parte della logica aziendale del tuo sito web, dovresti proteggerlo, applicare il controllo dell'accesso, solo gli utenti autorizzati possono utilizzare quel codice JS e offuscarlo.

Spero che questa informazione ti aiuti.