image

CERT/CC waarschuwt voor cookie-lek in browsers

vrijdag 25 september 2015, 12:07 door Redactie, 4 reacties

Een probleem met de manier waarop HTTP-cookies worden geplaatst kan ervoor zorgen dat aanvallers HTTPS kunnen omzeilen en privégegevens kunnen stelen, zo waarschuwt het CERT Coordination Center (CERT/CC) van de Carnegie Mellon Universiteit. Het probleem speelt in alle grote browsers.

Het probleem is dat de standaard voor cookies geen mechanisme specificeert voor scheiding en integriteit en browsers niet altijd de domein-instellingen van een cookie authenticeren. Een aanvaller kan dit gebruiken om een cookie te plaatsen die later voor een HTTPS-verbinding wordt gebruikt, in plaats van de cookie van de betreffende website. Een aanvaller kan zodoende een cookie voor example.com op de computer plaatsen die het echte cookie voor www.example.com overschrijft als het slachtoffer HTTPS-content laadt. Door een andere kwetsbaarheid in de server te gebruiken kan het cookie van de aanvaller worden gebruikt om privégegevens te verkrijgen.

De onderzoekers die het probleem tijdens het laatste USENIX Security Symposium besproken stellen dat een cookie een zogeheten "secure flag" kan bevatten, wat aangeeft dat het alleen over een HTTPS-verbinding moet worden gestuurd. Er is echter geen corresponderende flag die aangeeft hoe het cookie is geplaatst. Een aanvaller kan via een man-in-the-middle zodoende cookies injecteren die voor latere HTTPS-verbindingen worden gebruikt. Volgens het CERT/CC zijn er wel pogingen voor veiliger cookiebeheer ondernomen, maar zijn die allemaal mislukt vanwege een gebrek aan een wijdverbreide geïmplementeerde standaard.

Als oplossing stelt de organisatie dat de standaard voor cookies mogelijk moet worden aangepast. In de tussentijd adviseren de onderzoekers aan websites om HSTS (HTTP Strict Transport Security) voor het top-level domein in te stellen en de "includeSubDomains" optie te gebruiken. Dit voorkomt gedeeltelijk de mogelijkheid van een aanvaller om top-level cookies te plaatsen die de cookies voor een subdomein, zoals www.domeinnaam.tld, overschrijven. Eindgebruikers krijgen het advies om de meest recente browserversie te gebruiken. Met name IE-gebruikers doen hier verstandig aan. Internet Explorer 11 is namelijk de enige IE-versie die HSTS ondersteunt.

Reacties (4)
25-09-2015, 12:36 door meinonA
Hoe installeer ik Internet Explorer 11 in Windows XP?

Oftewel: achterlijk advies omdat dat helemaal niet kan.
25-09-2015, 13:06 door Anoniem
Door meinonA: Hoe installeer ik Internet Explorer 11 in Windows XP?

Oftewel: achterlijk advies omdat dat helemaal niet kan.

Lijkt me een misplaatste qualificatie aangezien jij gebruik blijft maken van een niet meer ondersteund OS.
25-09-2015, 13:31 door karma4
Door meinonA: Hoe installeer ik Internet Explorer 11 in Windows XP?
Oftewel: achterlijk advies omdat dat helemaal niet kan.
Het is achterlijk dat je als desktop nog steeds terug wilt vallen op iets uit de verre oudheid (2001), Doe een upgrade.
De mac lisa en ZX-80 krijg je niet over, die zijn maar 2 resp 3 keer zo oud.
25-09-2015, 16:01 door Anoniem
Tja, een up to date OS en een up to date browser zijn wel wenselijk.
In ieder geval dat laatste.

Wellicht is de keuze voor een Mozilla browser met behulp van een optimaal secure configuratie nog wel veiliger te krijgen dan een gemiddelde up to date browser van die gemiddelde gebruiker die helemaal niets configureert.

Met IE bemoei ik me niet zoveel maar wellicht kan je met een Firefox-like browser, wat extra addons* en wat extra aanpassingen in je "about:config" settings nog een heel eind komen.

Wat betreft dit cookie verhaal dacht ik aan een mogelijke optie onder NoScript.
Beoordeel zelf de mate van toepasselijke overlap met het beschreven probleem in het artikel.

https://noscript.net/faq#qa6_4
6.4
Q: What can NoScript do against HTTPS cookie hijacking?

A: HTTPS cookie hijacking happens when a site sets sensitive cookies (e.g. those identifying authenticated sessions) over HTTPS connections but "forgets" to flag them as "Secure". This means that subsequent unencrypted (non-HTTPS) requests for the same site will leak the session cookies away, even if you logged in securely. NoScript provides means to mitigate this issue, configurable in NoScript Options|Advanced|HTTPS|Cookies.

If Enable Automatic Secure Cookies Management is checked, NoScript will try to "patch" insecure cookies set by HTTPS sites on the fly:

1) If the site matches the "Ignore unsafe cookies..." pattern list, NoScript lets its cookies pass through untouched

2) If the site matches the "Force encryption for all the cookies..." pattern list, NoScript appends a ";Secure" flag to every non-secure cookie set by this response

3) Otherwise, NoScript just logs unsafe cookies BUT if no secure cookie is set in a HTTPS transaction setting other (unsafe) cookies, NoScript patches all these cookies with ";Secure" like in #2.
However, if a navigation from an encrypted to a non-encrypted part of the same site (i.e. sharing the same cookies) happens in the same tab, NoScript removes its ";Secure" patch to ensure compatibility. When it happens, this event is logged to the Error Console, along with a recommendation to try forcing HTTPS by listing this site in the HTTPS|Behavior|Force section.

* Vergeet ook https everywhere niet voor het bij voorkeur afdwingen van secure connecties als de keuze er is.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.