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:
- cookies a fundamental threat? Brian Eaton (Apr 30)
- Re: [WEB SECURITY] cookies a fundamental threat? Achim Hoffmann (Apr 30)
- Re: [WEB SECURITY] cookies a fundamental threat? Brian Eaton (May 01)
- Re: [WEB SECURITY] cookies a fundamental threat? Achim Hoffmann (May 02)
- Re: [WEB SECURITY] cookies a fundamental threat? Brian Eaton (May 03)
- Re: [WEB SECURITY] cookies a fundamental threat? Achim Hoffmann (May 03)
- Re: [WEB SECURITY] cookies a fundamental threat? Brian Eaton (May 01)
- Re: [WEB SECURITY] cookies a fundamental threat? Achim Hoffmann (Apr 30)
- Re: [WEB SECURITY] Re: cookies a fundamental threat (or risk)? Pilon Mntry (Apr 30)