In the e-commerce space, iFrames have become a popular option for merchants to maintain PCI DSS compliance and keep the checkout process accessible from inside their webpage. Hosted payment processors take on the complexity of compliance and merchants can tend to their business.
You can imagine an iFrame on your website like a safe room at the end of a hallway in your house. The manufacturer of the room assures you it is the best in the business and has given you easy instructions to implement the safe room. The integration is so well done, customers don’t even realize that the safe room is not actually a part of your house. When you use an iFrame, customers feel good about your security and trust you with their credit card, never knowing that you never even saw them. You feel secure knowing that you’ve side-stepped the risk of accepting payments on your own web server. You don’t collect, store, or transmit any card data. It all happens inside the iFrame–or “safe room”–away from prying eyes.
Then confusion, disbelief, and even anger ensue as you stare in shock at the Common Point of Purchase (CPP) notice from your acquirer. It simply cannot be you. You’re using an iFrame. You never even saw a credit card. Yet here you are, identified as the likely source of a credit card data breach. How did it happen?
Recently, SecurityMetrics forensic investigators have seen a surge in iFrame compromises. A lot of time and effort has gone into making the contents of payment iFrames more secure; there are tokenization schemes, drop-ins, hosted fields, iFrame specific security policies and other measures to ensure the card data remains unavailable to bad actors. But an iFrame is still just an HTML element rendered in the customer’s browser. A safe room in your house might give you some temporary security, but what happens if threat actors have unlimited access to attack the safe room? Hackers have not been idle in figuring out devious ways of extracting data from all those payment iFrames at the end of the hallway in your house.
At best, an iFrame is like a black box. Given enough time, a genius thief might succeed in figuring a way to get their malware into the box and capture the payment data from the inside. A lazy, clever thief might not bother with that much work.
Consider a basic iFrame tag: “<iFrame></iFrame>”. It is a browser window object. It supports all of the Global HTML attributes such as id, tabindex, and others. It also has specific attributes including a source (src) used to populate the frame with content external to the host page. All of these attributes and properties are accessible by JavaScript–the programming language that makes interactive web pages possible. All an attacker needs to do is find any area of the website or the customer’s browser where they can execute JavaScript commands against the iFrame tag.
DEMO: Click here for a few examples of some pseudo-malicious JavaScripts messing with a payment iFrame.
There are many things a merchant can do to protect their payment iFrame, but at the end of the day, an iFrame is nothing more than an HTML element on a page, and if bad actors can access the element itself, it might not matter how well guarded the payment data is inside the element.
Merchants must approach their security to protect the iFrame element with as much gravitas as they do the credit card data being collected inside the iFrame.
The merchant usually has little, direct control of the security of a hosted checkout process. Thus, the hosting provider may or may not implement a full collection of important security controls to protect your card data. (i.e. critical function logs, AVS, SSL, hardened firewall configurations, vulnerability assessment scans and more).
It is your job as the merchant to fully vet the security compliance (including PCI DSS) of the payment host. In order to begin to improve your security, you may wish to consider the following:
SecurityMetrics will be contacting it’s customer base of merchants to offer promotions for ASV scans where they have not previously been required.
Additionally, SecurityMetrics has created a more reliable method to flag Magento 1.x within our vulnerability scan (ASV). Recently, Magento 1.x has too often been a primary factor in merchant breaches.
While some aspects of the payment process may be “outsourced,” the merchant is ultimately responsible for protecting customer data. Education and awareness is an important first step in your cybersecurity and payment security compliance journey.
To learn more and stay up to date on the latest cyber threats, tips, and best practices, subscribe to SecurityMetrics Blog, Podcast, and News.
.svg)
