Paid Advertising
web application security lab

PCI Question of the Day

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… 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).

Users would have no idea that it has happened. Even seasoned experts who were just lazy and didn’t bother to read the source (assuming it wasn’t overly convoluted with obfuscated JavaScript), or watch the wire themselves might not know the difference. So while I’m not an ASV, QSA or any other TLA, it’s my opinion that the answer to the question is a resounding “yes”. Sorry mashups and widgets, it’s time to grow up and stop playing in the sandbox. The same thing goes with sites that submit via SSL/TLS but the page with the form on it is unencrypted. Bad idea. And yes, I think it should be specifically mentioned in PCI. Many more uncovered use cases to come, and feel free to send your own questions if you’d like my opinion.

12 Responses to “PCI Question of the Day”

  1. dzhkh Says:

    I get this question a lot too(I’m a QSA), and I answer it as follows:

    Technically, you’re not storing, transmitting, or processing credit cards, so PCI isn’t your problem. Yep, if someone owns the site forwarding the customer to the payment gateway, they can redirect the numbers somewhere else. And if the site embeds an iFrame, you’re right, it needs to be SSLed.

    It’s a bit of a loophole, but I generally make the recommendation that the merchant in question has
    1. A contract with the payment company saying they accept responsibility for the cards.

    2. That they meet the vulnerability assessment, patch management, some of the secure coding practices, and penetration testing requirements (including penetration testing for 6.6 — I never recommend WAFs) to be good ‘lil merchants.

    Also, as for the http://lol/HTTPS thing, that’s wrong. The QSAs job is to ensure the item in the “PCI DSS Requirement” column is met. The “Testing procedures” are recommendations/ways of doing this. Some times they make no sense for a given situation, or like this one, all situations.

  2. duryodhan Says:

    Reading this a browser feature me and my friends had discussed some time back came back to me …

    Every time you enter a password somewhere, the name of the site that the form is gonna post to will be made visible next to the password entry area (in a nice clean looking UI)*

    If it is in https - then the owner of the cert will be displayed…

    of course, again the user can make mistakes, but this should at least prevent reasonably competent people from making dumb mistakes. ..

  3. Wladimir Palant Says:

    Full ACK. Not too long ago I happened to be on a website that wanted my credit card number for a payment but didn’t even bother encrypting the connection. WTF??? I was already about to leave it when I realized that the credit card number is requested by a frame that was served over HTTPS (usually there is no easy way to see that, Adblock Plus helps here). I decided to accept it this one time but I am for sure never going back to that site. No, I don’t want to check every time I want to pay for something. And I cannot imagine regular users doing that.

  4. a Says:

    what does PCI actually mean? one can only guess….”protecting confidential information”?
    same goes for ASV, QSA, TLA

  5. muckpig Says:

    > @a

    PCI should actually be PCI DSS

    PCI = Payment Card Industry Data Security Standards
    URL =
    Latest version update = 1.2 (October 2008)

    ASV = Approved Scan Vendor
    QSA = Qualified Security Assessor
    TLA = Three Letter Acronym

    As a merchant im heavily involved with PCI DSS for my company and have spent the last 18 months or so investigating, reviewing & updating adequate measures to ensure my company is not at risk from Credit Card Misuses

    We do NOT hold, store, receive or handle ANY Credit Card Data, computerised or other (paper)
    - therefore having minimum risk

    Also as a level 4 merchant (only doing

  6. infosecsceptic Says:

    a. I’m wondering if you’re being serious or not. It’s probably a sarcastic comment, but in case it wasn’t (and for those reading that might not know), here is your answer:

    PCI stands for “Payment Card Industry”. It is the abbreviated form of PCI DSS (DSS = “Data Security Standard”).

    “PCI DSS is a worldwide security standard assembled by the Payment Card Industry Security Standards Council (PCI SSC). The PCI security standards are technical and operational requirements that were created to help organizations that process card payments prevent credit card fraud, hacking and various other security vulnerabilities and threats. The standards apply to all organizations that store, process or transmit cardholder data with guidance for software developers and manufacturers of applications and devices used in those transactions.”

    Google and wikipedia are your friends.

    There are a whole bunch of supporting TLA’s (Three Letter Acronyms) on the PCI DSS page that you can add to your list. :)

    One caveat about PCI DSS. Heartland was “compliant.” Go figure.

    As a former IT auditor and now security manager, it is disheartening to see how much these “point-in-time” certifications are relied on in industry. I guess it’s the illusion of security everyone is after. Blue Pill syndrome.

  7. GrrFace Says:


    PCI is the Payment Card Industry standard for protecting credit card data. It’s a series of rules laid out by a few of the major CC companies, designed to prevent more TJX type breaches. They classify vendors according to size, and then dish out penalties until they meet the PCI standards.

    As far as ASV, QSA, and TLA, ASV is an Approved Scanning Vendor (PCI companies have to have a monthly (or quarterly, I can’t ever remember) vulnerability scan run against their network externally.) QSA is a Qualified Security Assessor, essentially a PCI auditor. And TLA stands for Three Letter Acronym.

  8. David Kierznowski Says:

    Why bother with scanless PCI around, eh? ;)

    On a more serious note, I find PCI requirements terribly ambiguous but I think it is getting better.

  9. Rafal Los Says:

    Honestly, if you’re being asked this question then there is something fundamentally wrong with the spec. There is the *intent* of the PCI DSS, and then there is the *letter* of the PCI DSS. While I agree the standards document may need some clarification in wording, so that everyone down to a 5th grade level can comprehend it (and lawyers find it difficult to worm their company out of it)… at the end of the day the spirit of the regulation is this: PII/Private data in transit must be encrypted with stream-based encryption (ssl/tls)… I think that it’s rather obvious if you’re not trying to circumvent it.

    I feel the fact that you’re getting asked that question points to a much deeper underlying problem with the merchants, and a sad state of affairs in that camp, a la HPS, SRA, and many others.

  10. Eponymous Says:


    It ought to be a FF plugin called banhttp configurable to reject or even entirely erase input forms (using Greasemonkey etc) whenever the site it’s posting to is HTTP. Maybe it already exists. It should replace the input form with a .gif of Mr. Yuck, or a monkey’s ass.

  11. Tom T Hall Says:

    We used a tool called dotdefender - it helped us passing through the pci dss 6.6. Comparing this tool to other hardware solution - the dotdefender has his advantages over the hardware solution.


  12. Erik Says:

    Being a QSA myself I don’t agree with dzhkh.

    It doesn’t matter if you don’t store, process or transmits card data as long as you accept payments with payment cards you have to adhere to PCI DSS. You might not need to go through an on-site assessment. Instead you might be elgible to use on of the Self Assessment Questionnaires but you still fall under the requirements of PCI DSS.
    In the case discussed here (e-commerce) SAQ A would probably work if you have confirmed that your 3rd party service provider handling the card data is PCI DSS compliant. And you as a merchant must have policies and procedures maintained and implemented to manage service providers.