> 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...
----------------------------------------------------------------------
CONFIDENTIALITY: This e-mail and any files transmitted with it are
confidential and intended solely for the use of the recipient(s) only.
Any review, retransmission, dissemination or other use of, or taking
any action in reliance upon this information by persons or entities
other than the intended recipient(s) is prohibited. If you have
received this e-mail in error please notify the sender immediately
and destroy the material whether stored on a computer or otherwise.
----------------------------------------------------------------------
DISCLAIMER: Any views or opinions presented within this e-mail are
solely those of the author and do not necessarily represent those
of Corsaire Limited, unless otherwise specifically stated.
----------------------------------------------------------------------
Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF
Telephone: +44(0)1483-226000 Email:info_at_corsaire.com
-------------------------------------------------------------------------
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
--------------------------------------------------------------------------
Received on May 03 2006
Intro
