[ OWASP - Montréal ]XSFR/CSFR testing difficulty level

Benoit Guerette benoit.guerette at gmail.com
Thu Nov 27 22:56:47 EST 2008

Very helpful!

I was focusing on threats involving financial lost, but your are
right, there is more simple issues. I will review my procedure with
that information (password change, login/logout, so basic and common
web apps functionnalities)

Once again thanks a lot!!!

On Thu, Nov 27, 2008 at 10:51 PM, Laurent Desaulniers
<laurent.desaulniers at gmail.com> wrote:
> Some XSRF are very easy to find. Most "logout" feature are vulnerable to
> xsrf. A good way to find XSRF is to try to reproduce the usual requests with
> netcat. Once you get a "feel" how the application works and what parameters
> are needed, you can test it easily. Simply create a local html file and
> embed your request in img tag. Then, load your page and voila.
> But i have to agree with you. Most XSRF are difficult to exploit. A good way
> to test the "xsrf potential", try to send POST requests as GET. For example,
> if your POST is
> POST /?password=mypassword&user=toto then you may want to try GET
> password=mypassword&user=toto
> Some programmer (usually the slightly less experienced) forward the post to
> a get. Of course, this is a great XSRF potential. (Imagine an image called
> setpassword=mypasswordicanuse&setemail=myevilhackeremail&confirm=1
> Lot of fun possible. Webscarab has a "potential XSRF" tool. It does not work
> too well but it is worth a try.
> I hope it helps
> Laurent
> On Thu, Nov 27, 2008 at 10:34 PM, Benoit Guerette
> <benoit.guerette at gmail.com> wrote:
>> I don't know which term to use but I mean Cross Site Request Forgery
>> (both seems ok).
>> How do you test XSRF vulnerabilities? From what I can understand,
>> finding a successful XSRF vulnerabilty need a lot of understanding of
>> the web application, and lot of time. I don't thing lots of clients
>> allow huge buffers $ for that kind of test, but it is so important.
>> Forging a request with the right parameters values for success is very
>> hard, and result are not always easy to see. Example: XSRF
>> vulnerability of a bank web apps, allowing you to transfer money to
>> your 'attacker' account. When you test, you cannot transfer money to
>> your own account, so you need a friend at the same bank, leaving is
>> session open and surfing to your 'blog' containing the the forged
>> request hidden in the image html tags.
>> My conclusion: XSRF vulnerability is easier and faster to find by
>> talking to the dev team, asking them specific question (do you use a
>> token associated with the session to avoid XSFR) to find the
>> vulnerability?
>> What did I miss? :) Thanks!
>> --
>> http://www.linkedin.com/in/benoitguerette
>> _______________________________________________
>> Owasp-montreal mailing list
>> Owasp-montreal at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-montreal
> --
> *CONFIDENTIALITÉ* L'information apparaissant dans ce message électronique
> est de nature légalement privilégiée et confidentielle. Si ce message vous
> est parvenu par erreur et que vous n'êtes pas le destinataire visé, vous
> êtes par les présentes avisé que tout usage, copie ou distribution de ce
> message est strictement interdit. Vous êtes donc prié de nous informer
> immédiatement de cette erreur et de détruire ce message.
> *CONFIDENTIALITY* The information in this message is legally privileged and
> confidential. In the event of a transmission error and if you are not the
> individual or entity mentioned above, you are hereby advised that any use,
> copying or reproduction of this document is strictly forbidden. Please
> advise us of this error and destroy this message.


More information about the Owasp-montreal mailing list