Hacking Cookies in Modern Web Applications and Browsers
Dawid Czagan (Silesia Security Lab)
Since cookies store sensitive data (session ID, CSRF token, etc.) they are interesting from an attacker’s point of view. As it turns out, quite many web applications (including sensitive ones like bitcoin platforms) have cookie related vulnerabilities, that lead, for example, to user impersonation, remote cookie tampering, XSS and more.
Developers tend to forget that multi-factor authentication does not help if cookies are insecurely processed. Security evaluators underestimate cookie related problems. Moreover, there are problems with the secure processing of cookies in modern browsers. And browser dependent exploitation can be used to launch more powerful attacks.
That’s why secure cookie processing (from the perspective of web application and browser) is a subject worth discussing. The following topics will be presented:
– cookie related vulnerabilities in web applications
– insecure processing of secure flag in modern browsers
– bypassing HttpOnly flag in Safari
– problems with Domain attribute in Internet Explorer
– cookie tampering in Safari
– underestimated XSS via cookie
– HTTP Strict Transport Security (HSTS)
– importance of regeneration
– and more
Why are we interested in Cookies…
Even when an application enforced 2 Factor Authentication, an attacker can gain access by getting the cookies. Security is always measured at the least protected part. If Cookies aren’t correctly protected, then even a 2FA system can be bypassed.
Many testers underestimate the security issues caused by mis-configured Cookie protections. Exploitation of Cookie related issues is not limited to local attacks.
Browsers also have issues dealing with secure Cookie processing. These kind of issues can be combined with application issues to make attacks on cookies more impactful.
What are the consequences of insecure Cookie processing?
- SQL injection
- User impersonation
Secure flag and HSTS
Setting “Secure” on Cookies protects the confidentiality of the cookies by making sure that they are only send over secure connections.
RFC6265 prevents this cookie being sent over unencrypted HTTP, however it specifically allows an attacker to overwrite a cookie in the browser. This allows an attacker to inject a cookie (new or overwriting an existing cookie) that will be used in the HTTPS protected sessions.
HSTS to the rescue… even if a Cookie is not marked as “Secure” an HSTS header will tell the browser to only communicate over HTTPS. Therefore it’s not required to set “Secure” right… wrong!
Although HSTS works fine, as long as it’s supported by all major browsers. This is not the case with HSTS, as Internet Explorer 10 doesn’t support it.
Setting both “Secure” and HSTS is the safest mechanism here… to ensure maximum security.
Importance of regeneration
If session IDs are regenerated after a session change (logon, logout, etc…) then this may allow an attacker access (session fixation).
An attacker who can learn the value of the Cookie prior to the user authenticating, can re-use this knowledge once the Cookie is authenticated.
All Cookies with sensitive data or used within the application should be regenerated on a state change (include CSRF tokens etc…)
Just because the session cookie is deleted by the users browser, doesn’t mean that it’s invalidated on the server. This can lead to issues where the session remains open, however the server still has a valid session.
Problems here are that RFC6265 talks about “reading” the cookie. However non-HTTP API can still write or overwrite depending on how the RFC is understood and implemented.
Specific browsers (e.g. Safari 9) will allow you to overwrite the cookie. This means that an XSS vulnerability can overwrite the Cookie and switch the user into an attacker controlled account. If the user can then be prompted to enter private data into this session, it is exposed to the attacker.
Combining this with the previously seen session fixation issue (Cookie value not changed after state change). This would allow an attacker to set a known Cookie and use it to gain access to a user’s session once they authenticate.
RFC6265 says – When a domain attribute is not specified, then it should only be sent to the domain where it originated.
However Internet Explorer 11 sends this Cookie to all subdomains of this domain.
This can be a real issue where a cookie is set on example.com where a sensitive application lives under example.com/wallet. The cookie is set without the domain attribute, according to the RFC. In Internet Explorer 11 this means that the user will also send this Cookie to sub-domains that are less sensitive, meaning an XSS in test.example.com can read out the Cookie value.
This kind of leakage can happen to externally hosted domains. As the rules only take effect on the Domain name, the fact that the site is hosted externally is incidental, however may expose sensitive data to a 3rd party vendor.
Safari 9 allows comma-separated lists of Cookies (taken from the obsoleted RFC2109)
As this is taken from the request and put into the Set-Cookie header, it allows an attacker fully remotely to tamper with the Cookie jar of the user. This allows changing the users account, as discussed previously.
It’s also possible to perform XSS via Cookie without locally setting a Cookie.
Underestimated XS via Cookie
Commonly this issue has a low assigned risk as the Cookie value has to be set locally. However if you can gain access to a low sensitive website on a subdomain like x.example.com, you can set a Cookie for y.example.com in order to exploit the user without local access to the browser.
Response splitting also allows exploitation of this issue, by allowing an attacker to set a Cookie by injecting a Set-Cookie header to place the XSS into the browser’s Cookie Jar.
- Educate development teams about the risks of Cookies
- Discuss/improve RFC 6265
- Cooperate with Browser vendors