Main Content

ClickJacking and JavaScript KeyLogging in Iframes

This week I was asked some specific questions about the security of iframes. The questions came about from a PCI standpoint, for stores that use fully outsourced iframes for taking payment.

The question was effectively, if an attacker can inject JavaScript into the framing (store) page, what effect can they have on the security of the site and the payment page.

Short answer: The attacks are very limited.

Long answer:

ClickJacking

The issue ClickJacking allows an attacker, that can trick a user into visiting a page, to cause the user to perform actions on another page, without them being aware of it.

Effectively this is achieved by creating a malicious page that entices the user to click on the malicious page, but having that page frame a victim page.

The framed page should be displayed at the “front” (as in, have a higher z-index) and should be made near invisible (as in have an opacity set to 0.001). That way the user will click the page thinking they are performing some action on the framing page, but that click will actually “land” on the transparent framed page.

This attack is very restricted, by requiring a user be tricked into visiting a malicious page (or perhaps a trustworthy page that has a convinient cross-site scripting vulnerability) and then interacting with that page in such a way that the “clicks” land on inputs that cause a security issue to occur

ClickJacking is often reported by vulnerability scanners, or some security testers, simply because a page is frameable (as in, does not have an X-Frame-Options header, or is restricted from being framed with Content-Security-Policy). However being frameable is simply the first step in creating an actual exploit for this issue, the latter step can often be quite difficult.

For example, think about the applications that you visit and thing of what kind of security issue you could create only by clicking, and that add to that the requirement for a user to be tricked into visiting and interacting with a malicious page. There aren’t many places that becomes an issue.

Two example risks would be: shops that allow for 1-Click ordering, where you trick a user into buying things from you, or causing a user to “like” a political post on social media.

Overall, a genuine risk yes – but often quite unlikely to be easily exploitable en masse.

Is ClickJacking limited to clicks only? No, in the same way you can convince a user to click on a transparent iframe you could get them to type into the iframe, however again this attack is limited…

KeyLogging

I was also asked about the possibility of keylogging through an attack as described above. This come from the idea that it is possible for JavaScript to detect keypresses (onkeydown).

This is limited when considering iframes, as the onkeydown event effectively follows “focus”. Meaning that whilst it is possible to log key events it is not possible to log them on a framing page and have the framed page receive them (or vice versa)

The attack that was being considered was injecting third-party code into a storefront (perhaps through a cross-site scripting attack) and then using that code to keylog the payment card details of a user as they type them into an iframe payment page.

This is technically possible, in a slightly different way to previously mentioned – by this time putting the framed page behind the malicious, or compromised store, page.

Then the attacker could use JavaScript such as:

var stolen = "";
document.addEventListener('keydown', logKey);
function logKey(e) {
if (e.key != "Meta" && e.key != "Shift" && e.key != "Alt" ) {
stolen = stolen + e.key;
}
document.getElementById('log').innerHTML = stolen;
}

The above short script could be used top capture key presses on the framed page, allowing for keylogging. However these keypresses would not propagate to the framed page. It could be made to look as though it does, by drawing the captured text to the screen in the relevant places on the framing page. So the text overlays the framed page and looks (in two dimension) as though it’s on the framed page. However the framed page won’t receive these key presses and therefore whilst the details could be stolen it would likely be detected quickly if exploited en masse – through a reduction in sales (and many users getting to the final step of the checkout process but appearing to never complete it).

The next logical thing to try would be to use document.getElementById() to try and addEventListender() to the iframe itself – to determine if keys can be captured by the parent from the framed page. This is not allowed when the frame is of a different origin, due to same-origin policy. Thereby the attack is limited again.

So it is possible to capture keypresses that a user thinks are going into a page, you could even write text to a div displayed in front (higher z-index) of the payment page to make it look like the key presses are propagating.

This would allow you to steal personal data and payment card information yes, but it would do it in such a way that it could be quickly detected (payments wouldn’t be made and the lack of sales would be noticeable). So in short, this is no better than other attacks you could come up with in this context – such as simply overwriting the legitimate payment page with your own malicious payment page and capturing the card details that way.

You could possibly capture the payment card before it’s given to the iframe and then put through the order as a separate action, perhaps through a cross-origin message or a HTTP post – but this likely be blocked. Unless, in addition, a cross-origin resource sharing issue or a cross-site request forgery issue also exists.

Summary

Payments handled through fully outsource iframes do have additional security in place when compared to a payment page embedded in the store page itself – through same origin policy enforced by web browsers.

Yes JavaScript can monitor some key strokes, but not all, same-origin policy will likely get in the way and make it so the attack is significantly more likely to be detected. ClickJacking is a real vulnerability but it’s often a very limited attack.