Clickjacking is also known as the “User Interface redress attack”. The attacker uses a malicious technique of tricking a user to click a button or link, which reveals confidential information, which in turn allows an attacker to take control of the user’s computer or the web browser.
There is one popular attack cross-site request forgeries (CSRF) that can interact with functions on other websites. Unknown HTTP requests are raised and successfully executed at other website operations. Like Attacker.com is able to ‘Like’ or ‘Share’ post on facebook.com.
Clickjacking is bypassing the same-origin policy with UI redness. The malicious site tricks a user into clicking on a masked element of another site which they have loaded in a hidden iframe. Clickjacking is easy to implement, if there is an action on your site that can be done with a single click it may be clickjacked. This redressing is a serious attack that can have an awful effect.
Impact
- To gain followers on social media and then, possibly, sell the social media account/page for mass marketing.
- To have the user unknowingly transfer funds to the attacker.
- To have the user download malware (e.g. a trojan).
And much more.
Defense
As a website or web application owner, you must make sure that your web assets cannot be used in a clickjacking attack. You may use several techniques for that purpose. You can also use several of them together to ensure full coverage.
- Using X-Frame-Options HTTP headers.
- Using Content Security Policy (frame-ancestors) HTTP headers.
- Using SameSite cookie attribute.
- Using Frame busting
X-Frame-Options
X-Frame-Options (XFO) is an HTTP response header. It was introduced in 2008 in Microsoft Internet Explorer 8. However, it was never accepted as an official standard (despite the IETF publication RFC 7034 from 2013). This response header is a simple predecessor of the frame-ancestors directive.
X-Frame-Options HTTP header that indicates whether or not a resource is allowed to load within a frame or not. If the response contains the header with a value of SAMEORIGIN, then the browser will only load the resource in a frame if the request originated from the same site. If the header is set to DENY, then the browser will block the resource from loading in a frame, no matter which site made the request.
Content Security Policy (frame-ancestors)
Content-Security-Policy (CSP) is an HTTP response header. It was designed primarily to protect against Cross-site Scripting (XSS) attacks. Currently, it also includes an anti-clickjacking frame-ancestors directive. This directive controls how the page can be embedded by different sites by specifying parent pages that may embed the page.
SameSite cookie attribute
The SameSite cookie attribute defined in RFC 6265bis is primarily intended to defend against cross-site request forgery (CSRF); however it can also provide protection against Clickjacking attacks.
Cookies with a SameSite attribute of either strict or lax will not be included in requests made to a page within an <iframe>. This means that if the session cookies are marked as SameSite, any Clickjacking attack that requires the victim to be authenticated will not work, as the cookie will not be sent.
Frame busting
Framebusting (also known as framebreaking or framekilling) is a client-side technique. It does not require any modifications to HTTP headers. All you need to do is modify your web page HTML code.
Secure Clickjacking in CloudFront
You cannot directly add the HTTP headers in the cloudfront for the response. As of now you only can add the custom headers for the requests made to cloudfront not the response. So, In order to add X-Frame-Option header to all the responses we need to create a lambda@edge function and associate that function to the origin response in the cloudfront configuration.
Use to below code to create the lambda@edge function
Secure Clickjacking in Amplify
If you are hosted your webapp frontend in Amplify. You can directly add these security headers in the Amplify console under custom headers menu or you can create a file named customHttp.yml and place it in the root of your app code.
Secure Clickjacking in Nginx
Clickjacking in Nginx can be secured by adding the HTTP headers in the nginx configuration file. Look at the below gist for the header settings and various options.
Common Mistakes
- Setting X-Frame-Options inside the
<meta>element is useless! For instance,<meta http-equiv="X-Frame-Options" content="deny">has no effect. Do not use it!X-Frame-Optionsworks only by setting through the HTTP header - If the Clickjacking attack does not require the user to be authenticated, then SameSite attribute cookie will not provide any protection.
- Content-Security-Policy may only be used directly as a response header, it cannot be used in meta tags.
Writer: Mounick
About me: A DevOps engineer and serverless evangelist with a love of all things AWS, innovation, security, software architecture and technology.
Follow me on LinkedIn
