Immagina il seguente scenario: l'utente è attacker.com e gioca lì. Poco prima di fare clic su un punto, viene reindirizzato a victim.com utilizzando la cronologia del browser. L'utente pensava di aver cliccato su attacker.com ma in realtà ha cliccato su victim.com implicando così operazioni indesiderate. Vedi la dimostrazione al link .
In che modo il proprietario di victim.com può proteggere da tali attacchi? E dovrebbe?
Gli attacchi di Zalewski per la navigazione in entrata e in navigazione sono basati sulla navigazione senza sfocare la finestra; specialmente nel caso più fluido in cui l'operazione "indietro" attiva la bfcache, è improbabile che persino ottenga un evento onblur o onfocus !
Questi possono essere neutralizzati rilevando che la tua finestra è stata aperta da uno script. Questo può essere fatto controllando window.opener ; Vale anche la pena di cercare window.name , dal momento che una finestra con nome può potenzialmente essere "trovata" da window.open .
Questo in genere viene aggiunto a uno script per interruzione di frame, ad esempio:
if (top!==self || opener!==null || name!=='') {
// countermeasure
}
in cui la contromisura sarebbe qualcosa come nascondere / disattivare l'intero contenuto della pagina (non navigare in alto in quanto è davvero facile da fermare).
Come per i framebreaker in generale, ciò richiede JavaScript, quindi non funzionerà se è disabilitato e potrebbe potenzialmente essere attaccato tramite il filtro anti-XSS fasullo di IE (se non lo hai disabilitato con X-XSS-Protection ). Se sei un'applicazione che si basa su JS e non ha bisogno di accessibilità solo HTML, puoi negare per default qui per maggiore affidabilità.
Naturalmente, se lo fai, tu oi tuoi partner non possono aprire la tua pagina in un popup.
Ci sono altri attacchi simili che coinvolgono schede di chiusura o finestre a comparsa per far apparire il contenuto della pagina sotto il puntatore, ma sono meno agevoli degli attacchi della varietà di navigazione. In questi casi fai ottieni onfocus / onblur ed è ragionevole reagire rendendo l'interfaccia inattiva per un periodo dopo un onfocus se c'è una pagina di cui sei particolarmente preoccupato proteggere.
Una mitigazione generale per l'intera classe di vulnerabilità non consiste nel fare procedere operazioni pericolose da un singolo clic su una pagina che può essere navigata direttamente. Sembra debole, ma probabilmente troverai che lo stai già facendo naturalmente in molti casi per motivi non di sicurezza, ad esempio Elimina account - > "Sei sicuro di voler eliminare definitivamente il tuo account?".
In teoria, l'operatore del sito web può prevenire tali attacchi utilizzando gli eventi window onfocus e onblur . Ad esempio, nell'evento onfocus window si potrebbe creare una sovrapposizione <div> su tutta la pagina per mezzo secondo, impedendo così l'interazione con gli elementi della pagina. Comunque non l'ho visto in uso da nessuna parte, e non sospetto che guadagnerà popolarità poichè probabilmente sarà comunque bypassabile.
L'attacco che descrivi, creato da Michael Zalewski è solo uno dei tanti attacchi di novità proof-of-concept che dimostrano il motivo per cui "il web è rotto 'ad un livello fondamentale. Alcuni dei suoi precedenti attacchi basati sul timing - dirottamento del consenso alla geolocalizzazione HTML5 - hanno sfruttato un vettore simile ed è stato corretto a livello di browser. Si potrebbe sospettare che questa classe di vulnerabilità verrà risolta nei browser nel (possibilmente lontano) futuro, ma sono molto difficili da risolvere in quanto sfruttano le imperfezioni umane che possono manifestarsi in vari modi.
In breve: potresti provare a sperimentare con onfocus e onblur eventi, ma preparati per stranezze del browser e non passare troppo tempo su di esso. È improbabile che venga massicciamente abusato dai cappelli neri.
Leggi altre domande sui tag appsec attack-prevention