On 5/2/06, Achim Hoffmann <kirke11@securenet.de> wrote:
!! - It is easier to steal a domain cookie than to steal a hidden form
!! field. To steal a domain cookie, you just need a vulnerable server in
!! the same domain. Stealing a form field requires a vulnerable page on
!! the server hosting the form.
yes, that's what I said (see subject:).
If the advice is "use form fields instead of domain cookies", that
makes plenty of sense. Domain cookies pose a greater risk than a well
targeted form field. But to say that *all* cookies pose the same risk
as domain cookies is a mistake.
Suggesting to someone that they should replace all of their
application cookies with hidden form fields is likely to waste their
time.
!! The one distinct advantage cookies have over form fields is IE's
!! HttpOnly cookie extension. HttpOnly doesn't make attacks impossible,
!! but it certainly does raise the bar a bit.
Here we leave the focus of the threat. Using HttpOnly relies on the browser
but we're talking about web application security.
Have a read of Mozilla defect 178993, comment 49.
https://bugzilla.mozilla.org/show_bug.cgi?id=178993#c49
The comment is from one of the administrators of the LiveJournal web
site. He writes
"... it's ironically Internet Explorer users who have had the least account
break-ins because their cookies haven't been stolen, while Safari/Mozilla have
been vulnerable...."
Think about that. IE is the vast majority of the browser market, and
thus the most appealing target for cookie stealing. Yet HttpOnly was
a strong enough mitigation measure that it was mostly Safari and
Mozilla users who were having their accounts compromised. Arguing
that using the "HttpOnly" attribute on a cookie doesn't count as web
application security makes very little sense.
OTOH... It looks like in late January Live Journal decided there was
no way they could prevent their users from posting malicious
javascript. They changed their entire authentication and session
tracking system so that when cookies did get stolen, the damage would
be less. (http://community.livejournal.com/lj_dev/708069.html?thread=7943397)
As long as there is a wide range of interpretation how the corresponding RFCs
should be implemented (if possible), a web application need to use methods
which all common browsers handle the same way. Such a standard is there with
Cookies2, roughly 6 years old, but it's implemented rarely on both ends.
But noone wants to blame the browser vendors, nor the application developers.
Actually, browsers are fairly consistent in how they handle cookies.
There are a few places where they are inconsistent, so web developers
tend to stay away from relying on those browser "features". For
day-to-day use, web developers can (and do) rely on all the major
browsers to act the same way.
Set-Cookie2 doesn't make much of a difference to web app security. It
clears up several ambiguities in the original cookie specification.
Not all ambiguities in specifications are security problems. If every
vague statement in an RFC was a security risk, the IETF would have a
worse security reputation than Microsoft and Oracle combined. =)
Regards,
Brian
-------------------------------------------------------------------------
Sponsored by: Watchfire
The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------
