I’ve had three different people ask me this question over the last several months and so now I feel like it’s time to answer some of these technical questions. I think there are tons of ambiguities in PCI and I’d like to start hashing them out - and you all can be the judge an jury, if you like. So without further ado, here is the first question, in what might become a recurring blog post theme:
If you’re a merchant who simply iframes your payment gateway, and never collects any information, do you have to use SSL/TLS? The payment gateway’s page already does.
If you look at PCI, there is no strict guidance about this use case, even though it’s coming up pretty often, and really needs to be spelled out clearly. So for the purposes of PCI, I’d say, kinda, it’s a requirement. The two things that specifically mention it are:
- Verify that HTTPS appears as a part of the browser Universal Record Locator (URL).
- Verify that no cardholder data is required when HTTPS does not appear in the URL.
This may not seem all that ambigious at first blush but really, there are tons of issues with these two sentences. Firstly, HTTPS very rarely appears anywhere. I think what they meant to type was https (lowercase). Next it doesn’t specify WHERE it has to appear, just that it is “part” of the URL, so http://www.whatever.com/HTTPS/… is fine. Next, in both bullets it doesn’t specify which URL they’re talking about (the one that’s in your browser or the one that’s being requested). And in the last bullet it doesn’t say that the information can’t be reflected back in a HTTP session, it just says that PII can’t be required of a user. All of these things are ambiguities.
With the increase in use of mashups and widgets there’s going to be more and more websites out there that iframe in some payment gateway or a backend “secure” website that takes in credentials. The problem is there is no way for a user to tell if the site is using SSL/TLS or not since it’s a child frame. The main reason you use SSL/TLS in the first place is to prevent man in the middle attacks from sniffing and modifying the content on the wire. If the attacker can modify the content, they can modify the iframe to point to an unsecure domain (one that they potentially own).