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

Fortier, Hugo hugo at securitycompass.com
Thu Nov 27 23:11:15 EST 2008

XSRF are everywhere, It doesn't mater if it's a GET or a POST. Any site can create post to any site using Javascript. Anytime that a request can be sent without needing a "secret" to perform a action on web it can be vulnerable to cross site request forgery. 

Session Management on most website rely uniquely on Session Cookie or Basic Auth. Some way to protect from XSRF is to verify a token that would be session or request related that would be sent across a post or a get request (it's better to send it in the post as get parameter are sometime leaker to third party site if they load or redirect to third party website).

I seen website that wouldn't require to enter back your password before changing it once your authenticated, with XSRF you can often force them to change their password. This is why it's a good practice to require a new authentication before any critical request, by example before allowing a money transfer, you might want to request the user to type in their password again or you might issue a unique token that would be embedded in the submit form.

The hard part of exploitation is to have the user connecting to your "malicious" website while they are on the website your targeting with your XSRF attack. It can be done effectively by clever social engineering or phishing attack, or if you are doing a MITM attack. I like the MITM attack approach to demonstrate those attack, if you can see the traffic of your victim even if it's SSL you know on witch site they are, and can hijack a secondary http connection that is in clear text to perform XSRF attack on the SSL site.

A other thing that you can attempt to exploit with XSRF are services binded on the localhost interface (or other service that might be in their LAN that isn't accessible from internet) of your victim, they often don't require authentication or your browser might send the credential automatically. By example IIS administration console used to be vulnerable to that if your where logged as Admin, not sure if that got fixed or not. 

In general if the website doesn't have a mechanism to protect against XSRF, they are vulnerable.


-----Original Message-----
From: owasp-montreal-bounces at lists.owasp.org on behalf of Laurent Desaulniers
Sent: Thu 11/27/2008 9:51 PM
To: Benoit Guerette
Cc: owasp-montreal at lists.owasp.org
Subject: Re: [ OWASP - Montréal ]XSFR/CSFR testing difficulty level
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


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
	What did I miss? :) Thanks!
	Owasp-montreal mailing list
	Owasp-montreal at lists.owasp.org

*CONFIDENTIALIT* L'information apparaissant dans ce message lectronique est de nature lgalement privilgie et confidentielle. Si ce message vous est parvenu par erreur et que vous n'tes pas le destinataire vis, vous tes par les prsentes avis que tout usage, copie ou distribution de ce message est strictement interdit. Vous tes donc pri de nous informer immdiatement de cette erreur et de dtruire 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/4c374d7b/attachment.html 

More information about the Owasp-montreal mailing list