Full Disclosure mailing list archives

Browser cookie handling: possible cross-domain cookie sharing


From: Stefan Winter <stefan.winter () restena lu>
Date: Fri, 4 Nov 2005 21:15:50 +0100

Hello list,

I stumbled over a rather strange behaviour in Konqueror and other browsers, 
related to cookie storage and name resolution, that - I think - makes data 
leakage via cookies possible. It needs a special setup, but such setups are 
common (I use the trailing dot notation for FQDNs in this mail to keep clear 
about what's what):
- the computer used must have a domain search-path in case the user enters a 
non-FQDN
- the beginning of the hostname visited must in itself be a host or domain 
name 
Example: search-path==yourcompany.com., host==ap1.com.yourcompany.com.

Then let the user be entering "ap1.com" in the Location Bar, which the 
resolver will - depending on its configuration - expand to 
ap.1.com.yourcompany.com. . In this case, Konqueror (and others) does two 
things: 

1) [minor issue] it asks the user if he wants to accept cookies from the 
_domain_ ap1.com (ap1.com. actually, but it doesn't display the trailing dot 
and can't tell the difference between the host actually meant and the 
top-level domain)
When the user sets this it will not only be valid for the host visited (i.e. 
ap1.com.yourcompany.com.) but also mistakenly for the entire top-level domain 
ap1.com. .
This is not really a big thing, but might fool the user to accepting cookies 
he may not want when he later visits the domain ap1.com. .

2) [bigger issue] when the cookie is accepted, it gets stored in Konqueror's 
cookie store as belonging to the top-level domain ap1.com. .This is a real 
problem: If the user ever truly visits the domain ap1.com. then his browser 
will happily send the cookie with the request, containing whatever (possibly 
sensitive) information is in it (for example, if the host ap1.com is a Cisco 
Access Point and the user was administering it, some of the APs settings are 
contained in the cookie).

Possible solutions: Difficult to solve cleanly, since applications in general 
don't have full control over the workings of the resolver. What seems to be 
at least a quick-and-dirty fix is:
When the user enters something without a trailing dot in the Location Bar, 
look up two hosts:
- the literal input of the user (in the example: "ap1.com")
- the input with a trailing dot added ("ap1.com.")
If the two results are different then the resolver has mangled the host name 
somehow. Then cookies from the host should not be treated as belonging to a 
top-level domain.
If the two results are equal then the host actually is the top-level host.
The cookie store could differentiate between the two cases by saving cookies 
from hosts which pass this check _with_ the trailing dot, and all others 
without the dot (which is the more correct behaviour anyway: host names 
without a trailing dot are relative to some unspecified root and should never 
be treated as top-level).

Not only Konqueror handles cookies this way. As far as I can tell, Mozilla and 
Firefox behave the same, and I haven't checked Opera and IE yet.

Greetings,

Stefan Winter

-- 
Stefan WINTER

Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche - Ingénieur de recherche

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Current thread: