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.




Network Security Web-App-Sec
[Top] [All Lists]

Re: [WEB SECURITY] Fundamental error in Corsaire's paper?

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

<Prev in Thread] Current Thread [Next in Thread>