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

Laurent Desaulniers laurent.desaulniers at gmail.com
Thu Nov 27 22:51:28 EST 2008


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-montreal/attachments/20081127/2cea7bca/attachment.html 


More information about the Owasp-montreal mailing list