WebApp Sec mailing list archives
Re: [WEB SECURITY] cookies a fundamental threat?
From: Achim Hoffmann <kirke11 () securenet de>
Date: Wed, 3 May 2006 12:46:17 +0200 (MEST)
On Tue, 2 May 2006, Martin O'Neal wrote: !! > identified by Amit Klein [8] in contrary/difference !! > to Martin O'Neal [7]. !! !! Although we have been around the houses now, there actually doesn't seem !! to be much of a difference between our points of view; both Amit and I !! accept that they don't offer much/any practical security today, but !! would recommend setting them anyway (if only to limit the cookie !! footprint on the server). OK, so we all agree on that. !! > - cookie theft anywhere in the application !! !! To maintain a session, every page of a hidden field application must !! logically be able to process the hidden field (otherwise the session !! would be broken); where would this be different in practice to a cookie !! based application? It's different in the way that the application is responsible to fill in the proper session value in each page (might be a problem with some frameworks, see some more comments below). !! > - cookie theft anywhere in the same domain (see [7], [8]) !! !! This is only really an issue for an application installed into an !! unsuitable environment. For a typical security conscious public facing !! implementation (single domain, single application), then the whole !! cookie path discussion is mostly irrelevant. True, but if all applications would be run on their own server (application isolation) then we would not need to think about such secuity threats. Hence this comment is off-topic (I don't mean it's wrong, it's very good to tell people to do application isolation). Keep in mind: Amit's /foo /bar application example was one of the reason for this discussion. !! - cookie fixiation anywhere in the domain !! !! If you mean session fixation, then hidden fields can happily be attacked !! using equivalent client side techniques. Yes I meant that (still said that I treated cookies as synonym for session ID). But I disagree with "equivalent techniques", as I already described, the cookie can be accessd anywhere in the domain, the hidden field in a single page. Again: one possibility compared to infinite possibilities. !! Caching; Good point. But again, this requires that an attacker finds the cached page and also finds a way to reuse it. I guess this is not that simple, it at least raises the bar for an attacker. BTW, does someone know how to write a JavaScript which continues after doing a hostory.back()? I guess using an intermediate scipt like Amit suggested could do it. !! 304 redirect; Agreed, the application is responsible for a proper session handling, not the client (as with cookies). That's what web application security is about: don't trust the client. !! > That's why I said that cookies are a threat to web applications. !! !! Objectively though you would be more accurate to say 'sessions'; as the !! risks associated with cookies are similar to those affecting hidden !! fields (or other equivalent mechanisms). Again: in my initial post I described that these threats count for cookies which transport session IDs. !! > an application developer has nothing !! > more to do for web application security !! > than ensuring that the page where it is !! > used is secure (free of XSS flaws for example), !! > while with cookies at least the whole application !! > has to fit this requirement !! !! This I would disagree with. To maintain the session throughout the !! application, a hidden field must be able to be processed by the 'whole !! application' or the session would be broken; in practice the challenge !! is identical. hmm, for sure I silently assumed that the application handles the session (including the hidden field for the session ID) proper. Then there is nothing more for the hidden field than the usual checks and validations. While with cookies the application still struggles to identify the reason why it was sent. Anyway, I'm aware that most frameworks do only support cookies and/or URL rewriting. If you mean that by "must be able to be processed", then there is nothing to disagree 'cause that's a missing functionality there. Even this (how do frameworks handle sessions) is fundamental to this discussion, I'd prefer that we open another thread to dicuss enhancement requests for such frameworks. !! > and also the server has to be configurerd properly. !! !! Apart from the TRACE example you have already given, what server !! configuration issues do you feel would exclusively affect only a cookie !! based application? Currently I'm not aware of attacks or alike, but there're problems if the application is load balanced and/or there're WAFs involved. In such cases the network people (load balancer, WAF) recommend to use a more general cookie path and/or domain wild cards. Sigh. Also some application servers are configured with a / path by default (no example handy, sorry). Others (Tomcat?) cannot change the cookie path from the application, that's were the application programmer relies on the server administrator. In other words: the application cannot ensure (parts of) its security, only in conjuction with the server configuration. {-: 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:
- Re: [WEB SECURITY] cookies a fundamental threat? Achim Hoffmann (May 03)
- <Possible follow-ups>
- RE: [WEB SECURITY] cookies a fundamental threat? Tom Stripling (May 03)
- Re: [WEB SECURITY] cookies a fundamental threat? Achim Hoffmann (May 03)
- RE: [WEB SECURITY] cookies a fundamental threat? Martin O'Neal (May 03)
- Re: [WEB SECURITY] cookies a fundamental threat? Achim Hoffmann (May 03)
- RE: [WEB SECURITY] cookies a fundamental threat? Martin O'Neal (May 03)
- RE: [WEB SECURITY] cookies a fundamental threat? Tom Stripling (May 03)
- RE: [WEB SECURITY] cookies a fundamental threat? Evans, Arian (May 09)
- Re: [WEB SECURITY] cookies a fundamental threat? Brian Eaton (May 10)
- RE: [WEB SECURITY] cookies a fundamental threat? Evans, Arian (May 10)