Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 36 reacties

Twee onderzoekers van de universiteiten van Illinois en Columbia hebben tijdens de Black Hat-conferentie aangetoond dat het stelen van cookies nog steeds een groot probleem is. Via een dergelijke aanval kunnen veel gevoelige gegevens ingezien worden, en https is maar een gedeeltelijke oplossing.

Het stelen van een cookie via een onbeveiligde http-verbinding is vrij eenvoudig, zo stellen de onderzoekers Suphannee Sivakorn en Jason Polakis. Bijvoorbeeld door een openbare wifi-hotspot in een café in de gaten te houden met tools als Wireshark en tcpdump. Zij stellen voorop dat cookie hijacking geen nieuw verschijnsel is, maar dat het nog steeds problemen oplevert. Zo maakt maar de helft van internet gebruik van een beveiligde https-verbinding.

Daar komt bij dat ook een versleutelde verbinding geen volledige bescherming biedt tegen het onderscheppen van cookies. Een browser maakt in sommige gevallen eerst verbinding met een site via http, waarna de server antwoordt dat er ook een https-verbinding mogelijk is. Daarna wordt de verbinding via https voortgezet. Een cookie wordt echter al tijdens het eerste gedeelte van de verbindingsopbouw uitgewisseld, waardoor dit alsnog te onderscheppen is.

In hun eerder gepubliceerd onderzoek hebben de wetenschappers zich gericht op de 25 meest populaire sites op het internet. Daarvan gebruiken er 15 https, wat aantoont dat de techniek nog niet alomtegenwoordig is. Zelfs bij een presentatie over het interne netwerk van Black Hat bleek dat de meeste uitgaande verbindingen via http verliepen, wat toch enige vragen opriep. Veel van de grote sites ondersteunen bijvoorbeeld personalisatie via een onbeveiligde verbinding. Door een cookie te stelen, kan deze gepersonaliseerde versie van de site ingezien worden, waardoor een grote hoeveelheid gevoelige gegevens zichtbaar is.

Door met een gestolen cookie zelf verbinding te maken met de server, zowel via http als https, wisten de onderzoekers bij zoekmachines als Google, Bing en Yahoo bijvoorbeeld het e-mailadres, de profielfoto en de voor-en achternaam van het slachtoffer te achterhalen. Daarnaast was het mogelijk om de zoekgeschiedenis, bezochte pagina's en opgeslagen locaties in te zien. In het geval van Yahoo was het bovendien mogelijk om titels en een beknopte weergave van e-mails in te zien, contacten te exporteren en e-mails vanaf het account van het slachtoffer te versturen.

Grote onlinewinkels als eBay, Target, Walmart en Amazon bieden allemaal ondersteuning voor https, maar slechts voor een gedeelte van de site. Bijvoorbeeld voor logins en accountpagina's. Andere delen, zoals de winkelwagen en gekochte producten, worden via een onbeveiligde verbinding aangeboden. Daardoor zijn deze gegevens in combinatie met gebruikersnaam en e-mail in te zien. In het geval van eBay was het mogelijk om het volledige verzendadres te achterhalen. Door vijftien procent van het wifi-netwerk van de universiteit van Columbia een maand lang in de gaten te houden, wisten de onderzoekers uiteindelijk 282.000 kwetsbare accounts te detecteren.

https black hat

De bevindingen hebben ook gevolgen voor het Tor-netwerk, zo zeiden de wetenschappers. Door een exitnode dertig dagen met toestemming in de gaten te houden bleek dat ongeveer driekwart van al het verkeer via http verliep. Om privacyredenen konden zij geen cookies meten, maar op basis van het percentage aan onbeveiligd verkeer kan aangenomen worden dat een groot deel van de gebruikers kwetsbaar is.

Een mogelijk oplossing voor dit probleem is hsts. Dat zorgt ervoor dat de server aan de browser laat weten alleen een https-verbinding te gebruiken. Deze techniek werkt echter alleen naar behoren als alle subdomeinen van een website via https te benaderen zijn. Dit gebeurt echter niet altijd, zo was account.google.com via https te benaderen, maar google.com/account niet. Dit heeft Google overigens in de laatste vijf dagen opgelost, aldus de onderzoekers. Ook hebben veel sites grote gedeeltes met legacy-systemen, waardoor die delen onbeveiligd blijven.

De wetenschappers hebben de betreffende bedrijven in november gewaarschuwd, waarna sommige ondernemingen actie hebben ondernomen. Andere bedrijven lieten onder andere weten dat 'de nieuwe applicaties wel beveiligd zullen zijn' en dat 'dit soort risico's nu eenmaal geaccepteerd moeten worden'. Een mogelijke oplossing voor gebruikers is het installeren van de extensie https everywhere van de Electronic Frontier Foundation. De onderzoekers merken op dat dit echter niet altijd werkt en soms problemen oplevert met bepaalde sites.

Moderatie-faq Wijzig weergave

Reacties (36)

Misschien wat achtergrond info voor sommige: cookies worden elk request (voor hetzelfde domein) dmv headers mee verzonden. Wanneer er dus een request tussen zit die onversleuteld is, worden (indien niet goed ingesteld en dat is vaak het geval) die cookie headers vrolijk meegestuurd door de browser. Je hoeft dan alleen dat request te onderscheppen en die headers aan je eigen request toe te voegen en je bent binnen..

Dit gedrag kan worden voorkomen door gebruik te maken van secure cookies. Dat is simpelweg een flag die de browser verteld dat hij het cookie alleen mag meesturen als het een beveiligde verbinding betreft. Maar die flag wordt vaak vergeten, of soms bewust niet aangezet omdat je ingelogd moet blijven op onbeveiligde delen van de site.

[Reactie gewijzigd door BlackHawkDesign op 5 augustus 2016 08:19]

Het gebruik van een secure flag op cookies is inderdaad het punt hier, maar niet iets nieuws. Dit wordt als "nieuw" onderzoek gepresenteerd, terwijl het gaat om een standaard beveiligingsmaatregel die al in de jaren '90 gedocumenteerd is.
Ik adviseer meestal naast de secure flag, ook de http flag. Veel cookies hoeven niet door script ingezien of gebruikt te worden (de browser voegt ze toe op de ajax/rest request), dat regelt deze flag.

---
Daarnaast adviseer ik vaak geen datum toe te voegen, wat ook wel 'sessie cookie' wordt genoemd. Dit betekend niet dat de server een sessie onthoud (statefull is), maar dat de client state (cookie) bewaard tijdens de browser sessie.

De impact is dat de cookie in memory komt - niet op disk - en na afsluiten van de tab, na 10 minuten wordt verwijderd door de meeste browsers.

Voor veel situaties voldoet zo'n cookie prima.

[Reactie gewijzigd door djwice op 5 augustus 2016 13:59]

Redirect van HTTP naar HTTPS al door de webserver of reverse proxy laten afhandelen, dan vindt die al plaats voor je de applicatie achter de webserver bereikt en dus voor er een cookie wordt geplaatst...
Maar als de browser al een cookie heeft, en eerst met http verbinding maakt, dan wordt die vrolijk meegestuurd, en kan dus uitgelezen worden.
Ik run zelf een kleine site volledig op https. Via de apache redirect wordt er geen enkel moment via http iets geserveerd.

Is er nu een reden dat de grote sites onderscheid maken tussen sommige delen wel en sommige delen niet via https? Is dat een performance keuze?
Via de apache redirect wordt er geen enkel moment via http iets geserveerd.
Dan serveer je via HTTP in ieder geval redirects. Of je iets via HTTP serveert is eigenlijk niet eens relevant.

Het gaat er om of er cookies worden meegestuurd als een gebruiker via HTTP verbinding probeert te maken. Zie ook de reactie van @BlackHawkDesign.

Je kan alles via HTTP doen, maar als je geen HSTS gebruikt dan gaat je browser alsnog naar de HTTP variant van de site als de gebruiker een URL voor je site intypt. Zodra er verbinding wordt gemaakt worden alle cookies voor je domein die geen 'secure' flag hebben onbeveiligd over het internet gestuurd.

Daarna wordt de gebruiker in jouw geval doorgestuurd maar dan is het al te laat. De cookies zijn dan al beschikbaar, een attacker kan vervolgens die cookies inzetten op jouw HTTPS site.

Dus:
- Gebruik HSTS als 100% van je pagina's en content via HTTPS gaat
- Gebruik de 'secure' flag voor cookies die er echt toe doen

Je kan prima HTTP gebruiken, zolang je dan maar een heel duidelijk onderscheid maakt tussen cookies. Je kan iemand laten inloggen, de sessiecookie geef je een 'secure' flag en je zet ook een simpele 'personalisatie' cookie die er alleen voor zorgt dat wat layout voorkeuren zichtbaar worden op HTTP pagina's. Alle gevoelige informatie (bij voorkeur ook accountnaam e.d.) zet je dan op HTTPS pagina's waar de secure cookie wordt gebruikt.

[Reactie gewijzigd door bartvb op 5 augustus 2016 09:47]

Je kunt aan HSTS ook de preload flag toevoegen. Dan kun je je site daarna aanmelden zodat de meeste grote browsers (Chrome, Firefox, IE, Tor, ..) zelfs bij het eerste request ooit, nooit een http verbinding zullen op proberen te zetten.

Vergeet ook niet DNSsec aan te zetten :)

[Reactie gewijzigd door djwice op 5 augustus 2016 23:16]

Diverse browsers gebruiken de lijst die bijgehouden wordt hier:
https://hstspreload.appspot.com/
Tweakers gebruikte tot nog niet zo heel lang geleden ook alleen HTTPS voor het inlog-gedeelte. Zie plan: Dilemma: moet Tweakers https inzetten? voor de redenen voor het lange uitstel. Heeft veel met performance te maken, maar ook om het goed te doen. Zodra je user content kan embedden moet je er ook voor zorgen dat die content 100% HTTPS is, anders geeft de browser veel naardere waarschuwingen dan als je gewoon helemaal geen HTTPS gebruikt.
HSTS is inderdaad een oplossing, HSTS preloading is daarentegen echt een draak.
  • Totaal niet schaalbaar, het is een statische lijst in de code van de browser
  • Mag alleen op je hoofddomeinnaam (omdat het dus niet schaalbaar is), al je subdomeinnamen moeten ook gelijk https hebben
  • Geen controle over de lijst, je kan een removal aanvragen, maar dan moet je nog steeds wachten op een browser update
  • Stricte eisen aan je HSTS configuratie
Ik kan zo al 2 betere oplossingen bedenken:
  • Een waarde in de TXT record van je DNS record die aangeeft dat HTTPS moet worden gebruikt
  • Een lege OPTIONS/HEAD HTTP request naar de website waarin de website de HSTS headers teruggeeft
Een waarde in de TXT record van je DNS record die aangeeft dat HTTPS moet worden gebruikt
Dat werkt natuurlijk alleen maar goed als je DNSSEC gebruikt, anders blijft daar een gat zitten.
Een lege OPTIONS/HEAD HTTP request naar de website waarin de website de HSTS headers teruggeeft
En hoe beveilig je dat dan?
DNSSEC wordt meer en meer gemeengoed. Dat het nog niet overal gebruikt wordt is geen reden om het niet te gebruiken voor communicatie over HTST. Lijkt me eigenlijk ook een veel betere oplossing. Als je server nu eenmaal per ongeluk HTST-headers heeft uitgestuurd zit je aan HTST vast. Ik spreek uit ervaring: ik had (gelukkig op een test-domein) een ISPConfig beta geinstalleerd. Iemand had daar overijverig ingesteld dat ISPConfig HTST-headers uitstuurde. Gevolg: er konden geen niet-HTTPS websites meer geserveerd worden want die werden door de browser geweigerd. Gelukkig is dit er snel weer standaard uit gehaald na een bugreport door mij, het moet nu door de administrator aangezet worden.

Het idee achter HTST is leuk, maar er mist een essentieel onderdeel. Dat aanleveren via DNS (beveiligd middels DNSSEC) lijkt me ideaal. Mocht je je domeinnaam ooit overdragen dan zadel je de nieuwe eigenaar ook niet direct met een HTTPS-verplichting op. Overigens net zo goed voor verificatie van certificaten. Als we nu gewoon de SSL certificate authorities laten vallen en in plaats daarvan een public/private key pair gebruiken waarbij de public key in de DNS gepubliceerd wordt kun je alles controleren met de zekerheid dat je daadwerkelijk praat met het domein waarmee je denkt te praten. Eigenlijk exact hetzelfde resultaat als middels een certificate authority, alleen is er dan geen derde partij bij nodig. Er is al zoiets in de vorm van DANE, maar echt gemeengoed is dat nog niet helaas.

[Reactie gewijzigd door MadEgg op 5 augustus 2016 09:34]

Ik kan zo al 2 betere oplossingen bedenken:
  • Een waarde in de TXT record van je DNS record die aangeeft dat HTTPS moet worden gebruikt
  • Een lege OPTIONS/HEAD HTTP request naar de website waarin de website de HSTS headers teruggeeft
Beide kunnen onderschept en gewijzigd worden door een MitM aanval met als doel om de HSTS headers te verminken en HSTS dus uit te zetten, of juist met als doel om HSTS aan te dwingen op sites die geen HTTPS endpoint hebben en deze sites onbereikbaar te maken.

Dus nee; dat zijn geen betere oplossingen...
Want? Een MitM kan je simpelweg detecteren met behulp van DNSSEC. Dan klopt de ondertekening niet meer, en wil je dus een grote waarschuwing geven dat het domein niet in orde is en dus niet bezocht kan worden.

De DNS/TXT oplossing dan. Een extra HEAD-request doen lijkt me killing voor de performance dus sowieso geen goed idee.
De extra HEAD request hoef je natuurlijk maar 1 keer te doen, daarna heb je de HSTS headers dus dan hoef je hem niet meer te doen.
En als er dan geen HTST headers verstuurd worden? Blijf je dan HEAD requests doen voor elke request?
1 keer per browsersessie wellicht? Of het voor een bepaalde tijd cachen.
Want? Een MitM kan je simpelweg detecteren met behulp van DNSSEC. Dan klopt de ondertekening niet meer, en wil je dus een grote waarschuwing geven dat het domein niet in orde is en dus niet bezocht kan worden.
Dan zouden clients die gaan connecten ook enkel en alleen de feature moeten ondersteunen over DNSSEC en dat is veel te limiterend.
Want? Alle TLD's ondersteunen al DNSSEC dus het is puur laksheid en verkeerde prioriteiten stellen als je wel HTST (preloaded) wil en geen DNSSEC configureerd...
Daar heb je gelijk in. DNS heeft DNSSEC, de OPTION/HEAD zou je inderdaad kunnen MitM'en.
HSTS is inderdaad een oplossing, HSTS preloading is daarentegen echt een draak.
  • Geen controle over de lijst, je kan een removal aanvragen, maar dan moet je nog steeds wachten op een browser update
Google controleerd actief of je preload header er nog is, zo niet, dan wordt je domein bij de volgende update uit de lijst gehaald.
Google en Mozilla updaten zo regelmatig, dat moet niet het probleem zijn, toch? (hooguit 1 tot 2 sprints wachten op de update).

De processen rondom HTST preloading zijn dus m.i. enorm verbeterd. Naar mijn idee zelfs zeer goed.

Dus zeker geen draak meer, zoals voorheen. Hoewel uitschrijven ook gewoon 3x klikken en domeinnaam invullen in een webformuliertje was, ook niet echt hoog dravend complex, toch?

De vraag is eigenlijk, waarom wil je nog perse http naast https? Met http/2 zie ik het nut niet.

[Reactie gewijzigd door djwice op 5 augustus 2016 23:29]

"Chrome has not yet removed any domains from the preload list for failing to keep up the requirements after submission, but there are plans to do so in the future."

Het gaat erom dat je er zelf geen controle over hebt maar dat je moet aankloppen bij Google. En het feit dat je moet wachten op de volgende browserupdate.

Het is gewoon een rare oplossing om de preloading zo te doen en ik hoop dat er snel een alternatief komt.
Preloading is toch juist bedoeld dat de browser iets over jou site weet voordat hij contact heeft gehad, en zonder eerst een ander request te doen.

Hoe zou je het anders en veilig willen doen? Een lijst met trusted authorities wordt ook pas met een update hewijzihd, toch?

En waarom wil je nog http? Zeker voor een domein dat al https had?

Ik denk dat de makers van preloading net als ik, daar geen logische reden voor kunnen bedenken, en dat daarom het verwijderen uit de lijst pas een latere implementatie is.

[Reactie gewijzigd door djwice op 5 augustus 2016 23:36]

Klopt, dat is wat preloading is.

Zoals hierboven besproken is zou een TXT record in je DNS met DNSSEC ook prima zijn en dan heb je er zelf helemaal controle over.

En wie zegt dat ik nog http wil? Ik ben juist voor HSTS, ik ben alleen tegen HSTS preloaden (in ieder geval in de huidige vorm).

Edit:
zie nu dat mijn vorige opmerking iets verkeerd verwoord is. Dit is geen rare manier voor preloaden, ik bedoelde dat ik hoop dat er snel een andere manier komt om https te forceren voordat de eerste request is gemaakt.

[Reactie gewijzigd door Pizzalucht op 5 augustus 2016 23:42]

"Chrome has not yet removed any domains from the preload list for failing to keep up the requirements after submission, but there are plans to do so in the future."
Die informatie is oud, zoals ik ook aan gaf. Je kunt dit zelf valideren op https://chromium.googleso...ecurity_state_static.json

Er is ook een blogpost over geweest, ik kan hem helaas zo 1-2-3 niet vinden. Maar met bovenstaande link, heb je de core: er worden al meer dan een jaar ook sites verwijderd van de lijst.

[Reactie gewijzigd door djwice op 5 augustus 2016 23:50]

Ik zie in die commits alleen maar records die handmatig zijn verwijderd?
Ja, ik nu ook. Gek.
De preload lijst is publiek, dus wellicht zelf een script schrijven dat automatisch updates doet.

Welicht eerst automatisch het formulier invult en een standaard bericht er in, 'bot detected incompliance': no preload header anymore.

Met github linkje naar code van de bot, in de hoop dat ze het overnemen.

En na elke file update draaien :)

Zou werk moeten schelen.

[Reactie gewijzigd door djwice op 6 augustus 2016 11:27]

Natuurlijk zou dat kunnen maar het doet er niet aan af dat het een omslachtige methode is. We gaan zien wat de toekomst ons brengt :)

Ik denk niet dat de HSTS preload lijst het heel lang vol houdt aangezien steeds meer mensen naar HTTPS en HSTS kijken en de lijst op een gegeven moment veel te groot wordt.
Ja, dus je verwacht dat er een soort pre-flight request zal komen zoals het OPTIONS request in gebruikt wordt in REST communicatie?

En je hoopt dit in het DNS systeem wordt toegevoegd.

[Reactie gewijzigd door djwice op 6 augustus 2016 11:53]

Maakt me niet echt uit hoe het wordt toegevoegd. Als het maar veilig is en ik er zelf controle over heb.
Heeft het ook nut om cookies miet te accepteren? Voor mij hoef het niet om bij alle nieuwssites cookies te accepteren. Ik lees het artikel even een dan weet ik genoeg om meer over dat artikel op te zoeken (soms is het achteraf gezien clickbait geweest van bijvoorbeeld Omroep Brabant).

Bij het niet accepteren van dergelijke cookies, loop je dan ook minder gevaar of maakt dat nauwelijks uit?
Het gaat erom of je ermee ingelogd bent. Als je op een nieuwssite cookies krijgt is dat hoogstwaarschijnlijk voor tracking. Daar hebben hackers weinig aan. Voor je eigen privacy is het wel beter om dergelijke cookies niet te accepteren of te verwijderen bij het beeindigen van je browse-sessie.

Het gaat bij dit artikel vooral om sites waar je gevoelige informatie in een account hebt waartoe je middels een cookie toegang krijgt.
Volgende stap is kennelijk het meer promoten van hsts. Aangezien ik steeds meer sites zie, die een poging doen tot https (maar kennelijk niet voor 100%), heeft het "promoten" van https de laatste jaren wel redelijk zijn werk gedaan. Althans ook steeds meer sites die geen gevoelige data verwerken, zie ik https gebruiken

Verbaas me wel dat op het TOR netwerk 3/4 van het verkeer onversleuteld is. Ene kant doet me het ook wel weer deugd, en wordt het waarschijnlijk ook veel/steeds meer gebruikt door privacy-lievende, maar minder technische, mensen zonder kwade intenties.

[Reactie gewijzigd door GuruMeditation op 5 augustus 2016 08:18]

Er is niet 1 techniek waarmee je webapplicatie ineens super veilig is. Het vereist een combinatie van technieken om verschillende lagen van verdediging op te bouwen, om zo gebruikers te beschermen.

HSTS wordt als 1 van de oplossingen genoemd ('strict-transport-security' header), maar je kunt nog een stap verder gaan en naar HPKP (public key pinning) gaan. Daarmee wordt ook de allereerste request naar een website direct over https uitgevoerd. Helaas zijn er nog maar weinig websites die dit gebruiken.

Verder kun je natuurlijk ook de toegang tot cookies blokkeren over http (https flag aanzetten) en het niet toelaten dat javascript uberhaupt je cookies leest (http only flag).

En laten we CSP (content security policy) niet vergeten, waarmee je precies kan aangeven welke onderdelen van een website (stylesheets, scripts, media, frames etc) van welke source geladen mogen worden, zodat je dit niet kunt doen.

Troy hunt heeft een aantal mooie tutorials op Pluralsight staan, o.a. over browser security headers (CSP, HTST etc en how to hack yourself first over hoe je webapplicaties tegen de meeste basisaanvallen beschermt.

Zolang dit soort basisverdedigingen in een groot deel van websites op het internet nog niet wordt toegepast, hebben we nog een lange weg te gaan voordat we een (veiliger) internet hebben. 100% veiligheid zal echter altijd een illusie blijven.

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True