Title: Multiple Browser Cookie Injection Vulnerabilities Risk Rating: Low Software: Multiple Web Browsers Platforms: Unix and Windows Author: Paul Johnston <paul@westpoint.ltd.uk> assisted by Richard Moore <rich@westpoint.ltd.uk> Date: 15 September 2004 Advisory ID#: wp-04-0001 URL: http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt CVE: Multiple assigned, see main text
Overview --------
A design goal for cookies is to "prevent the sharing of session information between hosts that are in different domains." It appears current implementations are successful at allowing a domain to keep its cookies private. However, multiple mechanisms have been discovered for one domain to inject cookies into another. These could be used to perform session fixation attacks against web applications.
Recommendations: * Affected browsers be patched for these vulnerabilities. * Web applications implement application layer mitigations for session fixation attacks, as described in [2].
Tested: Internet Explorer 6.0 for Windows 2000, all patches Konqueror 3.1.4 for SuSE 9.0 Mozilla Firefox 0.9.2 for Windows 2000 Opera 7.51 for Windows 2000
Cross-Domain Cookie Injection ----------------------------- Vulnerable: Konqueror CAN-2004-0746 Internet Explorer CAN-2004-0866 Mozilla CAN-2004-0867 Not vulnerable: Opera
By default, cookies are only sent to the host that issued them. There is an optional "domain" attribute that overrides this behaviour. For example, red.example.com could set a cookie with domain=.example.com. This would then be sent to any host in the .example.com domain.
There is potential for abuse here, consider the case where red.example.com sets a cookie with domain=.com. In principle this would be sent to any host in the .com domain. However [1] requires browsers to reject cookies where:
"The value for the Domain attribute contains no embedded dots"
This prevents a cookie being set with domain=.com. However, this does not extend to country domains that are split into two parts. For example, red.example.co.uk could set a cookie with domain=.co.uk and this will be sent to all hosts in the .co.uk domain. Mozilla follows the RFC exactly and is vulnerable to this. Konqueror and Internet Explorer have some further protection, preventing domains of the following forms:
* Where the 2nd level domain is two or fewer characters, i.e. xx.yy or x.yy * Domains of the form (com|net|mil|org|gov|edu|int).yy
This does prevent .co.uk cross domain cookie injection but does not protect all domains. For example, the following .uk domains are unprotected:
When testing with Opera, it appeared that browser always correctly detected the domain. It is not immediately clear how Opera does this check.
Example exploitation: 1) http://example.ltd.uk/ is identified for attack. It uses the "sid" cookie to hold the session ID. 2) Attacker obtains attacker.ltd.uk domain 3) User is enticed to click link to http://attacker.ltd.uk/ 4) This site sets the "sid" cookie with domain=.ltd.uk 5) When user logs into example.ltd.uk, they are using a sesion ID known to the attacker. 6) Attacker now has a logged-in session ID and has compromised the user's account.
Exploitation is dependent on the user clicking an untrusted link. However, it is fundamental to the use of the web that we do sometimes click untrusted links. This attack can happen regardless of the use of SSL.
Cross Security Boundary Cookie Injection ---------------------------------------- Vulnerable: Internet Explorer CAN-2004-0869 Konqueror CAN-2004-0870 Mozilla CAN-2004-0871 Opera CAN-2004-0872
By default cookies are sent to all ports on the host that issued them, regardless of whether SSL is in use. There is an optional "secure" attribute that restricts sending to secure channels. This prevents secure cookies leaking out over insecure channels. However, there is no protection to prevent cookies set over a non-secure channel being presented on a secure channel. In general to maintain proper boundaries between security levels, it is necessary to defend against both attacks - protecting both confidentiality and integrity.
Example exploitation: 1) https://example.com/ identified for attack, which uses "sid" cookie as session ID. 2) User is enticed to click link to http://example.com/ 3) By some mechanism the attacker intercepts this request and sets the "sid" cookie 4) When user logs into https://example.com/ they are using a sesion ID known to the attacker. 5) Attacker now has a logged-in session ID and has compromised the user's account.
In addition to the user clicking an untrusted link, exploitation is dependent on the attacker tampering with non-SSL network traffic. This is a reasonable assumption as the purpose of SSL is to provide security over an insecure network.
