[WEB SECURITY] cookies a fundamental threat?

[Martin O'Neal]

> Keep in mind: Amit's /foo /bar example 
> was one of the reason for this discussion.

Ja, but the example was an exception; two applications hostile to
one-another on a single domain.  Good for demonstrating the issue, but
not a likely production scenario.

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

These are two separate issues; session fixation is a generic attack and
can be used against a session ID, however it is transported (and its
root is a failure in session management logic).  The second issue is
your assertion that the hidden field narrows the attack surface in
someway, which isn't correct.  Every page that must maintain the session
must be able to process the hidden field, making it a possible target.

> But again, this requires that an attacker finds the cached page and
also
> finds a way to reuse it. 

Easily achieved in a shared environment.

> That's what web application security is about:
> don't trust the client.

Actually I disagree with this, and would say the opposite; by their
nature, web applications *implicitly* trust the client.  They have no
inherent mechanism for verifying its integrity at all.

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

But the cookie piece isn't the crux though; it is the session ID
(whether it is transported in a cookie, a hidden field, or in a URI
etc).  Session fixation is about failures in session management, not the
transport mechanism.

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

:P  What I meant was that for an application that uses hidden fields,
*every* page of the application must be able to receive, validate, and
generate HTML output containing the hidden field for the session to be
maintained.  The attack surface (as far as pages to attack) is, in
practice, identical.

Martin...

---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/