This week brought news of an inline frame (iFrame) payment solution that was hacked in the UK. For all of you merchants that use an iFrame solution because you were told it reduced your PCI scope, you may want to rethink your security strategy. For all of you hosting companies that offer these iFrame solutions because of the scope reduction value, you too may want to rethink your security strategy as well.
For those of us that are not Web developers, an iFrame is:
“An HTML document embedded inside another HTML document on a website. The iFrame HTML element is often used to insert content from another source, such as an payment page or advertisement, into a merchant’s Web page.”
For merchants using an iFrame for handling payments, the PCI DSS rules that the iFrame makes the merchant’s Web site out of scope because the iFrame is managed by the payment provider, not the merchant. Thus merchants using an iFrame or a redirect are allowed to fill out an SAQ A. However, because of increased risks to merchant Web sites using iFrames and redirects, the Council has updated SAQ A in response to those risks.
But there has always been a risk that iFrames and redirects could be manipulated. The attack used in the article was fairly sophisticated in that it required a lot of knowledge about how that particular iFrame worked and then used a man in the middle (MITM) approach to intercept the invocation of the payment processor’s iFrame and insert their own iFrame. Not easy, but definitely effective.
The easier approach is an attacker changes the script/executable that invokes the iFrame/redirect to invoke a malicious iFrame/redirect. A merchant would be alerted to such a change if critical file monitoring were required, but SAQ A does not require critical file monitoring.
This is why a lot of QSAs have told their clients that only fools believe that the requirements in SAQ A will keep their Web sites secure. At a minimum, merchants using iFrame/redirect solutions should have critical file monitoring and logging implemented as well as conducting quarterly vulnerability scanning so that they can secure their Web sites as well as alert on any changes or any suspicious activity on their Web sites.
PCI Guru 
Generally I totally agree that in an SAQ-A type of situation, the merchant should be applying various protections and detections to the web site which does the indirect/iFrame, and that SAQ-A seems to be way too little. But let me play devil’s advocate for a second. Say that the merchant does not take phone or mail orders and never prints sensitive info. Sure the web site could get hacked, but so could the customer’s PC or browser, and so could a 3rd-party DNS server that might come into play with getting to the payment service provider. None of these latter things would be in-scope and yet all of them could have the same result as the merchant’s web server getting hacked. So why should PCI be any more concerned about the merchant’s web site that these other things?
If a merchant is using a redirect/iFrame and the code/script that invokes the redirect/iFrame gets tampered with and redirects or invokes a “bad” iFrame, who is the one that will be responsible? The bank? Nope. The merchant. So while PCI doesn’t require going beyond SAQ A, I think a company’s legal counsel would.
Hello,
Sorry to bring this up again, but when looking at the following document from Visa.
Click to access processing%20e-commerce%20payments%20guide-73-17337.pdf
On Page 5 you will notice the following line:
“PCI DSS applies to all merchants’ webservers, even if a webserver does not itself store, process or transmit cardholder data because the merchant’s webserver determines how cardholder data is processed and so can affect the security of the transaction.”
As I mentioned before, its madness to think a webserver with a redirect or iframe would be out of scope. Surely this backs that and therefore we need to include these webservers in scope of PCI? Granted they would not be Category 1 (As mentioned in the scoping document) but they would still be Category 2?
Please let me know your thoughts.
Thanks
But then go and read SAQ A. There is still “scope”, just greatly reduced.
idk though is it? depending on whats outputing the page that hosts the iframe im not sure it would change. Im admitedly new to pci but from the little ive put togeather about that and the bit i know about crosssite and dom modification… if site is using a cms where php is stored in database and or javascript is I cant see how scope would change because in the end the sql entries can poke at iframe if done right or poke at clients browser. The php plugin and web server are obviously as important… so what even shrinks in scope with the iframe?
Only way i see it geting smaller is if the merchant has no server side and few to no client side scripts. aka the only thing that isnt flat html is the iframe but this isnt a very practical or appealing compromise because people love clicky buttons… esp if they can submit their bitc…er ideas about things or just make a menu drop down, swat the red dot (sry thats cats)
err i guess u loose some stuff with the processing and or where the go b4 processing…
is the main site exempt from requireing tls in that senario? i would think not because then how do u trust the html indicating the iframes actions.
i guess i only see this shrinking scope if all interactivity is removed and at that point i have to ask if its really got much of a lead on a file watch system and dom manip of a div.
if im way off base its probably because i havent studied how pci defines scope in depth but if you care to elaborate im all eyes. This was more thought process out loud then trying to sound smart, looking for any specifics i missed or got wrong because im looking to learn.
At the end of the day, the smallest PCI scope any organization that accepts payment cards can have are the requirements in SAQ A. It gets no smaller than those requirements.
Hi PCI Guru! First time reader and love your blog. I am building a website with WordPress and using Woocommerce. For the payment method I am using authorize.net and it is an iframe into my website. I will be using all the security certificates needed but wondered about the hosting of this website. If you talk with Rackspace they said that I do not need PCI managed hosting that costs $4000/month on AWS. The hosting they recommended would be $400-900/month but is not the highest level of PCI hosting. How does hosting play into this iframe? How do small online stores afford this type of hosting?
If you are using a true iFrame that builds on the customer’s browser, then all you need to comply with are the requirements in SAQ A. That said, even though it is not required by PCI, I would highly recommend that you monitor the mechanism that launches the iFrame for changes as any change would likely be a potential hack. I would also recommend vulnerability scanning and patch often.
So at the minute, Using an iFrame to the payment provider on a self hosted website, classifies the hosting web server out of scope of PCI and you are only required to complete SAQ A?
Please tell me I am wrong as that is just pure madness. They used this example at PCI London and the speaker said it only takes 10 seconds to modify the redirect. From that point on wards I could never understand how and iFrame keeps the system out of scope as there are so many other risks that could effect this iFrame.
Those of us in the security business agree with you, but the Council wrote SAQ A otherwise because the hosting industry pushed for that opinion because that is how they sold their services to the unknowing clientele that bought their services. Anyone worth their salt in security knows that at a minimum you need to monitor the iFrame/redirect execution point for any change. Because at the end of the day, if an attacker modifies the iFrame/redirect point, it will be the merchant on the hook for that breach, not the iFrame/redirect provider. And until we see breaches for that occur, the Council is unlikely to change their opinion.
Forgenix didn’t do a good job obfuscating the code. Those URLs are clearly for SagePay.
Is this really considered a sophisticated attack? I could implement a similar attack that wouldn’t even require the customer to enter their details twice.
Sophisticated in that it required research on the part of the attacker.
Did it though? Forgenix says that prior research must have been needed to get the database credentials but I don’t see why. The way most web apps work is you establish a pool of database connections and then each request uses a connection out of that pool. If the attacker can execute their own code on the server then they have access to the db pool by default (and probably every credential the web app uses).
The only possibly sophisticated part is how they managed to modify files on the server but since Forgenix’s article is tagged with Magento it was probably due to the publicly known exploit mentioned in CVE-2016-4010.
All in all I imagine it’s your average drive by Arabic kids that normally stick to defacing sites.
As an article a few days ago pointed out, “sophisticated” is all in the eyes of the writer of the article.
So merchants shouldn’t let their web servers get hacked. Even if all cardholder data is supposedly being posted on another web site, they still have a duty to protect their own web servers.
Exactly. Out of scope is only for PCI compliance purposes, not security purposes.
Wait, where does the SAQ A-EP come in ? I thought web merchant were now being directed to do at least an A-EP… Even with redirect.
If the sensitive authentication/cardholder data (SAD/CHD) does not flow through their Web site as with a redirect or iFrame, they can comply only with the requirements in SAQ A. SAQ A-EP is for all other methods used for payment processing.
and one more comment – I also advice to do not add automatically web servers to PCI scope. there are known solutions on market which allow to descope web servers from PCI DSS scope even for eCommerce solutions …
Be careful with scope for eCommerce. The only true out of scope solution for eCommerce is the solution that is totally outsourced with no merchant operated Web site.
I do not agree with you . There are known solutions where merchant operate web servers but they are not (1) processing cardholder data and (2) cannot impact cardholder data security. As such they are considered as not in scope. In other words – even if you hack web servers you cannot steal cardholder data as other controls are in place which will prevent from that
But if they are the start of the payment process, i.e., their Web site directs you to the payment processor, then who do you blame when the merchant’s Web site directs you to a malicious payment page? They don’t process the data, but they sure caused the problem.
Merchant obviously is part of the process however it’s different discussion. I claimed below that in eCommerce world there are known solutions that web servers can be out of scope even when they generate payment or link to iframe page.
In “standard” approach web servers obviously are in scope however in some “non standard ” they can be easily excluded.
First, let us be absolutely clear. There is no solution that will ever totally put the merchant out of scope for PCI compliance. If a merchant accepts payment cards for payment, they are in scope for PCI compliance. Period. Given that fact, the absolute minimum of PCI requirements that any merchant can comply with are the requirements documented in SAQ A. In order to use SAQ A, the merchant must have totally outsourced their eCommerce and cannot have any other payment channels. If the merchant does not have their own Web site, then I would agree with your comment.
Where the discussion/argument comes from is over merchant Web sites that the merchant maintains that do a redirect or use an iFrame to process payments. A lot of us in the security profession argue that if that redirect or iFrame invocation method is tampered with, it is not the service provider that will be at fault. It is the merchant that will be at fault. However, under the PCI SSC’s current rules, that merchant Web site is viewed as out of scope and does not require the requisite security protections that other eCommerce Web sites require. Not that the merchant’s Web site necessarily needs all of the controls specified in SAQ A-EP, but definitely more than what is specified in SAQ A.
To be honest I’m not suprised to read that. SAQ A approach is bad by design. There is a multiple known methods to capture cardholder data by malicious individual (internal and external) . So my personal opinion is that for eCommerce market PCI SSC should review SAQ A approach and extend it – current approach is simply no longer valid.
Based on my experience I would add at least
-> req 2 – change of defaults
-> req 6 – patching (especially software components not systems), change control and SDLC
-> req 8 – password policy for system components and application components
-> req 10 – Logging especially admin activity (10.2.2)
-> req 11 – Vulnerability Scans, Pen Tests (esp external ones), FIM
Only my personal opinion, but as a QSA I have a problem to sign SAQ A for my clients. This is excellent examle when compliance is not equal security ..
REALLY… an iframe? They deserved to be fined
Sorry but should be fined for what ? And who ?
Alex is referring to the merchant.
If a Web server managed, maintained and controlled by a merchant initiates the payment processing by using a redirect or an iFrame and that invocation method is changed by an attacker to now invoke a malicious redirect/iFrame, that breach is the merchant’s fault, not the service provider’s fault. Therefore the merchant should be fined for their lack of security, not the service provider.
Exactly. This is why I tell my clients to do more than SAQ A if they really want to be secure. But I add monitoring of changes to the redirect/iFrame as well as admin access in requirement 10.