Op de Black Hat conference in LA werd gedemonstreerd hoe een GMail- of Facebook-sessie kan worden gehackt.
Voor zover ik kan zien, werd hier eigenlijk een wijd open deur ingetrapt; op een (Wifi-)netwerk alle verkeer naar bv. gmail of facebook sniffen, de session-waarde uit de cookie overnemen in de eigen cookie en voor je het weet zit ik in uw mailbox te snuisteren.
Het probleem heeft eigenlijk helemaal niets met web 2.0 te maken, maar gaat over de vreemde beslissing van oa. Google en Facebook (en eigenlijk zie je dat bijna overal) om enkel het login-proces te beveiligen (achter https te zetten). Eenmaal succesvol aangelogd ga je terug naar onbeveiligd verkeer (http zonder de s van secure) en dan is je cookie dus leesbaar voor iedereen die aan je netwerkverkeer kan.
De oplossing voor GMail is alvast eenvoudig: als je als URL zelf https://mail.google.com ingeeft, ben en blijf je in https en is ook je cookie niet meer zomaar te lezen. Ik heb mijn bookmark al aangepast 🙂 Bij Facebook en Linkedin lijkt dat alvast niet te lukken.
Meer info:
- bron: BBC NEWS: “Warning of webmail wi-fi hijack”
- meer op: News.COM: “Researcher: Web 2.0 vulnerable to cookie theft”
Update: ondertussen zit ik op de trein (bovenstaande had ik nog snel-snel op het werk geschreven) en ik heb nu even tijd om wat verder uit te weiden (en open deuren in te trappen) in de vorm van een paar vragen en antwoorden.
V: waarom zijn die (sessies in) cookies nodig?
A: omdat het web (het onderliggende http-protocol) eigenlijk ‘stateless’. Een request (de logon op Facebook bv.) kan aan serverkant enkel aan een volgende request (narcistisch bekijken van je vriendenlijst) gelinkt worden door middel van een sessie. Die sessie wordt geïdentificeerd door een sessionid, die maar op een paar manieren kan worden uitgewisseld; in een cookie, in een url (als parameter in een GET-request) of in een form (als parameter in een POST-request). Van die drie methodes is een cookie ontegensprekelijk de properste, maar qua security zijn ze in principe quasi even (on-)veilig.
V: waarom steken Google en al die andere hot-shots hun applicaties dan niet volledig achter https?
A: de s in https betekent dat alles geëncrypteerd wordt. Encryptie betekent dat de processoren aan ontvangende maar vooral verzendende kant wat meer werk hebben en dat de hoeveelheid data groter wordt (wat een geëncrypteerde tekst bestaat in principe uit meer karakters dan het origineel). Omdat Google, maar meer nog Facebook, Linkedin en andere fancy applicaties gebaat zijn bij het beperken van CPU-load en te versturen data, werken ze dus liever gewoon in http.
V: en kan die sessie dan niet op een andere manier beveiligd worden?
A: in principe wel, maar dan begeeft een developer zich in woelige wateren. Je zou aan serverkant kunnen bijhouden vanop welk ip-adres de gebruiker inlogt (evt. met nog een paar andere parameters zoals useragent van de browser) en dat voor elke request opnieuw controleren. Als een hacker dan met een sessie aan de haal gaat, is de kans groot (maar niet gegarandeerd) dat die parameters niet overeenkomen en dan kun je die malafide gebruiker vragen terug in te loggen. Andere (aanvullende) mogelijkheden zijn het beperken van de geldigheid van een sessie en het afblokken van gelijktijde gebruik van dezelfde login (het gelijktijdig gebruik van dezelfde sessie). Maar met al deze “oplossingen” is de kans groot dat je op bonafide gebruikers zult moeten lastigvallen om terug aan te loggen of zelfs buitensluiten (in het geval van concurrent sessions) . En dat maakt gebruikers zenuwachtig.
Conclusie: er is geen ontkomen aan, je moet https echt vanaf login tot aan de logout gebruiken (en voor alles, ook images in die pagina’s, anders krijg je in sommige browsers lelijke security-warnings). Eén troost: er bestaan hardware-oplossingen (ssl-encryptie devices en insteekkaarten) om de impact op CPU-load tot een minimum te beperken. Met de grotere hoeveelheid dataverkeer zul je dan maar moeten leren leven 🙂