PCI DSS compliance dates are fast approaching, and we are a little more than a year away from the SAQ A iFrame changes that many merchants and service providers will need to deal with. iFrames used to be the primary escape hatch that companies would use to avoid bringing vast parts of their websites into scope for PCI DSS, but this has now changed.
In our example, let’s assume the parent site is store.com, and upon checkout they present an iFrame hosted by paymentprovider.com.
Before we dive in, let’s talk about the issue the Council is trying to solve.
iFrames, when implemented correctly, can be a powerful tool in keeping sensitive, user-entered content secure. The mere presence of an iFrame tag on the parent website also unfortunately means that there is a risk of iFrame injection. This is how MageCart was going after Magneto-powered eComm sites. Essentially, a compromise of the parent site can lead to iFrame injection allowing attackers to replace your iFrame with theirs. There are ways to mitigate this attack even if the parent site is compromised, which is what requirement 11.6.1 is attempting to explain.
While researching this issue for a client, a number of QSA Companies publish recommendations on how to solve this, but they are ignoring the most common one (which is ironically listed in the Guidance for Req 6.4.3). This isn’t just a “be vigilant about patching” type solution. Unfortunately, solving this problem can be difficult to manage.
The quick way to solve for this is having the parent site install a Content Security Policy (CSP) and using tools to ensure it does not change. When implemented correctly, code cannot execute from random places on the Internet—only locations approved in the CSP. Branden has implemented CSPs before and they are a hassle. Generally, in order to not break sites with lots of dynamic and external content (think tags, tracking, etc.), you have to water down the CSP sufficiently enough that it could be bypassed in a supply-chain attack (depending on where the code is loaded from) or worse. Sandboxing may be a possibility, but it likely does not solve the problem without breaking other things given that you may need to execute code in the iFrame.
A CSP can be used to address 11.6.1 in SAQ-A. There are monitoring services available, but this could easily be tracked and monitored in a python-based Lambda function as well. If you choose to have near realtime monitoring, you would know in advance if you have had a compromise that could lead to iFrame injection, allowing you to meet this requirement.
We’d love to hear more from you! Don’t forget to participate in our GitHub Community! We’ve got tons of useful links there, including a link to join our Discord server as well for real-time chats about PCI DSS.