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