In the last article, we discussed the vulnerability of websites to Cross-Site Scripting (XSS), which allowed attackers to steal user data. Thanks to frameworks like Angular, effective security mechanisms have been introduced. However, attackers are not giving up and now have to put in significantly more effort to expose your website visitors to malicious JavaScript code. The iframe sandbox provides an even stronger security framework to isolate potentially dangerous third-party content on your website.

The story continues

You are a user of an online shop: You’re excited about the new winter collection from your favorite  retailer but prefer to try on the shirt in a physical store before purchasing. While browsing, you come across an interactive map embedded in the online shop, providing a compact overview of all nearby stores. How convenient – or is it?

What you don’t know: This map does not come from the online shop itself but from a development team at an external company. This team prioritizes rolling out new features over maintenance and bug fixes, which means security vulnerabilities often remain unpatched for a long time. Attackers are always on the lookout – but their target is no longer the software modules you write; instead, they now focus on your project’s dependencies. By opening the interactive map, a new potential security vulnerability has emerged.

In the following section, we’ll show you how to mitigate this security risk by using an iframe sandbox to confine it to a protected space, improving your IT security with proactive XSS protection.

Updates Against Security Vulnerabilities

Publicly known security vulnerabilities are recorded in the CVE system. CVE stands for “Common Vulnerabilities and Exposures.” It is a public and widely used identification system for security vulnerabilities in software and hardware. CVE entries typically do not contain detailed information about the vulnerabilities themselves. Instead, they serve as references to more detailed security reports and information provided by affected software vendors or other security organizations.

Before a CVE is published, the software’s development team is usually contacted and given time to release a patched version. If the team fails to do so, the discovered vulnerability is published anyway. Ideally, the team reacts quickly, and the vulnerability is closed before it becomes public. However, it is difficult to determine whether the vulnerability was actively exploited before its discovery.

When Updates Are Not Enough

You are a developer: You have embedded an interactive gas station map as an iframe on your website. The development team behind this map belongs to a large company with which you have signed an exclusivity contract. This company prioritizes rolling out new features over maintenance and bug fixes, meaning security vulnerabilities often remain unpatched for a long time.

As an attacker, you are aware of this team’s practices and would like to exploit them. If it were up to you, the map should do more than just run the code from the map team on users’ computers.

Sandbox for iframes

You are a developer: You have already taken precautions for this scenario. You are familiar with and use the “sandbox” attribute of an iframe.

When embedding third-party content on your website, the “sandbox” attribute provides better protection for embedded content (iframe).

<iframe src="https://beispiel.com" sandbox="..."> <!-- Inhalt des iframes wird hier platziert -->
</iframe>

The “sandbox” attribute accepts a space-separated list of values that define the restrictions applied to the content within the iframe. These values can include:

1. allow-same-origin: Allows the iframe to request content from the same origin as the parent page. This is typically required for communication between the parent page and the iframe.
2. allow-scripts: Allows JavaScript execution within the iframe. Without this value, JavaScript is disabled in the iframe.
3. allow-forms: Allows form submissions within the iframe.
4. allow-modals: Allows the iframe to display modal dialogs.
5. allow-popups: Allows the iframe to open new browser windows or tabs.
6. allow-popups-to-escape-sandbox: Allows popups to open outside the iframe sandbox.
7. allow-pointer-lock: Allows the iframe to use the Pointer Lock API.
8. allow-top-navigation: Allows the iframe to navigate the top-level window. Without this value, the iframe cannot change the URL of the parent page.

Depending on the desired restrictions for the iframe content, you can specify one or more of these values in the “sandbox” attribute.

For example:

html<iframe src="https://beispiel.com" sandbox="allow-same-origin allow-scripts"></iframe>

In this example, the iframe is allowed to execute JavaScript and request content from the same origin as your page. Other functions such as form submissions, popups, and navigation to external websites are disabled. Just like that, the next attack is prevented—even if the iframe has been compromised.

Stay tuned!

But attackers are persistent and are now targeting other dependencies of the website. Find out in the next article whether the popular rubber-duck-generator-module of the online shop, a dependency with many security vulnerabilities, can be saved from attackers.