Allowing the webpage to open in iframe exposes it to security attacks. In this blog, we will list out the vulnerabilities exposed and try to suggest solutions to mitigate them.
In this attack, the attacker opens a webpage in an iframe. On top of this webpage, he opens an invisible webpage with action buttons matching the position of the action buttons inside the iframe. When the user tries to click on the buttons which are visible, he is actually clicking on the invisible action buttons. Read more about this attack on OWASP.
Cross Frame Scripting
Defense Against Above Attacks
Content-Security-Policy Header frame-ancestors directive
To prevent a webpage to be included in any iframe on any website, set the value of
frame-ancestors directive as
'none'. See the example below.
Content-Security-Policy: frame-ancestors 'none';
To allow the webpage to be included in iframe only on whitelisted websites, send the URLs to these websites in the form of a space-separated list in the value of
frame-ancestors. See the example below.
Content-Security-Policy: frame-ancestors https://example.com http://*.example.com;
Read more about the frame-ancestors directive on MDN Web Docs.
This HTTP response header can be used as a defense in the case of old browsers. For new browsers, the
Content-Security-Policy header’s frame-ancestors directive is given respect.
There are 2 possible values for
SAMEORIGIN. If we set it to
DENY, then the webpage will not open in an iframe. If we set it to
SAMEORIGIN, then the webpage will open only in iframe elements that have the same origin. Read more about
X-Frame-Options on MDN Web Docs.
SameSite Cookie Attribute
Set the SameSite cookie attribute to
None should be avoided. Read more on MDN Web Docs.
In this blog, we saw the possible attacks which can be caused by making a webpage includable in an iframe. Also, we listed out possible defense mechanisms. If you want help in eliminating this vulnerability, you can get in touch with True Sparrow, that’s us.