WebApp Sec mailing list archives
RE: [WEB SECURITY] Fundamental error in Corsaire's paper?
From: "Amit Klein (AKsecurity)" <aksecurity () hotpop com>
Date: Thu, 27 Apr 2006 20:04:14 +0200
Hi Martin,
The concluding paragraph states, "There is no such thing as path security. Two entities that share the same host cannot be defended from each other".
A simple counter example that shows this to be incorrect would be a browser with all the mobile code support disabled and 'bar' with a correctly specified path. This would be, as far as I can see, immune to all the example attacks from 'foo' contained in the paper.
1. When you say "all the mobile code support disabled" - does this cover Javascript? if so, I find it not so realistic, as the vast majority of present day apps/sites require Javascript to properly work. 2. Anyway, even with Javascript turned off, it's still possible to execute many attacks, even when the cookie path is limited to bar. Consider the following HTML snippet embedded in a foo page (I turned less-than and greater-than symbols to their square bracket counterparts to avoid filtering problems): [img src="/bar/%2e%2e/foo/collect.cgi"] [img src="/bar/baz\..\../foo/collect.cgi"] [img src="/bar/%u002e%u002e/foo/collect.cgi"] [img src="/bar/%c0%ae%c0%ae/foo/collect.cgi"] [img src="/bar/%252e%252e/foo/collect.cgi"] All the above techniques are discussed in my paper. Actually, the first one was discovered by you.
However, even so, the situation described in the paper is at best unlikely; if 'foo' and 'bar' share the same host, are hostile to one another, and 'foo' can upload arbitrary server side code, then attacks against the session are probably the least of your worries. Server side attacks are not covered in your paper, and are probably the easiest mechanism of delivery in this scenario.
I think there are setups where users (in different paths) are protected from one another. The classic example would be the Unix O/S (up to implementation problems...). So for example, http://www.the.site/~foo/ may cause stuff to run at the server, but they can only touch /home/foo/, never /home/bar/, and so http://www.the.site/~bar/ is unaffected. Besides, the foo application may not be hostile, but may suffer from XSS (pretty common, I'd say...) which makes it a jumping stone into bar.
Even so, staying with session attacks, if 'bar' doesn't correctly specify a path, then there is no requirement for any form of client side attack at all; 'foo' just harvests the cookies as presented by the browser.
Right. 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.
In the more likely implementation scenario, where all the apps on a domain do belong to the same owner (and hence are not hostile to one another), then the path provides a mechanism whereby the cookie footprint can be kept constrained. For a third-party to successfully attack the session requires a flaw in one of the applications as the delivery mechanism. Like I said, a correctly specified path isn't any form of universal solution. Conversely, I could be wrong, but I'm sure that you wouldn't recommend not specifying the path at all?
I recommend simply not to rely on separation by path as any form of security what-so-ever. 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. THat is, to enable you to run two applications simulteaneously - one in /foo, the other in /bar, possibly from two different vendors, and have each app assign you a cookie named SessionID, without collision. 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? -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? 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)
- RE: [WEB SECURITY] Fundamental error in Corsaire's paper? Martin O'Neal (Apr 28)