Guides

Guide: From ClickJacking and Self-XSS to XSSJacking

During a penetration testing we may face some input sanitisation issues that can lead to various XSS attacks. However, many times we are not able to trigger these issues and perform an attack with an actual impact. For example, we may find an XSS on a submit form which sends the user’s data with POST requests. Moreover, these data are reflected back to the same user and nobody else can view this page. If, for any reason, we can execute arbitrary code on this segment of the page, the XSS is categorised as self-XSS and does not have any impact because nobody can send the malicious request except of the victim. But what if the site is vulnerable to a ClickJacking attack? If the site can be embedded to an iframe, the attacker can leverage this vulnerability and force the user to submit malicious JS through the ClickJacking attack. A security researher called Dylan Ayrey created a really nice proof of concept code that exploits these two vulnerabilities in order to perform a valid XSS attack. At first, we have the vulnerable page as presented below (for this example, the page is a form which does not get any input from HTTP GET parameters and an attacker cannot send a malicious link of this page in order to execute arbitrary JS):

The above website is vulnerable to a ClickJacking attack as well. The attacker creates a classic registration form as like the following:

However, the registration form has the iframe with the vulnerable page on the second part as an invisible overlay.

Moreover, the attacker has a JS event that copies the following JS vector on the clipboard when the user tries to use CTRL+C (Many people are lazy and use copy-paste to confirm their email addresses).

When the victim pastes the email address, the XSS will be used instead.

If you want to replicate the attack, please consider to download the Proof of Concept exploit code from:

Tagged