Se qualcuno ha impostato correttamente un sito Web di phishing su una rete wireless fasulla per dire, bankofamerica.com, e fa finta che SSL non sia stato utilizzato, sarebbe in grado di eseguire uno script sul server che legge i contenuti dei cookie di chiunque chi si è connesso ad esso (ad esempio un token di autenticazione a lungo termine)?
Supponendo un attacco pharming anziché il phishing ... Qui è dove il nome del dominio viene reindirizzato a un sito falso di Typosquatting o inducendo l'utente a visitare un sito completamente diverso che è stato creato per assomigliare alla destinazione.
La differenza qui è cruciale: il dominio effettivo del sito falso visto dalla vittima che è effettivamente lo stesso del sito reale causerà al browser il trattamento del sito falso come la stessa origine .
Ciò significa che i cookie, la memorizzazione locale e altri saranno disponibili per il sito falso.
Due punti attenuanti:
Se nessuna delle precedenti condizioni si applica e l'utente ha una sessione autenticata contro il sito falso, i cookie verranno inviati al sito falso, inclusi quelli utilizzati per l'autenticazione. Speriamo che una banca abbia adottato una delle precauzioni sopra citate, ma non sempre.
Sì, l'attaccante può inviarti un link dannoso e se fai clic su di esso le informazioni sui cookie passeranno all'utente malintenzionato. Tali tipi di attacchi sono chiamati attacco Cross Site Scripting XSS . Lo scenario di attacco può essere di due tipi: 1. XSS memorizzato . 2. XSS riflesso
Sì, supponendo che HTTPS non sia utilizzato.
Nella tua situazione, esegui il gateway wireless e hai la possibilità di convertire bankofamerica.com in un host diverso da quello che avrebbe su Internet pubblica. Questo è un attacco pharming .
I cookie sono legati a un nome di dominio . Quando un server invia un'intestazione di risposta Set-Cookie , o uno script usa document.cookie per impostare un cookie, diciamo che il cookie è impostato da (o per ) < em> quel dominio . In generale, la capacità di leggere i cookie per un determinato nome di dominio è limitata al server con quel nome di dominio. Questo ha implicazioni di attacco evidenti se il nome bankofamerica.com si riferisce improvvisamente a un indirizzo IP diverso.
Ogni volta che il browser invia una richiesta a un server denominato bankofamerica.com , include i cookie impostati da bankofamerica.com nella richiesta. Se il server (o l'indirizzo IP) effettivo raggiunto quando il tuo computer richiede bankofamerica.com , il tuo browser non si preoccupa e invierà i tuoi cookie bankofamerica.com al server con il nome accettabile (ma in realtà dannoso) . (Si consideri che a volte l'indirizzo IP associato a un nome di dominio può cambiare in modo legittimo, in che modo il sistema dovrebbe sapere se una modifica è legittima o un attacco?)
Dal momento che controlli questo server canaglia, puoi vedere tutto il traffico che entra ed esce. Pertanto, è possibile visualizzare le intestazioni dei cookie inviate dal browser del client al server. Tuttavia, se controlli il router, puoi vedere tutte quelle informazioni anche prima che raggiungano il tuo server malevolo (tramite il router stesso), quindi non c'è una buona ragione per impostare effettivamente un server malevolo oltre a il tuo router dannoso. Se in qualche modo sei riuscito a modificare il record DNS di bankofamerica.com del client senza controllare completamente il router, tuttavia, l'idea del server canaglia risponde perfettamente alle tue esigenze.
Nota che HTTPS fa un buon lavoro nel bloccare questo attacco. Il tuo server non può impersonare correttamente una connessione sicura a bankofamerica.com , perché non ha un certificato firmato da un'autorità di certificazione che l'utente considera attendibile. Nessuna autorità di certificazione ti darebbe un certificato firmato per bankofamerica.com , a meno che tu non possa dimostrare che la tua proprietà è di proprietà reale (cosa che ovviamente non puoi provare, perché non la possiedi). Quando provi a reindirizzare la connessione sicura del client al tuo server falso, il client verrà avvisato che sta accadendo un possibile attacco.
Se l'utente prima ha provato http://bankofamerica.com invece di andare direttamente a https://bankofamerica.com , il tuo malvagio server potrebbe dire "Non c'è bisogno di eseguire l'upgrade a HTTPS, diciamo semplicemente su HTTP semplice" e il client non riceverebbe un avvertimento certificati. Questo attacco di stripping SSL . Questo può essere impedito da HSTS , che un server può utilizzare per comunicare a un cliente, "Non contattare mai questo host con una connessione non sicura per i prossimi XX giorni / mesi / anni. "
Un'altra misura protettiva possibile con HTTPS è la bandiera cookie sicura . Il browser non invierà cookie contrassegnati in modo sicuro al dominio proprietario, a meno che la richiesta non avvenga su HTTPS. Poiché il tuo server non può impersonare il dominio di destinazione su una connessione sicura, non potrai mai vedere i cookie sicuri.
Sì, ma a seconda del browser non è nemmeno necessario un attacco di phishing. Internet Explorer 11 ha una vulnerabilità recente che consente a un utente malintenzionato di rubare i cookie.
Molti diversi linguaggi di programmazione possono essere eseguiti su siti Web e ci sono comandi che possono fare cose spaventose. Se sei su Linux puoi configurare un profilo completamente nuovo per Firefox solo così il tuo sistema è protetto. Sì, anche Linux può essere bloccato da Java e attaccare il caricatore di avvio con un attacco da cameriera malvagio remoto. (Perché ho menzionato la cameriera cattiva? Perché sto solo dando un esempio di quanto può andare lontano un exploit del browser.)