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] cookies a fundamental threat?

Subject: RE: [WEB SECURITY] cookies a fundamental threat?
Date: Tue, 2 May 2006 10:20:38 -0500
Hi Achim,

-----Original Message-----
From: Achim Hoffmann [mailto:kirke11@securenet.de] 
 
Yes that's true.
But it's still more difficult to access a form field than a 
cookie. Attacking form fields needs to know the DOM. The bar 
is higher for form fields.

Unless I'm missing something, it should be a simple matter to enumerate
all form fields on a page with JavaScript and send all the data offsite.
I don't see why it would require knowledge of the DOM to accomplish
this.  An attacker could just go through every form.elements array and
concatenate the values into a single request.

You're right here, but missing a part.
If the session ID is in the cookie, a session is created on 
the server and the browser holds the session ID after the 
session fixation attack and sends it automatically for (all) 
following requests.
If the session ID is in a hidden form field, a session is 
created on the server and the browser has nothing. To use 
that session you have to inject the session ID again in each 
following request.
Conclusion: with cookies session fixation is -lets say- one 
URL, while with hidden fields you need to do it for each 
request it should apply to.
If the application renews the session ID after creation, both 
methods could considered to be safe.
If the application *does not* renew the session ID after 
creation, the threat are cookies only (see above).

I guess I don't understand your point here.  An application using
form-based session management would need to pass the session ID back and
forth with every request/response just as if the session ID were being
stored in a cookie.  If I execute a form-based session fixation attack,
the fixated session ID will simply get passed back and forth for the
remainder of the session in the same way that a cookie would.  Which
brings us back to Brian's point that session fixation is easier when the
application is using form-based session management because I can execute
the attack from anywhere.

!! - It is easier to steal a domain cookie than to steal a 
hidden form !! field.  To steal a domain cookie, you just 
need a vulnerable server in !! the same domain.  Stealing a 
form field requires a vulnerable page on !! the server 
hosting the form.

Yep.


Regards,
Tom

-------------------------------------------------------------------------
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online 
despite security executives' efforts to prevent malicious attacks. This 
whitepaper identifies the most common methods of attacks that we have seen, 
and outlines a guideline for developing secure web applications. 
Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------


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