Hiya chap,
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).
which should not exist according the RFCs
The RFC standards that cover the technologies used in a typical HTTP
transaction are varied, conflicting, vague and in my experience there is
definitely *not* a universal consensus (amongst vendors or third-parties
alike) in regard to which provide a definitive version of events.
- 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?
- 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.
- cookie fixiation anywhere in the domain
If you mean session fixation, then hidden fields can happily be attacked
using equivalent client side techniques.
A couple of quick thoughts about issues that affect hidden fields, that
may not affect cookies (at least not to the same degree):
Caching; an application developer has no control of the HTTP agent/s
involved in a transaction, which can happily ignore any cache control
settings (either intentionally or via flaws) and store content either
locally or in communal caches.
304 redirect; it is common to use a redirect after a POST to stop a
browser behaving unexpectedly when using the back button. When using
hidden fields, there isn't an easy way to maintain the session through
the 304 exchange; the result is that either you must use an alternative
or you are left with an application where the back button will resubmit
previous requests.
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).
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.
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?
Regards,
Martin O'Neal
----------------------------------------------------------------------
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@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
--------------------------------------------------------------------------
