Search Mailing List Archives
IE 7, webauth_at cookie and subdomains
eagle at windlord.stanford.edu
Mon Jan 5 12:44:24 PST 2009
Sorry about the delay in responding. We were all away for the holiday.
Matthew Buckett <matthew.buckett at oucs.ox.ac.uk> writes:
> We are having an issue with our WebAuth setup here at Oxford.
> Ok a bit of background, if you set a cookie on a domain (eg
> weblearn.ox.ac.uk) the browser will send that cookie for that domain and
> any subdomains (eg beta.weblearn.ox.ac.uk) so long as all the other
> rules apply.
And I believe this is the heart of the problem. This is a serious bug in
IE 7's implementation of the cookie protocol, as near as I can tell.
The relevant RFC is RFC 2965, which says:
Host names can be specified either as an IP address or a HDN string.
Sometimes we compare one host name with another. (Such comparisons
SHALL be case-insensitive.) Host A's name domain-matches host B's if
* their host name strings string-compare equal; or
* A is a HDN string and has the form NB, where N is a non-empty
name string, B has the form .B', and B' is a HDN string. (So,
x.y.com domain-matches .Y.com but not Y.com.)
Note the *requirement* for a leading period in B in order for A to match B
when B is A's parent domain. It is even more explicit in section 3.3:
Domain Defaults to the effective request-host. (Note that because
there is no dot at the beginning of effective request-host,
the default Domain can only domain-match itself.)
WebAuth intentionally does not set a Domain parameter on any of its
cookies because it is trying to create cookies scoped to only that host.
Hence, its cookies should not be sent when connecting to a server that's
in a subdomain of the original host.
Does this works correctly in Firefox? The screen shot you included shows
Firefox happily managing two independent cookies, one for the
beta.weblearn.ox.ac.uk host and one for weblearn.ox.ac.uk. Those two
cookies are unrelated to each other; each host should only get the cookie
relevant to that host. I checked the predecessor standard and it says the
> For IE 7:
> If a user visits weblearn.ox.ac.uk. Then logs in with webauth,
> visits beta.weblearn.ox.ac.uk and attempts to login with webauth they
> repeatedly get redirected to the green tick page. Attached is an
> edited/commented capture of the HTTP headers of such a visit.
> I think reason for this is that weblearn.ox sets the original webauth_at
> cooke and login works, then when visiting beta.weblearn.ox and logging
> in the clearing of the existing webauth_at cookie doesn't work because
> the domain isn't the same as the setting domain,
Right, not only does IE 7 not implement the protocol correctly, it breaks
it in a half-assed fashion. It sends the cookie to beta.weblearn.ox.ac.uk
even though it shouldn't, but when beta.weblearn.ox.ac.uk can't decrypt
the cookie (since it's using the key of weblearn.ox.ac.uk) and hence tries
to clear it and send the user back to WebAuth, then IE 7 realizes that the
cookie is for a different domain and doesn't clear it.
Basically, IE 7 is acting as if all cookies from host A have an implicit
Domain=.A attribute, which is exactly what the standard says it should not
do. But it's only doing this for setting cookies, not for clearing them.
> The correct fix for this would seem to be to have the mod_webauth
> module attempt a login with all webauth_at cookies, or make the cookie
> name specific to the domain (eg webauth_at_beta_weblearn_ox_ac_uk).
Well, the *correct* fix would be for Microsoft to fix IE. :)
But we have a bug in IE, so now the question is how best to work around
it. From a WebAuth perspective, far and away the simplest workaround
would be for you to not use the domain layout that you're using. If you
called the host weblearn-beta.ox.ac.uk, you wouldn't have this problem.
Similarly, if you renamed weblearn.ox.ac.uk to login.weblearn.ox.ac.uk,
you wouldn't have this problem.
Failing that, I'm not quite sure what I think about having the host try
all webauth_at cookies that it receives. One of the known attacks on
cookies is explained in the RFC:
Proper application design can avoid spoofing attacks from related
1. User agent makes request to victim.cracker.edu, gets back
cookie session_id="1234" and sets the default domain
2. User agent makes request to spoof.cracker.edu, gets back cookie
session-id="1111", with Domain=".cracker.edu".
3. User agent makes request to victim.cracker.edu again, and
Cookie: $Version="1"; session_id="1234",
$Version="1"; session_id="1111"; $Domain=".cracker.edu"
The server at victim.cracker.edu should detect that the second
cookie was not one it originated by noticing that the Domain
attribute is not for itself and ignore it.
However, I can't think how this attack could be used usefully with WebAuth
itself. It seems like the most an attacker could do would be to get
someone to log in as them instead of as the expected user, which while
weird doesn't seem likely to cause actual security issues.
The code changes required to try multiple cookies are a bit complicated,
though. The routine to find the cookie would need to keep state and retry
several times. It's not impossible, but it's not trivial either.
Unfortunately, I don't think embedding the hostname into the cookie name
will help. A server may be serving multiple different hosts, and I'm not
sure that it's always going to know what hostname to look for in a cookie,
particularly in the presence of internal redirects and the like. I think
implementing that reduces to trying all webauth_at cookies that it finds,
so the above solution would be simpler.
> A quick hack would be to have the mod_webauth filter on
> weblearn.ox.ac.uk set it's webauth_at cookie with a path of /site/ (at
> the moment it has a path of /) which would mean it wouldn't get supplied
> on beta.weblearn.ox.ac.uk requests as the path wouldn't match.
> Another hack would be to have weblearn.ox.ac.uk clear the original
> webauth_at cookie after login as we only need webauth for one request
> as we store information associated with another cookie after that.
Yes, both of those would work, although I think an even easier solution
would be to change your host naming scheme.
At the very least, I'll definitely document this problem.
Russ Allbery <eagle at windlord.stanford.edu>
Technical Lead, ITS UNIX Systems and Applications, Stanford University
More information about the webauth-info