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). Having said that, it is still a valid
scenario, that happily stands contrary to the paper's conclusion.
...
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.
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.
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.
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
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).
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.
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.
Martin...
----------------------------------------------------------------------
CONFIDENTIALITY: This e-mail and any files transmitted with it are
confidential and intended solely for the use of the recipient(s) only.
Any review, retransmission, dissemination or other use of, or taking
any action in reliance upon this information by persons or entities
other than the intended recipient(s) is prohibited. If you have
received this e-mail in error please notify the sender immediately
and destroy the material whether stored on a computer or otherwise.
----------------------------------------------------------------------
DISCLAIMER: Any views or opinions presented within this e-mail are
solely those of the author and do not necessarily represent those
of Corsaire Limited, unless otherwise specifically stated.
----------------------------------------------------------------------
Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF
Telephone: +44(0)1483-226000 Email:info@corsaire.com
-------------------------------------------------------------------------
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
--------------------------------------------------------------------------
