In today's blog post, I will be discussing what ClickJacking attack is and how we can prevent it.
Let's take a look at an example:
Suppose, you have a simple banking web application with transfer functionality. The Transfer button is the one which does the money transfer from your account. In my example, I just simply show an alert message called Clicked when Transfer button is clicked.
Next, here is the attacker website where he can lure the user to click on a specific button or area And when the user clicks on the "Claim Coupon"
When the user clicks on the "Claim Coupon", then "Transfer"
functionality is triggered. Imagine, if you were logged into your bank
account and your bank website had this vulnerability, the money could
have been transferred from your account.
<iframe style="opacity: 0;" scrolling="no" src="http://localhost:3931/Bank/TransferMoney"></iframe>
In my sample application, let me remove the opacity style attribute and let's take a look at the webpage again. So, the transfer button is invisible but when "Claim Coupon" is clicked, in reality, Transfer button is clicked. So suppose the user's session is currently valid, this can cause user to inadvertently do things which he/she never intended from their accounts.
Here we are adding X-FRAME-Options to response headers with value DENY.
There are 3 values possible to X-Frame-Options:
i) DENY: do not allow any site to frame your application
ii) SAMEORIGIN: only allow same application site to frame
iii) ALLOW-FROM: only allow specific domain to frame your application
So having DENY option loads the malicious page.
This time, the Transfer money page is not rendered inside the frame as we denied it.
For future updates to my weekly blog, please subscribe to my blog via the "Subscribe By Email" feature at the right.
ClickJacking
ClickJacking is a neat little malicious technique whereby the victim is fooled into clicking on something other than what the user is actually clicking on. This can be accomplished by the attacker using multiple transparent or opaque layers. The user views only the top level page but when they click, they actually trigger the functionality from another hidden layer. This causes some actions which the user never really intended.Let's take a look at an example:
Suppose, you have a simple banking web application with transfer functionality. The Transfer button is the one which does the money transfer from your account. In my example, I just simply show an alert message called Clicked when Transfer button is clicked.
Next, here is the attacker website where he can lure the user to click on a specific button or area And when the user clicks on the "Claim Coupon"
How?
So what happened behind the scenes is, the attacker has created an invisible iframe which loads the vulnerable web page inside the iFrame. And the "Claim Coupon" label is placed right on top of Transfer button inside the iFrame. So when the user clicks on the label, he/ she is actually clicking on the Transfer button.<iframe style="opacity: 0;" scrolling="no" src="http://localhost:3931/Bank/TransferMoney"></iframe>
In my sample application, let me remove the opacity style attribute and let's take a look at the webpage again. So, the transfer button is invisible but when "Claim Coupon" is clicked, in reality, Transfer button is clicked. So suppose the user's session is currently valid, this can cause user to inadvertently do things which he/she never intended from their accounts.
How to Prevent
In order to prevent this attack, we need to prevent others from framing our application. In ASP.NET application, we can simply add this to <system.webServer> in our Web.Config<httpProtocol> <customHeaders> <add name="X-Frame-Options" value="DENY" /> </customHeaders> </httpProtocol>
Here we are adding X-FRAME-Options to response headers with value DENY.
There are 3 values possible to X-Frame-Options:
i) DENY: do not allow any site to frame your application
ii) SAMEORIGIN: only allow same application site to frame
iii) ALLOW-FROM: only allow specific domain to frame your application
So having DENY option loads the malicious page.
This time, the Transfer money page is not rendered inside the frame as we denied it.
Conclusion
In this post, we saw how a malicious attacker can fool the user to click on elements which the user never intends to and cause unwanted actions. We also saw how to prevent this attack in an ASP.NET MVC application by using X-Frame options.For future updates to my weekly blog, please subscribe to my blog via the "Subscribe By Email" feature at the right.
No comments:
Post a Comment