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 that 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 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.
!! 304 redirect;
Agreed, the application is responsible for a proper session handling, not
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 for that.
!! > 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
--------------------------------------------------------------------------
