[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] cookies a fundamental threat?
- From: Achim Hoffmann <kirke11@xxxxxxxxxxxx>
- Subject: Re: [WEB SECURITY] cookies a fundamental threat?
- Date: Thu, 4 May 2006 00:11:22 +0200 (MEST)
On Wed, 3 May 2006, Tom Stripling wrote:
!! 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.
Right so far.
But do you see that this is now the link to the domain to be attacked,
and not anywhere else? Didn't you say that it works anywhere?
!! 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.
If someone clicks on a link to the right site, all methods (cookie, form
field, URL rewriting, basic auth) behave the same way. It's up to the
user to trust that URL. There is nothing to complain about.
As this is the same threat for all, we can silently ignore it (here).
!! In my experience, this attack is extremely common ..
for sure: it's the same way as phishing works.
!! 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.
Yes the URL can be placed anywhere, but that link is useless for session
fixation as long as the other credentials are not given with that link.
While with cookies that link injects the cookie and the final fixation of the
session can take place somewhere else, completely independent.
For form fields, the session fixation works only with the provided URL,
any other URL at another time/place is useless.
Or in other words: with form fields the user needs to do something (giving
credentials) after clicking the provided link. With cookies the user just
needs to click the link, switch off the computer and log in after power on
again, then the session is fixed.
(in both cases the click might also be automated, which doesn't make a
difference to fulfil the attack).
!! How does one craft a URL with cookie injection code?
something like:
http:/victim.tld/fixme?mea=culpa"><script>document.cookie="for=ever;path=/"<script>
(to be improved in many ways)
{-: Achim
- Sponsored Advertisement --------------------------------------------------
The Software Security Summit is the only event that addresses security
issues at the application development level. Join us Jun 5-7, Baltimore, MD.
http://www.s-3con.com
----------------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/
The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/
Brought to you by http://www.webappsec.org
Search this site
|