WebApp Sec mailing list archives
RE: [WEB SECURITY] Fundamental error in Corsaire's paper?
From: "Amit Klein (AKsecurity)" <aksecurity () hotpop com>
Date: Fri, 28 Apr 2006 18:10:46 +0200
On 27 Apr 2006 at 21:21, Martin O'Neal wrote:
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).
Uh, perhaps I'm not educated in the matter, but how does a site turn off Javascript support in the browser? that's typically something a user would do. And the vast majority of users have their Javascript enabled (which is the default, of course), because the vast majority of sites require JS in order to function. Having said that, it is still a valid
scenario, that happily stands contrary to the paper's conclusion.
OK, let's play it your way. In order for a site to benefit from specifying the path (I mean - in order for this to make a difference), the following should hold: 1. Most site's users turn off JS (and other client side scripting) off. 2. Those users do not use MSIE (MSIE has the %2e%2e bug/feature, which apparently isn't going to be fixed in the near future. Maybe IE 7?). 3. The site doesn't run IIS (there are too many ways to bypass the path with IIS, e.g. %uHHHH and backslash), ideally not running Windows at all (due to the backslash issue). Hmmmm... - not too common, so it seems.
... 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.
Oh, I disagree here. In my opinion, these are NOT browser issues (save perhaps the %2e trick?). The cookie RFCs (2109 and 2965) specify that the path restriction should be imposed as prefix match. This is somewhat vague, but if we turn to the HTTP 1.1 RFC (2616) for support (after all cookies are handled in an HTTP agent), we have in section 3.2.3 ("URI Comparison"): When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs [...] Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. Note that according to RFC 2396, dot is unreserved, so strictly speaking, it is not equivalent to %2e... (this is ridiculous, of course, but it still is a direct consequence of the above definitions). As for %252e, it is equivalent to the string %2e. Likewise %5c is equivalent to \, and so forth. So: /foo/%252e%252e/bar/collect.cgi is decoded (for comparison) by the browser to /foo/%2e%2e/bar/collect.cgi, but it is not equivalent to /foo/../bar/collect.cgi. Likewise /foo/baz%5c..%5c../bar/collect.cgi is decoded (for comparison) by the browser into /foo/baz\..\../bar/collect.cgi by the browser, but this isn't equivalent (when browser!=MSIE) to /foo/baz/../../bar/collect.cgi. The browser's equivalence model is simple, as it should be. We mustn't (I believe) expect the browser to predict each and every quirk of the server (double encoding, UTF-8 interpretation, backslash interpretation, etc.). If anything, this is a server problem.
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.
Makes sense, knowing your skills. Pity you didn't list those in your paper/advisory.
Besides, the foo application may not be hostile, but may suffer from XSSWhich supports my case that in a practical scenario, what is required is a secondary flaw to deliver an attack.
Agreed. Yet XSS is found in abundance. So placing two apps, one sensitive (and secure) the other not-so-sensitive (and XSS riddled) on the same host grants you the precondition. The point is, XSS can be found in (let me risk a guess here) MOST applications, so when placing two applications, one a sensitive (and possibly well audited) and the other "just an app", XSS in the second app is likely.
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
I wouldn't recommend anything ;-) As I stated above, the scenario in which a site really benefits from it is (in my mind) very rare. And as such, I'd direct the developer to more effective avenues to invest her time and effort.
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).
Agreed.
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.
Agreed.
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.
It doesn't hurt to set the cookie path. I'm still not convinced that it grants any real security benefit (in the vast majority of cases), as it seems to me that the techniques we discussed in this thread can be used easily to bypass this mechanism. As for SSL, I strongly disagree. SSL performs a well defined function of protecting data at transit (from eavesdropping, data modification, replay, insertion/deletion, etc.). It does so very well, I believe. Naturally, if you hack into the app database, then all the traffic encryption in the world won't help you, but as to the role SSL is supposed to fulfill - it does so well. -Amit ------------------------------------------------------------------------- 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?, (continued)
- 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)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Martin O'Neal (Apr 28)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Martin O'Neal (Apr 29)