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.
Consider these ways for an attacker to access to a payment iframe window object:
// reference to iframe window by index var frame = window.frames;
// reference to iframe window by id var frame = window.frames["frame1"];
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.
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>
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:
Aaron Willis is a Senior Forensic Analyst at SecurityMetrics. He has over 25 years of diverse experience in all aspects of IT security, digital forensics, risk assessment, business intelligence, data mining, SaaS consulting, and programming. In addition to being the VP of Technology at ScrapeGoat, Inc, Willis teaches Digital Forensics as an adjunct instructor at Utah Valley University. Willis holds a Bachelor’s in IT from the same school and a Master's in Digital Forensics from American Military University.