Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Become a Partner and License Our Database or Notification Service
Microsoft Internet Explorer Bug in Setting Cookies in Certain Domains May Let Remote Users Conduct Session Fixation Attacks
SecurityTracker Alert ID: 1011332|
SecurityTracker URL: http://securitytracker.com/id/1011332
CAN-2004-0866, CAN-2004-0868, CAN-2004-0869
(Links to External Site)
Updated: Sep 26 2004|
Original Entry Date: Sep 16 2004
Modification of user information|
Vendor Confirmed: Yes Exploit Included: Yes |
A vulnerabiltiy was reported in Microsoft Internet Explorer (IE). A remote user may be able to set cookies on certain domains as part of a session fixation attack.|
Westpoint Security reported that a remote web server can set a cookie on the target user's IE browser for certain country specific top-level domains (TLDs) to cause IE to send the cookies when connecting to any other web servers in the same domain.
Any country specific TLDs that have more than 2 characters in secondary portion of the domain name are affected, except those that use com, net, mil, org, gov, edu, or int. The report notes that '.ltd.uk', '.plc.uk', 'sch.uk', '.nhs.uk', '.police.uk', and '.mod.uk' are examples of affected domains.
This flaw may allow remote users to conduct session fixation attacks to hijack a target user's session. A paper on session fixation attacks is available at:
It is also reported that the browser may send non-secure cookies (i.e., those set via HTTP) to the server via SSL. A remote user with the ability to spoof connections or conduct a man-in-the-middle attack may be able to set a cookie on the target user's browser that will subsequently be sent by the target user's browser to a secure server as part of a session fixation attack.
The vendor was notified on July 20, 2004.
The original advisory is available at:
A remote user may be able to set cookies in certain top-level domains to be sent by the target user's browser when connecting to any server in that domain.|
A remote user may be able to set cookies via a non-secure server to be sent by the target user's browser to a secure server.
No solution was available at the time of this entry.|
Vendor URL: www.microsoft.com/ (Links to External Site)
Access control error, State error|
Source Message Contents
Date: Thu, 16 Sep 2004 11:00:37 -0400|
Westpoint Security Advisory
Title: Multiple Browser Cookie Injection Vulnerabilities
Risk Rating: Low
Software: Multiple Web Browsers
Platforms: Unix and Windows
Author: Paul Johnston <email@example.com>
assisted by Richard Moore <firstname.lastname@example.org>
Date: 15 September 2004
Advisory ID#: wp-04-0001
CVE: Multiple assigned, see main text
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.
* Affected browsers be patched for these vulnerabilities.
* Web applications implement application layer mitigations for session
fixation attacks, as described in .
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
Internet Explorer CAN-2004-0866
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  requires browsers to reject cookies
"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
* 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
When testing with Opera, it appeared that browser always correctly
detected the domain. It is not immediately clear how Opera does this
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
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
Internet Explorer CAN-2004-0869
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.
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
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
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.
 RFC2965 - HTTP State Management Mechanism
 Session Fixation Vulnerability in Web-based Applications
 Persistent Client State - HTTP Cookies
 Cookies and Cookie Handling in Opera 7 Explained
16 July 2004 Vulnerabilities discovered
20 July 2004 Vendors informed
20 July 2004 Mozilla bug opened
The discussion shows that the cross domain problem is a long standing
known bug. However, one contibutor claimed the exploit is being used in
the wild. Several fixes were suggested and it appears this bug will be
No discussion of the SSL vs non-SSL problem.
21 July 2004 Opera respond
The response explains that they take the cross domain problem seriously,
and that they have solved it by doing a DNS lookup on the specified
domain. Some information is available in .
They also explained that they could not solve the cross security
boundary problem without breaking standards and existing web apps.
This problem has previously been reported as the "Cookie Monster bug"
23 July 2004 Konqueror respond
Explain that they intend to fix the cross domain problem by including a
list of ccTLDs that, like .uk, require 3 dots. The domain are:
The brief discussion of the cross security boundary suggests they do not
consider it possible to solve at this time.
23 Aug 2004 KDE Security Advisory released
KDE issue an advisory stating the cross-domain problem is fixed in KDE
3.3. Patches are also available for older 3.x versions.
13 Sept 2004 Vendors notified of impending release
14 Sept 2004 CVE candidates assigned for other issues
15 Sept 2004 Microsoft respond
Best practice for web sites to resist session fixation attacks is to
change the session ID after authentication. They are looking at ways to
address this in the browser. As this may cause compatibility issues and
the issue is low risk, they have not commited to a timeline.
15 Sept 2004 Advisory published
Many thanks to the vendors for their responses. Also, thanks to Steven
Christey for assigning CVE numbers.
Go to the Top of This SecurityTracker Archive Page