Imagine your financial institution sends you an email that says you need to check something related to your account and the email contains a handy link to help you resolve the issue. You click on the link and the bank site loads, you login with your credentials and notice nothing out of place. Even though everything looked normal, an attacker has actually just intercepted your username and password. This is an example of an iframe injection attack.
Iframe is short for inline frame and is used to embed content from another webpage or site into the current page seamlessly. However, iframes can be very dangerous if they are used by malicious attackers to inject calls for malicious iframes into the URL itself or secretly insert malicious code on the page. The result of this may be that when you visited your bank website and clicked into the username and password boxes to enter your credentials, you were actually typing in the malicious iframe injected by the attacker. Think of it like a card skimmer at a gas station, as criminals put a fake card reader over the real one in order to steal credit card numbers.
Why does this happen? Well, mostly because the web browser does what it’s told. It doesn’t ask the user “do you want me to do this to keep you safe?” it simply receives code from the website or the attacker’s website, and renders/runs the code. This means that in order to stop this you have to instrument the website to instruct the browser to ignore rendering that malicious script. The website needs to define explicitly where the safe iframes can come from, while rejecting others. This is done using several different methods, though most involve headers to instruct the browser.
The X-Frame-Options HTTP response header can be used to instruct a browser whether or not it should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. This header can be part of the server response or can be set on a web application firewall (WAF) for all web responses to contain.
There are several options within Content Security Policy declarations made to the user’s browser that will direct further security decisions to be made by the browser. Things like Frame Ancestors statements, Frame Src (Source) and Frame Sandboxing can protect users from anything malicious that someone might attempt to inject into the page.
Even something as simple as having the legitimate frame always being on top with a “top=self” statement will create a browser directive to not load frames above that page.
Many of the iframe problems that exist have been solved in the past but as web issues are wont to do, sometimes history repeats itself and we end up with old problems resurfacing. Utilizing a WAF to set all security controls in the event they are forgotten in the app is a great way to defeat many of these types of attacks.
While iframe attacks are not directly an API security issue, they’re important web application attacks and can be solved with a properly-configured WAF such as from our partner Vercara. Adding Unified API Protection to the mix will not only protect against API-specific attacks but also intercept any API attack loads before they get to the WAF, enabling it to be more efficient.
Want to learn more? Get started with a free, no obligation API security assessment that gives you an attacker’s view into your organization’s APIs – and the next step in your web application and API security journey.
Never miss an update!
By clicking Subscribe, I agree to the use of my personal data in accordance with Cequence Security Privacy Policy. Cequence Security will not sell, trade, lease, or rent your personal data to third parties.
