JavaScript Can Access IFrame Attributes and Properties

Payment Iframes have a reputation for their ability to protect the contents they contain from threats like cross-site scripting and other data extraction attacks. This can be true, especially when the iframe is properly configured with same-origin and other properly implemented security protocols. However, that is no excuse to be lax on perimeter security.

If a bad actor gains access to a webpage containing a protected iframe, Javascript provides several methods to manipulate that iframe element, and maybe even trick a customer into giving the thieves their credit card number. This can happen even if the payment form inside the iframe itself remains safe from extraction or manipulation.

Consider these ways for an attacker to access to a payment iframe window object:

// reference to iframe window by index
var frame = window.frames[0];
    
// reference to iframe window by id
var frame = window.frames["frame1"];
    

Changing IFrame

Once an attacker has access to the window object, the location property is easily switched.

//what happens to an iframe when its location property is changed?

 //iframe is loaded correctly
<iframe src="http://legitimate_iframe.com/checkout.php"
 // load attacker's checkout page
frame.location = 'fake_checkout.php';

In this example, the attacker did little to conceal that the checkout process is fake. To be clear, in this example, we put in obvious clues that the web form is compromised. Hackers will never be so accomodating. Lets look at a more subtle attack.

Invisible Change:

If nothing happened, try clicking again.

Still seeing the same web form? That is the point. The source of the iframe did in fact change. The hacker just made the content identical to the real checkout.php page. In reality, the fake checkout page is not even on the same web server as the original one displayed. An attacker can call a malicious web form from anywhere, even one they create on the merchant's own web server. A customer would have no inkling that anything is amiss and even more disturbing is that if an investigator right clicks on the page to view the <iframe src=""> attribute, it will still show the original source, even though it has been dynamically altered.

//page source

<iframe src="http://www.legitimate_iframe.com/checkout2.php"></iframe>

Social Engineering:

While these are a very rudimentary examples of basic iframe jacking, in the real world, forensic investigators are reporting very sophisticated attacks, some that even involve aspects of social engineering.

At the end of the day, we must remember that iframes are rendered as HTML elements in the browser just like any other tag on the page. As such, if an attacker gains access to your checkout code, it might not matter how secure your credit card iframe is. A thief can simply comment it out and replace it with their own. Sure, it might interrupt the legitimate transaction, but a devious hacker could then simply put your customer back on the correct checkout path.

For example enter your credit card (i.e. 4111111111111111) and CVV (111) into this completely legitimate looking payment form and click submit:

Click to process your credit card: