WebApp Sec mailing list archives
RE: [WEB SECURITY] cookies a fundamental threat?
From: "Martin O'Neal" <martin.oneal () corsaire com>
Date: Tue, 2 May 2006 19:11:15 +0100
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 --------------------------------------------------------------------------
Current thread:
- Re: [WEB SECURITY] cookies a fundamental threat? Achim Hoffmann (May 03)
- <Possible follow-ups>
- RE: [WEB SECURITY] cookies a fundamental threat? Tom Stripling (May 03)
- Re: [WEB SECURITY] cookies a fundamental threat? Achim Hoffmann (May 03)
- RE: [WEB SECURITY] cookies a fundamental threat? Martin O'Neal (May 03)
- Re: [WEB SECURITY] cookies a fundamental threat? Achim Hoffmann (May 03)
- RE: [WEB SECURITY] cookies a fundamental threat? Martin O'Neal (May 03)
- RE: [WEB SECURITY] cookies a fundamental threat? Tom Stripling (May 03)
- RE: [WEB SECURITY] cookies a fundamental threat? Evans, Arian (May 09)
- Re: [WEB SECURITY] cookies a fundamental threat? Brian Eaton (May 10)
- RE: [WEB SECURITY] cookies a fundamental threat? Evans, Arian (May 10)