> -----Original Message-----
> From: Achim Hoffmann [mailto:kirke11_at_securenet.de]
> !!
> !! 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.
>
> Not that bad: a form can be placed anywhere, true, but ...
> Lets explain with an example:
> Assuming a simple login page with username, password and a
> hidden session ID.
> Also assuming that the application is vulnerable to session
> fixation.
>
> First the attacker copies the original login page, adds the
> original URL to
> the form's action attribute, fills in a session ID in the
> hidden field,
> and places this trap-page somewhere (not on the domain to
> be attacked).
>
> Now the victim has to be engaged to visit that trap. No
> Problem, you can
> send a link to be clicked, you can post the link in a forum
> somewhere,
> you even may misuse a search engine. And a sophiticated
> attack even can
> perform that the victim doesn't need tpo click but is redirected
> immediately to the trap.
>
> And here the difference starts.
> The victim has to fill in username and password to activate
> the form and
> hence to perform the session fixation. Damn, bad situation
> for an attacker.
>
> Silly Question: would you login in such a page with the wrong
> URL in your address bar?
> Well, you may argue that such a page could be placed using
> XSS or better website spoofing, but then we're back on the
> domain to be attacked. In that case I don't see a big
> difference to phishing, which is much more effective 'cause
> the attacker gets the full login credentials then.
> I don't see a reason why someone would login into a foreign
> page, but correct me if I miss a suitable working example here.
Here's the situation I was thinking of. Tell me if you think this
constitutes a counter example.
An application has a login form and accepts a hidden field containing
the session id. The application is vulnerable to session fixation, so
that if I enter a username and password into the form, the application
will accept the value that is stored in the hidden session id field and
use that for my session from that point on.
Up to this point, I don't think I've changed anything from your
scenario. You were saying that the attacker would need to duplicate the
login form to execute the attack.
But what if I formulate a link with the session id parameter only (i.e.
http://exmaple.com/login.aspx?sid=12345) and send that to you in the
manner you described above? If the application is vulnerable to session
fixation, it seems likely that it would simply take this session id,
store it in the hidden field, and present the user with the login form.
At this point, the victim is logging into the correct url and sees
nothing overly suspicious. And the attacker has dictated the session id
that the victim will use in the same way as the cookie example. In my
experience, this attack is extremely common in applications that use
form field session management and are vulnerable to session fixation.
Even though cookies will be sent with every request to that domain by
the browser, an application that uses another method to communicate the
session id still has to duplicate that behavior by storing the session
id on the client (in some form) on every page.
In this scenario, I don't see a real-world difference between the
ability to execute a form-based session fixation attack and cookie-based
attack except for the fact that the form-based attack can be executed
from anywhere, as we've agreed.
>
> On the other side have a look how an attacker does it with cookies:
> Assumptions as above.
>
> Attacker crafts URL with cookie injection code, delivers
> the URL the same
> way as above.
How does one craft a URL with cookie injection code? Are you talking
about ASP.NET cookieless sessions and the like? Could you provide an
example of this?
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
--------------------------------------------------------------------------
Received on May 03 2006
Intro
