About
A page that provides users with an interface to perform actions that the user might not wish to perform needs to be designed so as to avoid the possibility that users can be tricked into activating the interface.
It's a UI Redressing attacks.
One way that a user could be so tricked is if a hostile site places the victim site in a small iframe and then convinces the user to click, for instance by having the user play a reaction game. Once the user is playing the game, the hostile site can quickly position the iframe under the mouse cursor just as the user is about to click, thus tricking the user into clicking the victim site's interface.
To avoid this, sites that do not expect to be used in frames are encouraged to only enable their interface if they detect that they are not in a frame (e.g. by comparing the window object to the value of the top attribute).
Example
If users are allowed to use the style tag, they could create a link that takes the whole page area and is not visible.
Example 1):
<a href="http://example.com/attack.html" style="
display: block;
z-index: 100000;
opacity: 0;
position: fixed;
top: 0px;
left: 0;
width: 100vw;
height: 100vh;"> </a>
where:
-
-
- z-index of 10000 put on top of all other elements
- dimensioned:
- the width of the screen (100vw)
- the height of the screen (100vh)
-
- opacity makes it invisible.
Prevention
Frame ancestors
The frame-ancestors csp directive restricts the URLs which can embed the resource using frame, iframe, object, or embed.
It works only with a http response header
Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options
This HTTP header is enforced at the browser level. It was never standardized and has been deprecated in favour of the frame-ancestors directive
Applying the X-Frame-Options directive via meta http-equi seems to not work.
<meta http-equiv="X-Frame-Options" content="deny"/>