Re: [WEB SECURITY] cookies a fundamental threat?

[Achim Hoffmann <kirke11 () securenet de>]

On Tue, 2 May 2006, Tom Stripling wrote:

!! > From: Achim Hoffmann [mailto:kirke11 () securenet de]
!!
!! > 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.

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.

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.

  When this URL gets called, the cookie will be set, doesn't matter if
  the user provides credentials or not. This enables the attacker to
  automatically send the URL even with wrong credentials.
  Now the session is not yet fixed, 'cause the credentials are still missing,
  but the cookie is alive in the victims browser. When the victim then logs
  in later, the session is fixed. Bingo!

Silly question here also: do you get warned about the new cookie?
I guess no for the majority of cases (that's excatly why cookies are so
comfortable to use). If you have not been warned, and you did not give the
login credentials on that side, do you expect that something went wrong?


Conclusion: with cookies it's simple to inject something unintended, just
one malicious URL for a vulnerable domain is sufficient.
With other methods that's not as simple, at least the user has a chance to
identify the scam. I'd say that such a scam is under control of the victim.


This example was for hidden fields, we could play with URL rewriting and
basic/digest auth too. But just cookies suffer from this problem.

The vulnerability is in the application, but the threat which makes it to
become a risk are cookies. That's what the subject is about.


Regards,
{-: Achim


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