Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [WEB SECURITY] Fundamental error in Corsaire's paper? |
|---|---|
| Date: | Sat, 29 Apr 2006 21:09:17 +0200 (MEST) |
On Fri, 28 Apr 2006, Amit Klein (AKsecurity) wrote:
!! On 28 Apr 2006 at 11:58, Armag wrote:
!!
!! >
!! > What is the final verdict, the original topic of this thread?
!! > The Corsaire article - is there a fundamental error in the
!! > recommendation part of it?
!!
!! Well, if you ask me, then yes, there is a problem in the Corsaire paper,
!! since it doesn't mention that in almost all of the cases, the cookie
!! path is useless for improving security. The only case wherein this
recommendation actually
!! adds
!! security is the very rare situation of a JS-turned-off (indeed...) non-MSIE
browser
!! going to a non-IIS (or more likely non-Windows) website, and even that
!! is not guaranteed (who knows what other tricks work for the various servers
out there). So
!! up to this negligible situation, I hold to my original claim - "There is no
such thing as
!! path security".
agree with Amit here, path in cookies are unreliable, at least for the
application.
Please see also my inquiry here Subject: sequence of cookies in a request
I got only 2 responses, and they pointed me back to the RFCs. Sigh.
If we don't blame the browser vendors, call on to fix the flaws, and we also
do not blame application programers to avoid insecure cookies for their
session handling, where's the culprit then? Ahh, I see, it's the user again
accessing the wrong application with the wrong browser at the wrong time ...
Well, my post is a bit off-topic to the initial subject, but the question
and my other question "sequence of cookies in a request" show again that
cookies are a fundametal threat in todays web applications.
I claim too "There is no path security".
(cookie2 with encrypted values are a different story, however ...)
!! -Amit
!!
!! PS - which isn't to say I'm against using cookie path. Go ahead, use it - it
will probably
!! save you from cookie namespace collisions. But don't think you buy any
security this way
!! (well, up to the aforementioned bizarre scenario, that is...)
{-: Achim
-------------------------------------------------------------------------
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
--------------------------------------------------------------------------
| Previous by Date: | RE: Poll: Emerging Threats, H Alsaleh |
|---|---|
| Next by Date: | cookies a fundamental threat?, Brian Eaton |
| Previous by Thread: | RE: [WEB SECURITY] Fundamental error in Corsaire's paper?, Amit Klein (AKsecurity) |
| Next by Thread: | RE: [WEB SECURITY] Fundamental error in Corsaire's paper?, Martin O'Neal |
| Indexes: | [Date] [Thread] [Top] [All Lists] |