Legtöbbször nyugodtan vehetjük tudomásul, hogy fontos és bizalmas adatainkat nyilvános helyről ma már legtöbbször titkosított csatornán keresztül érhetjük el. Sandro Gauci azonban elrontja a kedvünket:
- Az áldozat belép egy biztonságos oldalra, pl. https://somesecurebank.com
- A biztonságos oldal küld egy sütit az áldozatnak, ami tartalmazza a munkamenet-azonosítót
- Mialatt belépett, az áldozat meglátogat egy másik oldalt egy másik fülön, pl. a http://www.example.com-ot
- A támadó, a hálózatot figyelve látja az áldozat kapcsolatát a www.example.com-felé (pl. WLAN, ARP mérgezés, stb.)
- A támadó küld egy választ az example.com nevében, melyben a 301-es HTTP kóddal elirányítja az áldozatot a http://somesecurebank.com-ra, ami már egy titkosítatlan kapcsolatot jelöl.
- Az áldozat böngészője szépen elküldi a somesecurebank.com-hoz tartozó munkamenet-azonosítót a titkosítatlan csatornán, amit pedig a támadó szépen lehallgat.
A védekezés alapesetben biztonságos sütik beállításával, vagy kizárólag titkosított csatornán elérhető domainek beállításával oldható meg Martin O'Neal a SecurityFocus listán azt írta, hogy elég az áldozatot a http://somesecurebank.com:443-ra irányítani, így az SSL-only megoldás nem segít!
Demonstráció alant:
Surf Jacking Gmail demonstration from Sandro Gauci on Vimeo.
synapse · http://google.com 2008.08.12. 11:30:27
- Injektalok az oldalba trojanos flasht / javat
- Hamis ssl certet adok neki (userek 90% ugyis rakattint, nembaj hogy nem az eredeti)...
- stbstbstb...
Ja, az ilyen cookie-lopos tamadasokrol meg annyit, hogy ha rogziti sessionbe a generalaskor a kliens ip-jet es csak azzal engedi be, akkor love van az egesz.
synapse
atomgape 2008.08.13. 09:28:55
A másik, hogy ha valaki ezt végre tudja hajtani, akkor egy IP-cím hamisítás már igazán ujjgyakorlat.
synapse · http://google.com 2008.08.13. 14:00:09
synapse
phr3ak 2008.08.18. 18:09:54