Re: [WEB SECURITY] cookies a fundamental threat?

[Achim Hoffmann <kirke11 () securenet de>]

Thanks to Brian to open a new thread [5] on this subject.

First of all I guess that there is a need to point to the right context
where my statement (see subject) was made:
  it was in reply to Amit's [2] "There is no such thing as path security"
so please don't confuse this issue with a more general "cookies are insecure".

In the other thread "Fundamental error in Corsaire's paper?" starting at [1])
the focus is more on difference in other statements, not on cookies. Hence I
didn't go into details why cookies can be insecure and therefore a threat
for web applications.
Now we have a new thread [5] to discuss this in detail. I guess that it will
get a long one.
-----------------------------

Said this, I'll try to explain why there is a threat, sometimes ..

In the majority of cases web applications use cookies to transport the
session ID or the like. Cookies, in this case, are commonly used as synonym
for session ID. When I say that cookies are a threat to web applications,
I only refer to this usage of cookies.
> From this point of view, we have to look at all parts of this technique,
staring at the RFC, looking at the browser behavious, and how developers
currently use and rely on this. Finally we probably find and agree on
best practice according web application security.

When I said threat for web applications, it was according the problems
identified by Amit Klein [8] in contrary/difference to Martin O'Neal [7].
In addition to the discussion if cookie paths are something secure, I've
thrown in my observations about different browser behaviours [3] still
waiting for answers there:).

If we look at all these problems, which should not exist according the RFCs,
we see that cookie paths are something unreliable.
In addition to that, rule number one when talking about web application
security is "verify all input". But how would an application verify/validate
a cookie path? Simple question, simple answer: it cannot. Dot.
(Note: I'm not talking about cookie2 according RFC2965, or cookies with proper
encrypted value including the path)

As Amit said [4], the browser vendors should not be blamed.
Others say that application developers should not be blamed 'cause there're
so many applications, frameworks, tools in the wild which support cookies.
So the question remains: where to fix the security issue?

Application devolpers argue that they use standards (RFC), but they forget
to tell you that this standard relies on many things which could not be
enforced by the application. A hazardous trustment, IMHO.

Here are some threats which exists with the current usage of cookies, some of
them have been shown by others many times before. The follwoing list is
incomplete, just a few examples.

Problems which occour only with cookies, but not with hidden fields:
  - cookie theft anywhere in the application
  - cookie theft anywhere in the same domain (see [7], [8])
  - cookie fixiation anywhere in the domain
These attacks are simple (just XSS) and are well known since a long time.
Even applications free of XSS vulnerabilities can be attacked.
These vulnerabilities lead to attacks like session hijacking, session fixation,
session riding (aka CSRF, web trojan) and some sort of DoS.
Additonally cookies are prone to attacks on server level (HTTP header for
example TRACE method). Keep in mind, that, even worse, the web server (TRACE
method) is not under control of the application nor its developers, usually.
In contary hidden fields can only be attacked within the application itself,
more specific in the page they are used. Session riding is impossible, session
fixation very hard, just session hijacking remains but is not simple too (I'm
talking about automated attacks, not shoulder surfing).

If we just compare this, there is one single point for an attack to hidden
fields, while cookies can be attacked anywhere, infinite posibilities ...
Using paths and secure flags for the cookie reduces the number of potential
attack points, but still not to one.

That's why I said that cookies are a threat to web applications.


Conclusion: if we assume that the sesion ID itself is secure (random, not
predicatble, etc. etc.) 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 and also the server has to be
configurerd properly.
And even if that gets all fixed, the cookie solution suffers from knwon
browser bugs (path issues, cross domain issues, etc.).

Please correct me if I'm wrong.


Final note: I won't claim that hidden fields are better than cookies. I've
just shown a few examples where cookies loose. There're other techniques
like URL rewriting or basic/digest authentication, which all have their
pros and cons too.
Also note that anthing described here just covers the application's view of
security, in particular I don't care about sniffing, information disclosure
in logfiles or browser bugs, just on what this mailing list is for:
   web application security.

Pointing to the problems and vulnerabilities is one part of web application
security, giving solutions or best practice another one. Up to now I left
out the best practice part, simply 'cause I guess there is no simple
to use suggestion, at least I don't know of any general one.
Hopefully the discussion here sheds more light on these problems.


{-: Achim


References
* Fundamental error in Corsaire's paper?
  [1] http://www.webappsec.org/lists/websecurity/archive/2006-04/msg00061.html
  [2] http://www.webappsec.org/lists/websecurity/archive/2006-04/msg00108.html
  [3] http://www.webappsec.org/lists/websecurity/archive/2005-11/msg00097.html
  [4] http://www.webappsec.org/lists/websecurity/archive/2006-04/msg00105.html
* cookies a fundamental threat?
  [5] http://www.webappsec.org/lists/websecurity/archive/2006-04/msg00113.html
  [6] http://www.webappsec.org/lists/websecurity/archive/2006-04/msg00114.html
* Crosaire Paper
  [7] http://www.corsaire.com/white-papers/040323-cookie-path-best-practice.pdf
* Path Insecuirty
  [8] http://www.webappsec.org/lists/websecurity/archive/2006-03/msg00000.html



-------------------------------------------------------------------------
Sponsored by: Watchfire

Watchfire's AppScan is the industry's first and leading web application 
security testing suite, and the only solution to provide comprehensive 
remediation tasks at every level of the application. Change the way you 
think about application security testing - See for yourself. 
Download a Free Trial of AppScan 6.0 today!

https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007kaF
--------------------------------------------------------------------------