IFrame security threats and the prevention

Security Feb 21, 2022

IFrames have been around for a long time in web development, and are still widely used today. However, its use has several security risks that can open the doors for attackers.

If you search on the internet, there are many posts and information similar to this article. But this article will explain it more comprehensively and in simple words to make it easier for you to understand iFrame security. In this article, I will describe scenarios of using iFrame, the threats, and the solutions to minimize the chance for attackers.


Before going through the detailed scenarios, let’s refresh to these techniques that will be used to prevent iFrame from security threats:

  1. X-Frame-Options: HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>.  Checkout to this X-Frame-Options docs for better understanding.
  2. CSP frame-ancestors: specifies valid parents that may embed a page using <frame>, <iframe>, <object>, <embed>, or <applet>. Checkout to this CSP: frame-ancestors docs for better understanding.
  3. CSP frame-src: specifies valid sources for nested browsing contexts loading using elements such as <frame> and <iframe>. Checkout to this CSP: frame-src docs for better understanding.
  4. IFrame sandbox attribute: Applies extra restrictions to the content in the frame. It applies restrictions to a page's actions including preventing popups, preventing the execution of plugins and scripts, and enforcing a same-origin policy. Checkout to this Iframe sandbox attribute docs for better understanding.
  5. CSP sandbox: another option similar to iFrame sandbox attribute, but this will be applied to all iFrames in a site. Checkout to this CSP: sandbox docs for better understanding.

I assume that you now know the techniques to prevent iFrame from security risks. Let’s continue to break down iFrame security cases for each scenario.

Scenario 1: Other site loads your site in iFrame

This attack is usually only successful when combined with social engineering. An example would consist of an attacker convincing the user to navigate to a web page the attacker controls.

Cross-frame scripting

Image 1. Cross-frame scripting illustration

Cross-Frame Scripting (XFS) is an attack that combines malicious JavaScript with an iFrame that loads a legitimate page in an effort to steal data from an unsuspecting user. Read more: Cross Frame Scripting on OWASP

The attacker’s page loads malicious JavaScript and an HTML iFrame pointing to a legitimate site. Once the user enters credentials into the legitimate site within the iFrame, the malicious JavaScript steals the keystrokes.

Prevention method:

Include proper Content-Security-Policy: frame-ancestors configurations. You can also use X-Frame-Options for older browser compatibility. These setups will make your site not allowed to be rendered by other sites other than included in the configurations.

IFrame phishing

Image 2. Cross-frame scripting illustration

IFrame phishing is an attack that combines iFrame that loads a legitimate page and iFrame that loads site from the attacker in an effort to steal data from an unsuspecting user

As seen in Image 2, there is a phishing site embedded using an iFrame. The user will be redirected there, and if the user is not attentive to the address bar, the attacker will easily obtain the user’s credentials.

Prevention method:

Include proper Content-Security-Policy: frame-ancestors configurations. You can also use X-Frame-Options for older browser compatibility. These setups will make your site not allowed to be rendered by other sites other than included in the configurations.

Scenario 2: Your site loads other sites in iFrame

IFrame injection

IFrame injection usually comes from 3rd-party javascript libraries, plugins, or user-generated content. This attack is a very common cross-site scripting attack.

This attack basically injects a malicious iFrame into our site. How they can inject an iFrame? Let me breakdown the possible causes below:

  1. Our site uses 3rd-party JS library that contain malicious scripts to inject an iFrame
  2. Our site uses plugins that contain malicious script to inject an iFrame
  3. The iFrame comes from user-generated content. This case comes along with XSS attack that injects an iFrame into our site.

Prevention method:

  1. Include proper Content-Security-Policy: frame-src configurations. This setup will make your site not allowed to render other sites other than included in the configurations.
  2. Include proper Content-Security-Policy: sandbox configurations. This setup will restrict iFrames loaded in your site to do page actions other than included in the configurations.

Prevention to this attack is not just limited to the iFrame. Instead, we should also fix the root cause and implement other security aspects. We should be careful to include 3rd-party JS libraries and plugins that are used in our site. Apart from that, we should also handle XSS attacks on our site.

Clickjacking

Clickjacking is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top-level page. Read more: Clickjacking on OWASP

Let say, your site load this iFrame:

<iframe src=’https://www.attackers.com’ style=’visibility: hidden;’></iframe>

But the iFrame use transparent layers on top of link or button in your site. Then inside attacker site https://www.attackers.com, there is script to be executed when user click on link/button in your site. This is the example code snippet of the script:

<script>
  function onClickLink() {
    // will redirect your site
    window.top.location = 'https://fake-yoursite.com';
  }
  
  //or
  function onClickButton() {
    // will open site in new tab
    window.open("https://fake-yoursite.com");
  }
</script

After the user clicked the link/button, the site will be redirected to the attacker site (which is fake your site). Then if the user doesn’t aware the link in the URL bar, the attacker can steal user data such as credentials, user email, password, and other sensitive information. This is one of the dangerous attacks that should be handled by developers.

Prevention method:

  1. Include proper Content-Security-Policy: frame-src configurations. This setup will make your site not allowed to render other sites other than included in the configurations.
  2. Include proper Content-Security-Policy: frame-ancestors configurations. You can also use X-Frame-Options for older browser compatibility. These setups will make your site not allowed to be rendered by other sites other than included in the configurations.
  3. Include sandbox attribute with proper configurations in an iFrame, such as removing allow-top-navigation, allow-top-navigation-by-user-activation, allow-popups, or allow-popups-to-escape-sandbox.  You can also use Content-Security-Policy: sandbox to be applied for all iFrame in your site. This setup will restrict iFrames loaded in your site to do page actions other than those included in the configurations.

Dialog box threat

Image 3. Dialog box threat illustration

Dialog box threat will make the annoy the users to interact with our site

Let say your site load an iFrame that contain this script:

<script>
  (function boomDialog() {
    if (window.confirm("Do you want $1000?")) {
      boomDialog();
    } else {
      boomDialog();
    }
  })();
</script>

The script will open a dialog that impossible to interact with your site. The users have to close the browser tab or disable javascript execution to get rid of the dialog.

There are other kinds of dialogs apart from window.confirm():

  • window.alert()
  • window.print()
  • window.prompt()
  • the beforeunload event

Prevention method:

Include sandbox attribute with removing allow-modals.  You can also use Content-Security-Policy: sandbox to be applied for all iFrame in your site. This setup will restrict iFrames loaded in your site to do dialog actions.

Other possible threats

There are a few possible threats that can be done if our site loads malicious iFrame:

  1. The iFrame contains a malicious form that can lead the user to submit sensitive information. This threat can be solved by using sandbox with removing allow-forms.
  2. The iFrame may unintentionally download malware to the user’s computer. This threat can be solved by using sandbox with removing allow-downloads and/or allow-downloads-without-user-activation.


Scenario 3: Your site load your own site in iFrame

Image 4. Display iFrame to your own site illustration

This scenario is clearly harmless. Your page is trusted, the content in the iFrame is trusted, nothing can go wrong.


Conclusion

Don’t be afraid to use iFrames. iFrames are totally useful when we want our site to be interactive by embedding media such as tweets, youtube videos, web stories, facebook or Instagram posts, etc.

If you feel safe because your site doesn't use iFrames, that doesn't guarantee your site is completely secure. As mentioned in this article, your site may be embedded by another site, or there may be an iFrame injection into your site. These threats make your site not completely secure.

Here is a recap to make your site more secure of using iFrames:

  1. Use trusted third-party libraries.
  2. Use trusted plugins.
  3. Handle XSS in your site to prevent iFrame injection.
  4. Use trusted iFrames source.
  5. Use proper Content-Security-Policy: frame-ancestors configurations. You can also use X-Frame-Options for older browser compatibility. These setups will make your site not allowed to be rendered by other sites other than included in the configurations
  6. Use proper Content-Security-Policy: frame-src configurations. This setup will make your site not allowed to render other sites other than included in the configurations.
  7. Use sandbox attribute with proper configurations in an iFrame. You can also use Content-Security-Policy: sandbox to be applied for all iFrame in your site. This setup will restrict iFrames loaded in your site to do page's actions other than included in the configurations

Even, this configuration may not prevent iFrame attacks. We can only trust the browser to do its job to make our site secure, but there is a possibility that the user is using an old browser or browser that does not support CSP or sandbox attributes.

To make our site safe, we need to conduct regular security checks on our site. There may be new security threats that cannot be prevented by current methods. So, we need to keep updating our knowledge with the latest information and knowledge.

Join us

Scalability, reliability and maintainability are the three pillars that govern what we build at Halodoc Tech. We are actively looking for engineers at all levels and  if solving hard problems with challenging requirements is your forte, please reach out to us with your resumé at careers.india@halodoc.com.


About Halodoc

Halodoc is the number 1 all around Healthcare application in Indonesia. Our mission is to simplify and bring quality healthcare across Indonesia, from Sabang to Merauke. We connect 20,000+ doctors with patients in need through our Tele-consultation service. We partner with 3500+ pharmacies in 100+ cities to bring medicine to your doorstep. We've also partnered with Indonesia's largest lab provider to provide lab home services, and to top it off we have recently launched a premium appointment service that partners with 500+ hospitals that allow patients to book a doctor appointment inside our application. We are extremely fortunate to be trusted by our investors, such as the Bill & Melinda Gates Foundation, Singtel, UOB Ventures, Allianz, GoJek, Astra, Temasek and many more. We recently closed our Series C round and In total have raised around USD$180 million for our mission. Our team works tirelessly to make sure that we create the best healthcare solution personalised for all of our patient's needs, and are continuously on a path to simplify healthcare for Indonesia.

Muhammad Nadzeri Munawar

Software Development Engineer, Web | Building Halodoc