Paper: Weaning the Web off of Session Cookies
Timothy D. Morgan
I would like to bring your attention to a paper I published today:
http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
It includes a few minor security problems with HTTP authentication
dialog boxes and password managers in several browsers.
More importantly, it makes an argument for a few small changes to
browser behavior and/or standards. I would hope that Mozilla
developers could take a look and provide any feedback. I'm
particularly interested in opinions on the suggested 401 response
behavior change. I have submitted this information to other browser
vendors as well.
thanks!
tim
Daniel Veditz
> I would like to bring your attention to a paper I published today:
> http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
>
> It includes a few minor security problems with HTTP authentication
> dialog boxes and password managers in several browsers.
This is an area Mozilla has been interested in. You should talk to our
"Mozilla Labs" folks who have been working on Identity in the browser.
They are coming at it from a different angle but there's a lot of
overlap between the problems you and they are trying to solve.
http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
http://mozillalabs.com/blog/2009/05/identity-in-the-browser/
I have a quibble with your section on HTTPOnly cookies. By mentioning
only IE by name when you follow with "other browsers have been slow to
adopt this feature" people will naturally assume that includes Firefox,
the only other browser with significant marketshare. Firefox has
supported HTTPOnly since 2007. Although perhaps "slow" compared to when
Microsoft invented the feature that's pretty irrelevant for a paper
written three years later when nearly all Firefox users will have
support for it.
Continuing that quote with "and continue to have difficulties fully
enforcing this rule in light of newer features (such as AJAX
requests/responses)" people will again assume Firefox, when Firefox was
the first to get this right and in fact IE is one of the browsers with
difficulties. You don't have to take my word for it, this is right in
the OWASP chart linked to from your paper and in the "[16]" link from
that chart to one of the OWASP author's blog
http://manicode.blogspot.com/2009/02/firefox-3006-httponly-champion.html
> More importantly, it makes an argument for a few small changes to
> browser behavior and/or standards. I would hope that Mozilla
> developers could take a look and provide any feedback. I'm
> particularly interested in opinions on the suggested 401 response
> behavior change. I have submitted this information to other browser
> vendors as well.
Your proposal to reinterpret 401 headers is clever and if the IETF HTTP
working group agreed with this interpretation Firefox would follow. The
IETF is currently working on (finishing up) an HTTP revision to clarify
things and you should bring this up with them. In practice, though, I
can't see sites adopting it because of the mass of old browsers who will
behave badly for some time. Your new header proposal would be easier to
get adopted since old browsers are no worse off by ignoring it.
You must be the Tim who started the "Past proposals for HTTP Auth
Logout" thread and if so you're already involved in the right place for
that.
-Dan Veditz
EricLaw
> difficulties. You don't have to take my word for it, this is right in
> the OWASP chart linked to from your paper and in the "[16]" link from
> that chart to one of the OWASP author's bloghttp://manicode.blogspot.com/2009/02/firefox-3006-httponly-champion.html
That's perhaps a bit misleading-- IE doesn't treat anything sent in
Set-Cookie2 as a cookie, and hence doesn't attempt to enforce cookie
protections against it. I haven't seen many servers that even attempt
to use Set-Cookie2.
Timothy D. Morgan
Thanks for taking the time to read through it.
> This is an area Mozilla has been interested in. You should talk to our
> "Mozilla Labs" folks who have been working on Identity in the browser.
> They are coming at it from a different angle but there's a lot of
> overlap between the problems you and they are trying to solve.
>
> http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
> http://mozillalabs.com/blog/2009/05/identity-in-the-browser/
Cool, there are some great UI ideas there. I particularly like the
examples that eliminate favicons. ;-)
I would think that moving toward HTTP authentication schemes, such as
digest, would make it much easier to automate a good identity manager.
Would you agree?
> I have a quibble with your section on HTTPOnly cookies. By mentioning
> only IE by name when you follow with "other browsers have been slow to
> adopt this feature" people will naturally assume that includes Firefox,
> the only other browser with significant marketshare. Firefox has
> supported HTTPOnly since 2007. Although perhaps "slow" compared to when
> Microsoft invented the feature that's pretty irrelevant for a paper
> written three years later when nearly all Firefox users will have
> support for it.
>
> Continuing that quote with "and continue to have difficulties fully
> enforcing this rule in light of newer features (such as AJAX
> requests/responses)" people will again assume Firefox, when Firefox was
> the first to get this right and in fact IE is one of the browsers with
> difficulties. You don't have to take my word for it, this is right in
> the OWASP chart linked to from your paper and in the "[16]" link from
> that chart to one of the OWASP author's blog
> http://manicode.blogspot.com/2009/02/firefox-3006-httponly-champion.html
I appologize if this comes out wrong. I do realize that Firefox had
started implementing this some time back, and I didn't intend to call
out Firefox specifically. Firefox clearly has done better than other
browsers with newer XHR impacts. I'll update the wording on that.
> Your proposal to reinterpret 401 headers is clever and if the IETF HTTP
> working group agreed with this interpretation Firefox would follow. The
> IETF is currently working on (finishing up) an HTTP revision to clarify
> things and you should bring this up with them. In practice, though, I
> can't see sites adopting it because of the mass of old browsers who will
> behave badly for some time. Your new header proposal would be easier to
> get adopted since old browsers are no worse off by ignoring it.
I do see your point with adoption. I think a change in newer browsers
to 401s won't badly break existing applications using HTTP auth, but
new applications won't adopt it until the old browser behavior goes
away.
Fortunately, the biggest backward compatibility problem is mostly with
IE. I think most users of other browsers upgrade pretty quickly to
later versions. If Microsoft could be convinced to make this change
and push out a service pack for IE7 & IE8 (yes, I know this is a
stretch), then perhaps developers would be in the clear in 1-2 years.
I have tried to contact the MSRC and submit a newsgroups bug report
against IE8 with this information, but I really don't know what the
best way is to get a hold of standards-oriented IE developers. Do you
know of a good way to contact them?
Another thought I had on performing logouts, which is not presented in
the paper, is that if the XMLHttpRequest W3C standard is finalized and
fully adopted by browsers as is, then one might be able to use
JavaScript to clear credentials much in the same way it is used with
that cute race condition in Firefox currently. (Recall the reference
in my paper how one can initiate an asynchronous call with bogus
credentials, then cancel it before the user is prompted.) If users
aren't prompted at all when the open() method is provided credentials,
then a log out page could just seed it with bogus ones on most (all?)
browsers. This could act as a stop-gap measure to provide log out in
the short term while 401 behavior is changed.
> You must be the Tim who started the "Past proposals for HTTP Auth
> Logout" thread and if so you're already involved in the right place for
> that.
Heh, you did your homework. Yes, I did start that thread.
If you read through the discussion , you'll see that some folks
champion the idea of an explicit log out, while others say
(paraphrasing):
"there's nothing stopping browsers from doing this already"
I proposed the idea of using the 401 processing change and no one
seemed to have a problem with it, but perhaps the thread was dying at
that point.
Let me also highlight a sentence from RFC 2616 related to the 401
response:
"If the 401 response contains the same challenge as the prior
response, and the user agent has already attempted authentication at
least once, then the user SHOULD be presented the entity that was
given in the response, since that entity might include relevant
diagnostic information."
So I actually am thinking my interpretation is the pretty close. If a
user was already logged in and they receive a 401 response, then of
course they had "already attempted authentication" on that request.
So they "SHOULD be presented with the entity given in the response".
Entities of course include, in part, the entity-body. This sentence
also implies that if a user messes up the login once, they should stop
being prompted, but perhaps that doesn't make sense.
Would you be interested in helping me make the case to the HTTP
working group? I think many more IETF folks might get involved in the
discussion if a representative from a major browser kicked things off.
Of course this working group cannot make any real changes to HTTP,
they can only clarify things. But maybe more explicit "MAY" and/or
"SHOULD" language could make it clear what flexibility user agents
have in processing 401s.
Thanks for your feedback,
tim
Daniel Veditz
> Cool, there are some great UI ideas there. I particularly like the
> examples that eliminate favicons. ;-)
>
> I would think that moving toward HTTP authentication schemes, such as
> digest, would make it much easier to automate a good identity manager.
> Would you agree?
We can't control what web sites do, but if we make the experience nicer
more sites may be encouraged to use things like HTTP Auth. Personally
I'd like to see client certs used for auth but we really have a lot of
work to do to make that a pleasant experience for anyone.
> Another thought I had on performing logouts, which is not presented in
> the paper, is that if the XMLHttpRequest W3C standard is finalized and
> fully adopted by browsers as is, then one might be able to use
> JavaScript to clear credentials
As someone who regularly disables JavaScript I'd hate to see client auth
require it.
>> You must be the Tim who started the "Past proposals for HTTP Auth
>> Logout" thread and if so you're already involved in the right place for
>> that.
>
> Heh, you did your homework. Yes, I did start that thread.
No creepy stalking involved, honest :-) I remembered the topic came up
on the httpbis mailing list recently so I went to see if they had
reached any kind of consensus in the group.
Chris Hills
> We can't control what web sites do, but if we make the experience nicer
> more sites may be encouraged to use things like HTTP Auth. Personally
> I'd like to see client certs used for auth but we really have a lot of
> work to do to make that a pleasant experience for anyone.
This is why I try to use OpenID where possible, since my provider
supports certificate login, which removes the necessity from the web
site to support it (as long as it supports OpenID of course).
Timothy D. Morgan
> supports certificate login, which removes the necessity from the web
> site to support it (as long as it supports OpenID of course).
That's handy, but doesn't that mean the website you're accessing will
still use cookies once you're authenticated?
tim
Chris Hills
> That's handy, but doesn't that mean the website you're accessing will
> still use cookies once you're authenticated?
Yes it does :/ But I think it's easier to get sites to implement OpenID
then it is to support HTTP Auth with certificates. Do you think it is
possible to use OpenID without cookies?
Adam Barth
I suspect it's difficult to use OpenID without cookies in today's
browsers. The challenge is you need some way to bind the session to
the user's browser. It might be interesting to think about ways that
browsers could make OpenID (or an OpenID-like federated identity
system) more awesome.
Tim, I need to read your paper in more detail, but could you summarize
what problem you're trying to solve by avoiding cookies?
Adam
Timothy D. Morgan
> > Yes it does :/ But I think it's easier to get sites to implement OpenID
> > then it is to support HTTP Auth with certificates. Do you think it is
> > possible to use OpenID without cookies?
>
> browsers. The challenge is you need some way to bind the session to
> the user's browser. It might be interesting to think about ways that
> browsers could make OpenID (or an OpenID-like federated identity
> system) more awesome.
I think it would be possible to utilize digest authentication's
multi-domain protection spaces along with something like OpenID. Of
course this would almost certainly require changes to standards. Note
that digest authentication can be used to pass cryptographic cookies
between servers, so back-end data transfers aren't necessarily
needed. If browser user interfacdes were just a little bit easier to
work with for HTTP auth generally, then this could be a very viable
option.
> Tim, I need to read your paper in more detail, but could you summarize
> what problem you're trying to solve by avoiding cookies?
Security problems. The introductory paragraphs provide a good
overview of the paper's structure, and the early sections provide the
laundry list of details why cookies are often unsafe in practice. I
look forward to any comments you have.
Thanks!
tim