views:

177

answers:

2

I am going trough the OWASP Top 10 list of 2007 and 2010.

I stumbled upon Cross Site Request Forgery (CSRF) this is often called session riding as you let the user usee his session to fulfill your wishes.

Now a solution to this is adding a token to every url and this token is checked for every link.

For example to vote on product x the url would be:

'http://mysite.com?token=HVBKJNKL'

This looks like a solid solution to because a hacker can not guess the token.

But I was thinking of the following scenario(I do not know if it is possible):

You create a website with an hidden iFrame or div. After that you can load my website in it either using just the normal iFrame or ajax.

When you have my website loaded hidden inside your website, and the user has a stored session, the following can be done. You can retrieve the token from the URLS, and still do all the actions needed.

Is it possible to do something like this. Or is it not possible to do this cross domain.

A: 

That scenario isn't really possibly because while they could frame to http://mysite.com, they would need the token to make it frame to http://mysite.com?token=HVBKJNKL. And if they have the token then you aren't safe anyways.

Tyler Smith
Ok but they have mysite.com in an iframe in the main website. In the main website they can use jQuery etc to get a link $('#link').attr('href') and subtract the token from it. And append this token to every link wanted in the main website.
Saif Bechan
They can't. Same origin policy will not allow their site to access your html, even if it is within an iframe.
sri
+5  A: 

The attack that you are describing is a clear violation of the Same Origin Policy. , iframe's do not inherit privileges in this way. Many bypasses to the same origin policy have been discovered. The only way these issues get fixed is by people asking questions like this. I urge you to try and write code to bypass the issue, even if it fails. The worst case is you'll learn something important, the best case you'll find an issue, post it to bugtraq, and trow a party :). Oah and everyone will be safer for the bug fix.

XSS can be used to bypass the protection provided by the Same Origin Policy for a specific vulnerable site. An XSS vulnerability can be used to read the XSRF token using XmlHttpRequest. Here is an exploit that wrote that does this.

Rook
Ok I will investigate this a little with some examples using my own website. I will look at the code provided also and report my findings in the next few days.
Saif Bechan
@Saif Bechan Very cool, good luck with your hacks ;)
Rook
@The Rook - just a minor, technical correction. XSS can defeat any XSRF protection, but it does not bypass the same origin policy. Atleast not technically. With XSS, attackers code is running from the same domain, so its not a violation of SOP.
sri
@Saif Bechan Here is standard xsrf exploit where the app doesn't use a token: http://milw0rm.com/exploits/7389here are other exploits written by me, some of them are xsrf:http://milw0rm.com/author/677
Rook
@Sripathi Krishnan you are correct, i have updated my post. But you are are also incorrect, if you use a captcha as XSRF protection then xss cannot be used by bypass it :). (You will also annoy the hell out of users.)
Rook
@The Rook - Agree. XSS cannot bypass a captcha, atleast if its implemented correctly.
sri
@Sripathi Really? Not read up on captcha - presumably you server the image from a different host/domain. Put that still leaves attacks leaning toward the social engineering side of things - do this captcha in a normal captcha situation but something else happens. Seems a number of ways of doing it.
Tom Hawtin - tackline
@Tom Hawtin Javascript cannot be used to "read" characters in an image, even with XmlHttpRequest. You might be able to trick the user into solving the captcha by rewriting the page with javascript.
Rook
@The Rook But it can read the image, can't it? If so, it can post it out to a adversary's server, where it can be solved and the result returned.
Tom Hawtin - tackline
@Tom Hawtin Aaah, it can send it, but it **can't** read the response from a normal server. Firefox 3 allows for cross-site XHR, which could be used (http://ajaxian.com/archives/cross-site-xmlhttprequest-in-firefox-3).
Rook