From: Amit Klein (AKsecurity) (aksecurityhotpop.com)
Date: Thu Apr 27 2006 - 13:04:14 CDT

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

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

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