Orlin
Maybe I am missing something on this email thread...I would think that if
the session token is changed after and before the HTTP POST of the new
transaction will prevent CSRF to happen. The point is to make sure that such
transaction does not exploit the implicit trust that the application has on
the user browser once the authentication session is initiated, or no?
More info on CSRF is here http://www.owasp.org/index.php/Testing_for_CSRF
and here is the countermeasure http://www.owasp.org/index.php/CSRF_Guard
My 2c
Marco Morana
OWASP Cincinnati Chapter Leader
http://www.owasp.org/index.php/Cincinnati
Join us at http://www.owasp.org/index.php/AppSecEU08
-----Original Message-----
From: listbounce_at_securityfocus.com [mailto:listbounce_at_securityfocus.com] On
Behalf Of Orlin Gueorguiev
Sent: Friday, May 02, 2008 8:25 PM
To: security-basics_at_securityfocus.com
Subject: Re: Cookie Security
ξΑ Wednesday 30 April 2008 17:24:19 Audrius ΞΑΠΙΣΑ:
> 2008/4/30 Orlin Gueorguiev <orlin_at_baturov.com>:
> > <img
> >
> >
src="http://bank.example/withdraw?account=bob&amount=1000000&for=mallory"
> >>
> >
> > If Bob's bank keeps his authentication information in a cookie, and if
> > the cookie hasn't expired, then Bob's browser's attempt to load the
image
> > will submit the withdrawal form with his cookie, thus authorizing a
> > transaction without Bob's approval.
> > =====
> > So... what I am asking myself how your consept can secure, that CSRF is
> > not going to be exploited?
>
> You already have answered your question using your "if's". Token can't
> be in the cookies, because they are returned back on every request.
> But if token will be used for example in an URL, then your method will
> not work. But again, this technique will not work, if site will be
> vulnerable to XSS. Most of security methods against CSRF doesn't work,
> if site has XSS vulnerability. Then much better way is to use
> something like captcha. Just ask user to do something before doing
> important actions. But again, captcha can't be to complicated, because
> you will have another problem. Usability of the website. :) Better
> security always means less usability and to find the middle is quite
> hard.
Lets take the classical situation: We have 3 persons: Alice (the attacked
person), Bob (the bank) and Eve (the hacker).
So... Eve crafts a web page, that tries to exploit a CSRF vulnerability and
steal money from anybody, who opens the page and has a non-expired cookie to
Bob (the bank). So Alice opens the page and she logs with her own computer
and credentials to the bank and send the money. Now... because SHE logs
there, and not Eve, this means that anything saved on her computer can be
used to log in there, so exchanging tokens would not work.
Even if you use a token, that is beeing randomly generated, if the process
of
generation is simulated using CSRF, it would not really matter if you use
such a token. So... this is why I was asking why you how/why does this token
help prevent CSRF?
Cheers,
Orlin
Received on May 06 2008
Intro
