RE: [WEB SECURITY] Fundamental error in Corsaire's paper?

["Amit Klein (AKsecurity)" <aksecurity () hotpop com>]

Hi Martin,

1. Mea culpa
While I'm jumping in into this thread, it may be
appropriate to express my regrets to the author of the
original Corsaire paper - Martin O'Neal. In my own
paper, "Path Insecurity", I erred by omitting proper
references to two of Martin's works:

- The "Cookie Path Best Practice" paper of April 5th,
2004, which is the subject of this thread. I should
have mentioned this paper, as it is the relevant to the topic
at hand. I did mention one earlier (than my paper)
work on the subject - Ivan Ristic's book, yet I should
have mentioned Martin's paper at that point. Now, that
doesn't mean I agree to the paper's recommendation;
contrariwise (see below). In fact, you may say that
one of the main points of my paper is that using the path
field to secure cookies against attacks from the same
host/domain is hopeless.

- The "Multiple vendor HTTP user agent cookie path
traversal issue" advisory
(http://www.corsaire.com/advisories/c030712-001.txt.
In this case, the advisory discusses one of the
techniques I depicted in my paper - the "%2e%2e"
trick. This advisory was published in FullDisclosure
and in VulnWatch (and probably in few other lists but,
alas, not in BugTraq?) on March 10th, 2004. 
Note that my %2e%2e "finding" for IE 6.0 of early 2006 was
assigned a CVE number CAN-2003-0513 on July 2003.
I suppose Microsoft didn't find time to fix this in over 2.5
years. 
So, to clarify: while I did think of the %2e%2e all by
myself, it was apparently known to the public (courtesy of
Martin O'Neal from Corsaire) for over 2 years. 
And that's what matters.

2. And now to the point
Referring to your statement "this is all a moot point
if browsers still suffer from same
origin client issues (as highlighted by Amit's paper
and elsewhere)."
I'd like to point out that a technique I discussed
in the first section of my paper is obtaining a handle
to a window whose path is in the "secure" application,
and then obtaining the cookie through the handle to
the window. To quote my paper:

        Now, again an obvious attack is to read the cookies
        from H.document.cookie. If no such handle can be obtained,
        then it's still possible for
        http://www.some.site/foo/attack1.html to open 
        a window to some page in /bar/, e.g. 
        http://www.some.site/bar/page2.html, and now that a
        handle exists, to use it to read the cookies in /bar/ folder.
        If it is totally impossible to open a window, then perhaps the
        "voluntary" HTTP Response Splitting method described in [2] (p.
        26) can be used.

That is, the following two lines of code, executed in a page
http://www.some.site/foo/attack.html, will grant the Foo application
the cookies of Bar:

        H=window.open("http://www.some.site/bar/page1.html";;
        alert(H.document.cookie);

This is not a "same origin client issue" really, at
least not the way I understand it. This is a 100%
valid JS code - it's not "an exploit". Perhaps it is a
design flaw, but it's not a JS implementation flaw.
In other words, I don't expect a "fix" to this problem
(which is why I think there's a major problem with
path security to begin with).
 
-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
--------------------------------------------------------------------------