Clickjacking, Forgery and Phishing


Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or Black-Hat-Hackerstaking control of their computer while clicking on seemingly innocuous web pages. A clickjack takes the form of embedded code or a script that can execute without the user’s knowledge, such as clicking on a button that appears to perform another function.

How clickjacking works:
A user searches for a website, for eg: The listed URL may contains some dummy URL. Once the user clicks on this URL the hacker opens the actual www. in an iFrame. And hence the user is tricked into believing that it is the actual site. Here he clicks on any button for eg: Submit Bank Details. This button will be masked by an invisible button which will redirect the user to the hackers web page and the user will unknowingly type in all the details and this will be captured by the hacker.

Proposed Fix:
To fix this issue execute a set of code which will check if the URL in the iFrame is same as the URL on the browser i.e self==top. If yes, then continue else the URL in the iFrame will replace the browser URL and hence the user will be redirected to the authentic website.
First apply an ID to the style element itself:

<style id="antiClickjack">body{display:none !important;}</style>

And then delete that style by its ID immediately after in the script:

if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
} else {
top.location = self.location;

Cross-site request FORGERY(CSRF)

Cross-site request forgery abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF, is a type of malicious exploit, ie CSRF is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

How CSRF works:
A simple example is, if a bank for eg: uses the below URL for transferring money to a particular user named ABC.

A hacker can send an html email with the below link as some promotional campaign,

 <a href="“"">View my Pictures!</a>

Once the user unknowingly clicks on this link, the amount gets transferred.

Proposed Fix:

  • Include a hidden form field on all forms of your site which are required when a user is logged in.
  • Include this form field or token value in the users session variables, so that they have a copy.
  • After every POST or GET evaluation you want to protect, make sure that the token from the browser (session) matches the token from the form (GET/POST value) If they do not match, then the page may have been submitted fraudulently (XSRF)
  • The token may be generated new for each form and stored server side or in a database.

PHISHING referrer trust

In phishing attacks, a hacker creates a website that resembles a victim web’s application. The fake website often reuses pages and images from the original website to seem authentic. Pages from the original site may be embedded in frames in the phishing site. The fake website can thus capture form information sent by users and forward the data to the authentic website.

How Phishing referrer trust works:
The HTTP Referrer field is a browser-passed value in an HTTP header meant to provide a basic means for logging and tracking the origin of HTTP requests. Web servers can be configured to allow requests originating only from specific sites based on the HTTP Referrer field. Some sites use the values of this variable as a part of their access-control measures. Check for HTTP Referrer allows a web server to add a barrier for attacks such as Cross-Site Request Forgery (CSRF).

Proposed Fix:
Always check for difference between the referrer domain and the current domain. If it is different, the user will be redirected to access denied page.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s