WebApp Sec mailing list archives
RE: [WEB SECURITY] Fundamental error in Corsaire's paper?
From: "Martin O'Neal" <martin.oneal () corsaire com>
Date: Thu, 27 Apr 2006 21:21:07 +0100
Hiya chap,
does this cover Javascript?
Yes, all mobile code. However I agree, for general browsing this isn't all that practical (although I have seen some sites that blanket disable java, javascript and activex). Having said that, it is still a valid scenario, that happily stands contrary to the paper's conclusion.
... All the above techniques are discussed in my paper.
But these are simply browser flaws, which will presumably get fixed once the temperature in hell drops far enough to inspire the vendors.
Actually, the first one was discovered by you.
Actually the advisory was for the generic issue; I had identified that all that was required was a sequence that the browser would not make canonical before dispatching it to the server, but that the server would make canonical. The test set I used at the time used all of the standard encoding sequences, slash replacement etc., but the advisory only contained the %2e example for brevity.
Besides, the foo application may not be hostile, but may suffer from XSS
Which supports my case that in a practical scenario, what is required is a secondary flaw to deliver an attack.
But the whole point of my paper was to prove that even when bar DOES specify the path for its cookies, it's still pretty useless.
Granted; given the various browser issues etc. it has limited utility, but I wouldn't recommend not setting it and nor, it would appear, would you. :p
My thinking is (I don't know how to verify or refute this) that the path element in the Set-Cookie was put there in order to enable cookie separation from an administrative/functionality point of view, rather than as a security measure.
When I originally found the cookie issues I tried several times to contact the original RFC2965 authors to clarify their intentions, but without luck. RFC2965 does in fact cover path usage in the Security section of the document (7.1 Protocol Design), but it is a touch vague (in the true RFC tradition). However, I don't think the crux of the issue is cookies in general, or the path argument in particular. I think it is the implementation model of the mobile code; the separation model that is enforced at the HTTP level (browser flaws accepted) isn't carried through to the mobile code. Whether this is by design, or by accident, I am not sure.
To turn the question back to you: GIVEN all the attacks discussed above and in my paper, in which realistic scenario do you perceive that setting the path makes the cookies more secure than not setting it?
I think that setting the path makes attacking the cookies more difficult, and would always recommend it. On its own it doesn't give you any guaranteed security as an absolute, but then you can objectively say the same thing about SSL and all of the other individual technologies employed within an application deployment. They are separate parts of the puzzle, but only come into their own in a fully rounded implementation. 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 () corsaire com ------------------------------------------------------------------------- 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 --------------------------------------------------------------------------
Current thread:
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Amit Klein (AKsecurity) (Apr 26)
- <Possible follow-ups>
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Martin O'Neal (Apr 27)
- Re: [WEB SECURITY] Fundamental error in Corsaire's paper? Dan Kuykendall (Apr 27)
- WebScarab Fuzzer Jason Murray (Jun 09)
- Re: WebScarab Fuzzer Vlad (Jun 11)
- Re: WebScarab Fuzzer Rogan Dawes (Jun 11)
- WebScarab Fuzzer Jason Murray (Jun 09)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Martin O'Neal (Apr 27)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Amit Klein (AKsecurity) (Apr 27)
- Re: [WEB SECURITY] Fundamental error in Corsaire's paper? Dan Kuykendall (Apr 27)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Martin O'Neal (Apr 27)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Martin O'Neal (Apr 28)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Amit Klein (AKsecurity) (Apr 28)
- Re: [WEB SECURITY] Fundamental error in Corsaire's paper? Brian Eaton (Apr 28)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Amit Klein (AKsecurity) (Apr 28)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Armag (Apr 28)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Amit Klein (AKsecurity) (Apr 28)
- Re: [WEB SECURITY] Fundamental error in Corsaire's paper? Achim Hoffmann (Apr 30)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Armag (Apr 28)