WebApp Sec mailing list archives

Re: [WEB SECURITY] cookies a fundamental threat?


From: Achim Hoffmann <kirke11 () securenet de>
Date: Tue, 2 May 2006 09:40:04 +0200 (MEST)

Hi Brian

On Mon, 1 May 2006, Brian Eaton wrote:

!! On 4/30/06, Achim Hoffmann <kirke11 () securenet de> wrote:
!!
!! I think this is where one of us is confused. =)

hmm, I won't say confusing. Session management is a complex task, and you
need to be aware of a lot of details. Hope this discussion sheds some light
on it, at least on some common problems.

!! Amit's note on "Path Insecurity" described how to execute javascript
!! in the context of another document on the same server.  Is "Path
!! Insecurity" somehow limited to XSS attacks on cookies?  I don't
!! believe so; I suspect the same techniques AK used in that paper to
!! steal cookies that were accessible to other documents apply equally
!! well to reading hidden form fields in those documents.

Yes that's true.
But it's still more difficult to access a form field than a cookie. Attacking
form fields needs to know the DOM. The bar is higher for form fields.

!! Assuming I did understand Amit's paper properly, nearly all of the
!! attack techniques you listed in your note apply equally to hidden form
!! fields and cookies.  There are some practical differences.  For
!! example:
!!
!! - Session fixation is easier with form fields than with cookies.  If
!! form fields are used for sessions, a session fixation attack can be
!! performed from any web server.  If cookies are used, it can only be
!! done from another web server in the same DNS domain.  Assuming the
!! application developer does the right thing and changes the session
!! cookie after authentication, session fixation is not possible in
!! either case.

You're right here, but missing a part.
If the session ID is in the cookie, a session is created on the server and the
browser holds the session ID after the session fixation attack and sends it
automatically for (all) following requests.
If the session ID is in a hidden form field, a session is created on the
server and the browser has nothing. To use that session you have to inject
the session ID again in each following request.
Conclusion: with cookies session fixation is -lets say- one URL, while with
hidden fields you need to do it for each request it should apply to.
If the application renews the session ID after creation, both methods could
considered to be safe.
If the application *does not* renew the session ID after creation, the threat
are cookies only (see above).

!! - 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:).

!! 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.
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.

{-: Achim


-------------------------------------------------------------------------
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
--------------------------------------------------------------------------


Current thread: