Ho letto su CRIME - Come battere il successore BEAST? domande e risposte, ma non lo capisco: se Javascript può essere iniettato ed eseguito sulla macchina attaccata, perché non inviare direttamente il cookie segreto come richiesta AJAX a un server di rimozione ospitato dall'hacker?
Quote:
Suppose that the attacker uses some JavaScript code which can send arbitrary requests to a target site (e.g. a bank) and runs on the attacked machine;
Poiché JavaScript verrà eseguito da un'origine diversa - la Stessa politica di origine impedirà a example.org di afferrando i cookie da bank.example.com .
Example.org non deve nemmeno essere stato compromesso. Un aggressore Man-In-The-Middle (chiamiamola Mallory) potrebbe aver intercettato una connessione dalla vittima (chiamiamolo Bob) al sito benevolo che Bob visita su semplice http. per esempio. http://example.org .
Mallory inietta alcuni JavaScript nelle risposte ricevute da example.org che verranno eseguite nel browser di Bob. Poiché questo JavaScript è ricevuto da example.org agli occhi del browser, questo JavaScript non può accedere ai cookie su bank.example.com . Mallory non può manipolare il traffico a bank.example.com perché questa connessione utilizza https e tutti i cookie sono contrassegnati come sicuri e / o viene utilizzata l'HSTS.
Tuttavia, usando l'attacco CRIME, Mallory può usare il JavaScript per inviare richieste da example.org a bank.example.com e quindi monitorare il traffico di rete. Con un traffico sufficiente inviato a bank.example.com , è possibile determinare i valori di cookie di Bob.
Il codice JavaScript non viene inserito su bank.com, viene eseguito su compromised.com che visiti o che sono indotti a visitare. Il codice JavaScript su compromised.com invia richieste a bank.com per tuo conto.
L'attaccante deve anche essere in grado di visualizzare il tuo traffico di rete, ad esempio in un hotspot Wi-Fi.
Leggi altre domande sui tag encryption compression attacks tls beast