Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

IE 7, webauth_at cookie and subdomains

Russ Allbery eagle at
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> 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
> the browser will send that cookie for that domain and
> any subdomains (eg 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, domain-matches but not

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 host and one for  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
same thing.

> For IE 7:
> If a user visits Then logs in with webauth,
> visits 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
even though it shouldn't, but when can't decrypt
the cookie (since it's using the key of 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, you wouldn't have this problem.
Similarly, if you renamed to,
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
   domains.  Consider:

      1. User agent makes request to, gets back
         cookie session_id="1234" and sets the default domain

      2. User agent makes request to, gets back cookie
         session-id="1111", with Domain="".

      3. User agent makes request to again, and

         Cookie: $Version="1"; session_id="1234",
                 $Version="1"; session_id="1111"; $Domain=""

         The server at 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
> 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 requests as the path wouldn't match.
> Another hack would be to have 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>
Technical Lead, ITS UNIX Systems and Applications, Stanford University

More information about the webauth-info mailing list