A clickjacking attack is a user-interface-based attack where an attacker’s website is embedded into a vulnerable website may be on a plain site or by placing hidden content, tricking a victim to click the link and perform the attacker’s intended action.
To understand more, let’s look at one example website. Check the below website which is advertising season sale. If there is injection vulnerability exists in the application and this application deals with collecting lots of sensitive information from the user for processing payment which is not even allowed to store (credit/debit card) data as per standards.
An attacker can grab this opportunity to embed attacker website into this application and trick users to submit payment details. Once the attacker’s website is embedded into the vulnerable site, it looks like below.
Also Read: Server Side Request Forgery – How it works ?
Now, the user can’t differentiate any difference between the two sites and is tricked to enter the details. Once, the attacker grabs the entire payment detail from the victim user, anytime the user can be scammed into huge financial loss.
There are lots of efforts made into fixing these issues by browsers so far. But, it’s always the vulnerable website’s responsibility to fix such issues through coding.
How to identify such cases?
One simple rule can be followed by the user to avoid this attack. Right-Click on the website and select the view page source option. If the iframe option is the user and some other source is mentioned here attacker.html. Click on that source and check whether that website URL matches the original/originated website.
If it’s not the same URL, then it’s better to avoid submitting such information on the original site. Even to verify about that attacker site, ip address or DNS can be cross-checked in phishing domain search sites for its integrity.
How to prevent this attack?
Mitigation for this attack is relying on User-Interface, so browser headers that were developed for this issue can be configured at the webserver.
- Make sure that user input data is accepted without validation or sanitization.
- X-Frame-Options can be used at server side.
- X-Frame-Options: deny won’t allow any website to be framed as part of application
- X-Frame-Options: sameorigin can be used to allow application for same origin to be framed inside the application.
- X-Frame-Options: allow-from https://trusted-website.com will allow the external trusted application to be embedded as part of application.
- Content Security Policy (CSP) is one more server side mitigation for this attack. CSP header instructs browser to load contents from another application.
- Content-Security-Policy: ‘none’; same like deny option in X-Frame-Options. Content from another website won’t be rendered in the application.
- Content-Security-Policy: frame-ancestors ‘self’; similar to sameorigin policy in X-Frame-Options header. Allows sites within same origin to load the content into browser.
- Content-Security-Policy: frame-ancestors trusted-website.com; same way like allow-from option in X-Frame-Options header, it will allow content to be loaded from trusted site into the browser.
With these options, Clickjacking can be prevented. Even identifying such attacks is also covered for the safeguard of users.