From: Amit Klein (AKsecurity) (aksecurityhotpop.com)
Date: Fri Apr 28 2006 - 11:10:46 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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 XSS
>
> Which 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
--------------------------------------------------------------------------

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]