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 a 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.