ClickJacking and Blind XSS

What you see is NOT what you get!

In essence, ClickJacking (or UI redressing) is a technique used by attackers to trick users into clicking on malicious web pages that they wouldn’t have accessed otherwise, by overlaying them on apparently legitimate web pages and hiding them from sight. When ClickJacking is successful, it can have various effects depending on the intention of the attacker and the other live web sessions in the victim’s browser. For example; clicking on hidden pages can lead to data loss via proliferating XSS attacks on currently available web sessions, redirections to malware infected websites, contribution to click fraud or spam, and essentially any unwanted actions that can be triggered with a click of a mouse.

Most commonly, attackers abuse a feature of HTML / CSS in order to set up the ClickJacking attack: the transparent iframe. This technology allows overlaying invisible iframe objects over legitimate websites, thus luring the victim into click on objects of the attacker’s choice, while being under the impression that they are browsing a harmless webpage.

Typical example:

CSS:

iframe {
position: some value;
width: some value;
height: some value;
top: some value;
left: some value;
z-index: some value;
opacity: 0;
filter: alpha(opacity=0);
}
button {
position: some value;
top: some value;
left: some value;
z-index: 1;
width: some value;
}

HTML:

<iframe src="”URL" height="240" width="320" scrolling="no"></iframe>
<button> Appealing text </button>

As a result, the victim loads a seemingly legitimate web page hiding the iframe. The page is crafted so that it appears legitimate. Hence, when the victim clicks on the button that has a luring caption, he or she actually clicks on another object of the attacker’s choice.

ClickJacking as a method of delivery for Blind XSS

In general, XSS attacks – Blind XSS included, are based on the premise that the attacker can build and inject a malicious script into the HTML page that the browser processes for display, causing it to execute the payload. In the case of the Blind XSS attacks, the payload would get stored for an undetermined period of time and then will presumably be served to a different user, in a different web page / context and eventually get executed by the browser. During all this time the attacker implements tools that would listen to feedback coming from the initial payloads being deployed.

However, there are cases where injection from the attacker’s side is not possible because of the technologies used by the target webpage, and in case that particular web page presents sufficient interest, the attacker will find ways to deliver the payload nevertheless. One such way is luring legitimate users to build and deliver the malicious payloads themselves, through the use of ClickJacking techniques.

Let’s assume that the attacker is keen on delivering a payload through a client web application based on AJAX technology, which does not expose the vulnerable parameter – the input for a search function. The ultimate goal of the attacker is to deliver a Blind XSS attack through the parameter of the “website search” functionality, which in turn would get stored in the search logs, and get reflected back to an administrator who generates reports on the keywords being searched on the website, thus generating the Blind XSS condition. The showstopper is the fact that the attacker does not have access to the search parameter as it is not submitted via a POST request or in the URL. The only way to populate the search parameter with the malicious payload would be to trick the victim using the client web application into manually building and delivering the malicious script.

This is where ClickJacking techniques come into play. The attacker builds an apparently legitimate webpage that will collect user input, in the form of clicks, drag and drops or combinations of the two, using a hidden iframe which, in the background, would generate the XSS payload and input it in the vulnerable field.

Drag and drop games

The Drag and drop games technique lures victims into playing apparently harmless short games by offering a “prize” or challenging them to beat a certain completion time. In most cases the games consist of dragging certain objects (images of balls, fruit or letters) into corresponding table columns or containers (basket, fridge, etc.). What happens in the background is really interesting – the attacker sticks the control in which the payload must be manually inputted by the victim (i.e. text box) to the mouse cursor while hiding it with an iframe. Each time the victim drags a letter as part of the game, the letter may be input into the vulnerable control as well. For the game to end successfully, the victim must do a series of actions that will ensure that the vulnerable control has been properly populated with the malicious script to be injected.

You can watch an example of building an XSS payload via ClickJacking here and read more about it here (in this case, the attacker is after a reflected XSS attack targeted at getting a logon name).

Thus, ClickJacking enables attackers to deliver malicious payloads in situations where they couldn’t have done so otherwise. In the case of Blind XSS attacks, following on the example above, the attacker would have successfully delivered a malicious payload through the “search” parameter by manipulating the user into manually building and injecting the payload on his/her own. The payload gets stored in the search logs and waits for an administrator, using a management web application, to access the entry somehow (i.e. via reporting) causing the payload to execute, and complete the Blind XSS attack.

Defending against ClickJacking

Developers can implement protective measures, like setting the X-Frame options headers to DENY or SAMEORIGIN (which will prevent framing or allow it only from the same domain), implement frame-breaker scripts on each page presenting a potential risk of framing, or find ways of letting users know when the page is framed. You can find more information on preventing ClickJacking here.

However, the best way to avoid ClickJacking is to render it ineffective – make sure that the web application is not vulnerable to XSS or other types of web vulnerabilities. This way, even if pages are framed, and ClickJacking is successful, the sanitization code will handle the malicious payload and the attack won’t be successful.

Web vulnerability scanners and penetration testing tools deliver peace of mind when it comes to assuring that the web application is not vulnerable to attacks, particularly nowadays when web content is highly dynamic and the attackers develop new ways of circumventing static security measures on a regular basis.