Clickjacking Vulnerability - Shezartech
post-template-default,single,single-post,postid-11437,single-format-standard,mkd-core-1.0.2,sparks child-child-ver-1.0.0,sparks-ver-1.5,mkd-smooth-scroll,mkd-smooth-page-transitions,mkd-ajax,mkd-grid-1300,mkd-blog-installed,mkd-header-standard,mkd-sticky-header-on-scroll-down-up,mkd-default-mobile-header,mkd-sticky-up-mobile-header,mkd-dropdown-default,mkd-header-style-on-scroll,mkd-full-width-wide-menu,mkd-header-standard-in-grid-shadow-disable,wpb-js-composer js-comp-ver-6.0.3,vc_responsive

Clickjacking Vulnerability

Webpages consist of user interaction elements, like buttons, checkboxes, text fields, etc. Each element has a process associated (coded) with it. When a user interacts with an element, its background code executes. That process could be submitting credentials, liking a post on a social media page, or initiating fund transfer. The process (code) is not visible to users, as it runs in the background. A person with malicious intent can exploit this scenario and get users to perform a different activity than intended. This act is called ‘Clickjacking’. Such an act could be performed for various reasons, like getting alike for a Facebook page, getting money transferred, etc. Let us have an example to see how clickjacking works.

An attacker wants to steal a person’s money. The person often visits a bank’s website. Upon visiting, the first step is to log in. As the person logs in and reaches the fund transfer page, the attacker manages to redirect him from the bank portal to this own portal using malpractice. This portal has a user interface element named ‘iframe.’ These elements can display a remote webpage within themselves. The attacker codes this ‘iframe’ to display the bank’s fund transfer page. Since the iframe shows the bank’s webpage, the user does not figure out that he has got redirected. This portal also contains functionality to transfer funds to the attacker’s bank account by clicking a button. This functionality is kept invisible (transparent) but floats above the iframe’s content. The whole arrangement is made such a way that the bank portal’s fund transfer button and the attacker’s fund transfer button overlap each other. The bank’s button is visible, but clicking on the same area of the screen would ‘press’ the attacker button, since it is present right above, though invisible. As the user clicks fund transfer, the amount gets transferred to the attacker’s bank account.

The solution is to disable iframe support. Whenever a request for a webpage comes, the web application sends back a response to it. This response is known as ‘HTTP response’. This response has a component called header. Headers contain various parameters that provide additional information about the response package’s data. One of the settings is ‘x –frame’. It is possible to set this parameter and prevent the page from getting rendered (displayed) within an iframe component. This way, the vulnerability can be mitigated.