PCI Compliance Discussion

Adding reference to #2502109: Prevent Add/Update Card Functionality From User Tab with Stripe Checkout

Stripe have provided further information by email following their comment that I posted mentioned in the summary. They did mention that they've sent this information to other Drupal developers in the last few days.

The new PCI-DSS 3.0 standards support the use of an iframe or hosted payment to collect card details, while remaining eligible for the simplest form of compliance, the SAQ-A. However, even if you use an iframe or redirect to a hosted payment page, a breach of your systems could still enable a third party to harvest card data as it's being entered, since once an attacker has control of the HTML DOM they can replace your redirect or iframe with their own. For this reason, a solid approach to security of your entire application and systems is still good practice, in addition to the factors under the limited scope of PCI compliance.

The new version of Stripe.js complies with the updated PCI standards by performing all transmission of sensitive card data within an iframe served off of a stripe.com domain. By ensuring that transmission is handled in a Stripe controlled iFrame, a large subset of security and compatibility issues are taken care of. This iframe-based approach has been certified by our external PCI Qualified Security Assessor as conforming with the new PCI-DSS 3.0 standards as eligible for the SAQ-A, however we still recommend ensuring appropriate security practices are followed for the rest of your site and systems since, regardless of whatever checkout process you use, an attacker who gains control of the page linking to or hosting your checkout can still harvest cardholder data.

That version has been updated for everyone which means that as long as you're not using a local copy of Stripe.js your plugin would already rely on the updates we released in January. This means that if your plugin is using Stripe.js and never sends the card details to the server and as long as your users have an SSL certificate on their payment page(s) they would fall under SAQ-A and be PCI compliant directly from us.

We received a similar, though differently worded e-mail, form Stripe when we inquired about this.

Here's what we were told:

We found that the piece of the puzzle that was important to the QSAs was where the request for tokenization was initiated in the "direct post" situation. So we sought to make sure that actual tokenization requests are being made from a Stripe owned domain, since we meet all the requirements for compliance.

The mechanism is pretty simple, but browser compatibility, and the wild-west of third party javascript mean that we're rolling out our new stuff slowly and carefully. We take the credit card information that's put into the merchant site, message it to a hidden iframe on a Stripe domain, and then make the tokenization request from there. Then we send the response back up to the main page. The new rules allow for use of iframes or redirects for tokenization, so we now fall under those rules.

@aviindub what questions are you looking to get answered?

I don't have any more info from Stripe, but I found a reference to this doc (https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DS...) on the Braintree web site claiming the a similar feature (https://developers.braintreepayments.com/javascript+ruby/guides/hosted-f...).

Page 4 of the PCI DSS doc mention iframes and redirect keep you in SAQ A Scope.

I agree with @aviindub, I think what this means is, "Stripe Checkout is fully SAQ-A compliant because it lives in an iFrame hosted by Stripe, but Stripe.js is SAQ A-EP compliant on Drupal Commerce because the actual form fields are created within a Drupal Form API implementation, and whose POST action URL is back to Drupal itself." (This isn't just a Drupal thing, this is literally any Credit Card form that is generated by a page that isn't hosted by Stripe [or any other PCI Compliant payment services provider].)

The way I understand it, we'll never be SAQ-A compliant with Stripe.js usage, only SAQ A-EP, simply due to the fact that Drupal handles the submission of a form which includes credit card field when Stripe.js integration is used.

SAQ A-EP has been developed to differentiate between merchants that have partially outsourced management of their e-commerce transactions, and merchants that have completely outsourced all management of their e-commerce environment (SAQ A merchants).

As with SAQ A, SAQ A-EP merchants do not electronically store, process, or transmit any cardholder data on their systems or premises, but rely entirely on a third party(s) to handle these functions. All processing of cardholder data is outsourced to a PCI DSS validated third-party payment processor for both SAQ A and SAQ A-EP.

Prior to the release of SAQ A-EP, many e-commerce merchants with web sites that impacted the security of payment transactions may have felt they were eligible for SAQ A because their web server does not store, process, or transmit cardholder data. As a result, these web servers did not have sufficient security controls applied to them and have become common targets for attackers as a means to compromise cardholder data.

SAQ A-EP is intended to identify the controls needed to secure merchant web sites that control or manage the payment transaction, and reduce the likelihood a breach of the web site can be used to compromise cardholder data.

I do think the person at Stripe was missing the nuance of SAQ-A vs. A-EP. "Never transmitting the data to your server" is only one part of the equation; the other part is where the form fields are generated. If someone gained access to YOUR Drupal site, they could change the form action or other element on the Checkout page where user information is collected, thereby creating a man-in-the-middle type of attack. (I think they thought "A" and "A-EP" are the same thing, since they both have "A" in them.)

This actually seems pretty straightforward to me, the real problem is that the Stripe representative may have been misinterpreting the SAQ documentation. I will try to get someone at a bank who deals in PCI compliance to verify my hunch, and will post again if I glean anything.

I spoke with the PCI department at Wells Fargo and they basically copy-pasted what others have already posted, so I'm pretty sure this issue is nearing its conclusion. The real problem seems to be that Stripe uses "Stripe.js" interchangeably when talking about their Javascript File hosted on their servers (stripe.js), and their direct-post implementation Stripe.js.

Even on their "What about PCI v3" page they lay this out plainly but then muddy it up again:

If you’re using Checkout, we’ve got you covered with Stripe.js, so Checkout users will be largely unaffected by the upgrade. Since it already rests inside an iframe controlled by Stripe, you can continue to fill out SAQ A. Similarly, the CSP situation has not changed.

I've emailed Stripe to try and get them to clarify the documentation, because it is confusing and misleading.

Hi,

I have read PCI standards and according to the discussion here, it seems direct post should NOT be in SAQ-A. However, Stripe says on their web site that stripe.js have been modified (using iFrame) so that it meet the new security requirement and that make the drupal possibly eligible for SAQ-A.

On the web site of Stripe https://support.stripe.com/questions/what-about-pci-dss-3-1 <-- PCI version 3.1

The new version of Stripe.js meets these criteria by performing all transmission of sensitive cardholder data within an iframe served off of a stripe.com domain controlled by Stripe. This in turn allows our customers to continue to be eligible for SAQ-A (the older questionnaire).

To my understanding, if this module using Stripe as it should be (using stripe.js) for the payment form, this module could be at SAQ-A. Am I wrong?

I have not yet checked the detail implementation of this module. If this module have to be in SAQ A-EP, then which functionality for the payment process make it be. It is very likely that some webs do not need that part. May I know what it is and could that part become optional? Thanks.

Hi there,

As I mentioned, I'm pretty sure that the documentation on Stripe isn't 100% accurate. They use "Stripe.js" (the inline form method) interchangeably with the actual Javascript file "stripe.js". So your hunch is correct. Direct post is eligible to be SAQ A-EP compliant, not SAQ A.

According to the actual PCI documentation, any inline form that is created by a website other than a payment processor (which is the Stripe.js method, as opposed to the Stripe Checkout method) is automatically not qualified for SAQ A but may be eligible for SAQ A-EP. The reason is because, with many e-commerce sites including those created by Drupal Commerce, the payment forms are generated by YOUR site and not THEIRS, it is possible that those forms could be hijacked by a malicious user.

The only way your site would be SAQ A compliant is if you use the Checkout option, which in Stripe for Drupal Commerce, still has some issues to be worked out. But Stripe Checkout only uses a form that is provided by Stripe through an iFrame, meaning none of the forms are generated by Drupal, which in turn makes your site eligible for SAQ A.

Please see my above comments - especially #9 - as I have done a fairly thorough job of explaining where the problem is - mainly, the Stripe documentation being confusing.

I agree, though i have to admit I want to take them at face value. Regardless, I do think an separate effort to offer a SAQ A compliant version would be prudent. Attaining SAQ A-EP compliance is still a high hurdle, though obviously not as high as SAQ D, with close to 110 compliance points to meet in the self reporting form.

Hi, torgosPizza

Thank you for your clarification. I understand and agree with you. I also checked the detail implementation in the module today. The main reason is (for a site builder) to make sure/maintain Stripe.js is clean/correct is more complicated than just a link to a payment processor. Also, with checkout, the way of input sensitive info (drupal form) is NOT depends on the drupal site at all.

On the other hand, I just need to clarify one thing briefly (hope I am not silly about what I have read): We would like to do the PCI compliance to prevent loss of the company due to the security breach; therefore, there is no doubt that we must do the right process. We want to be under SAQ A because it cost much less. Some thing I am NOT clear is about how execute the SAQ or say PCI compliance.

In my mind right now, to be PCI compliance is execute the right SAQ. That is the merchant (drupal site) needs to finish required documents and create evidence (to ensure the ogranization/company to be prepared, evaluated, improved and trained to against security threats). Does the merchant need to have some kind of certification by a professional party (means more $$$) or JUST follow the process and provide the related documents to the related entities (such as bank, ...) according to the SAQ document?

I would really appreciate your brief clarification. Many thanks.

#13:

Regardless, I do think an separate effort to offer a SAQ A compliant version would be prudent.

The issue is that, if your payment form is being generated by Drupal Commerce - which it will be, unless you use Stripe Checkout integration - you will never be eligible for SAQ A. That's what the PCI documentation pretty much says in a nutshell.

#14:

Does the merchant need to have some kind of certification by a professional party (means more $$$) or JUST follow the process and provide the related documents to the related entities (such as bank, ...) according to the SAQ document?

In my experience you don't need to hire a 3rd party; if you use a major bank that has given you a merchant banking account they will most likely have a representative there who can guide you through the Questionnaire process. From my understanding and limited experience though there is no real "certification" and the only steps involved are filling out and submitting the questionnaire to your merchant's representative when and if they ask for it. We had Bank of America behind our merchant account and this is what they did when we were with them; with our new bank however I have yet to go through this process.

Hope this helps!

Hello torgosPizza,

Thank you very much for your sharing. It helps a lot.

hosais

For what it's worth, with version 1.1, as long as the integration type is checkout (which hosts the payment form in an iframe served from Stripe, not on the site), I believe that Commerce can be used as a solution only requiring SAQ A compliance.

It'd be great to get more opinions/advice on this because the project page doesn't even mention the option (it's new in 1.1, it seems). It works great, too! It should be made the default, I think!

@wizonesolution: You are correct! As I had mentioned in #12 and #15, using the Checkout integration is the only way to get SAQ A compliance; using stripe.js will only get you as far as SAQ A-EP. It breaks down like this regarding the checkout form - that is, the actual text field input where the card data is entered by the customer:

- Is the form created by the site? If so, it qualifies for SAQ A-EP.
- Is the form hosted offsite such as with Stripe Checkout (a popup widget served through an iframe), or a 3rd-party "Hosted Checkout Pages" (or forms)? That qualifies for SAQ A.

I'm 99.99999% confident that this is the answer. In fact after doing some research I even found out that Braintree is now offering Hosted Fields which sounds like an interesting mix of the best of both worlds, as it actually gets you SAQ A compliance while keeping the payment form "on your site" ¹. Might be worth checking out - and hopefully Stripe will add something like this to their toolbox.

I agree that having this clarified on the project page, while also mentioning new Checkout integration, will probably be very helpful for site merchants.

¹ Note that the form for Hosted Fields would not literally be on your site, it would just appear to be.

I appreciate this discussion, it helped me have confidence in using Stripe's "Checkout with Drupal Commerce and to understand these PCI compliance details more thoroughly.

Is Stripe.js not doing the same thing as Braintree's "hosted fields"?
That's what it sounds like according to https://support.stripe.com/questions/what-about-pci-dss-3-1 (which was linked to in comment #11). They explicitly say they reworked stripe.js so that people using it don't have to comply to SAQ A-EP:

The new version of Stripe.js meets these criteria by performing all transmission of sensitive cardholder data within an iframe served off of a stripe.com domain controlled by Stripe.

As acknowledged here, "transmission of data" is just part of the issue... but are not the other factors covered by the credit card data being served via the iframe? Maybe they just should have written that sentence better?

If Stripe.js falls under SAQ A-EP then it seems to me that:
- we're saying their Qualified Security Assessor is wrong and ill-advised them, or that..
- stripe.js is SAQ A-EP when implemented **in Drupal** because the Form API creates the credit card fields instead of allowing stripe.js to create them in an iFrame.

Back in #9 it was said that "this is not a Drupal thing" and that any credit card form that's not 100% outsourced is A-EP... but Stripe makes it sound like their stripe.js does outsource the card form 100%.

Could someone clarify that?

I don't understand the code well enough to suss this out myself, I'm just trying to reason around what's being said.
Thanks for all the discussion so far,
Alec

@ahillio: You know what, I think you're totally right.

Braintree has also updated their documentation to explain that these are "small, transparent iFrames that replace the sensitive credit card inputs in your checkout flow". This makes my own understanding even clearer, and I think negates what I had said previously about SAQ A-EP only being available if we are using the "stripe.js" method at Checkout.

That being said I'm satisfied that using stripe.js allows a site to be SAQ A compliant without having to resort to Checkout, which is excellent. Maybe we can finally put this issue to bed!

EDIT: Or not.

The way Braintree's transparent iFrames work is you need to modify your form's markup, replacing input fields with div tags instead. So we'll probably need to update Commerce Stripe to not use input fields for its forms in order to be SAQ-A compliant using stripe.js - I'll try to dig in a bit to see if that's the case. (Their documentation is somewhat lacking in a few areas.) I've also sent them an email for a clarification on this point.

Yeah, the thing with Stripe.js and SAQ A-EP seems to be visual as well. If the site appears to be providing payment forms, even if it technically doesn't, then it seems like they want you to use SAQ A-EP.

I noticed that I forgot to share a FAQ from the PCI Council itself that I managed to find a while ago and which made me feel confident using Stripe Checkout. It is the clearest answer I have seen:

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/W...

It does seem like if Stripe.js can somehow provide a solution that fully uses an iFrame to provide the entire payment form such that no data is posted from the merchant website to Stripe, then it could be SAQ A. Otherwise, A-EP. That has been my reading.

And FWIW, I've also read articles saying that Braintree's Hosted Fields would fall under A-EP -- unless they are replacing the <div> outright with an iFrame, I guess.

And FWIW, I've also read articles saying that Braintree's Hosted Fields would fall under A-EP -- unless they are replacing the <div> outright with an iFrame, I guess.

That's exactly what they require you to do before you can use Hosted Fields in an SAQ-A compliant scenario. (See my link above.) Removing the input fields so they are not generated "by your site" still appears to be a requirement in order to reach that level of compliance, so that's what Braintree's system requires. Then (I assume) the div tags are essentially taken over by their javascript which injects an iFrame containing input fields of their own.

This differs from what Commerce Stripe does, which is essentially nothing in the form of modifying our own site-generated form markup. I'm still waiting to hear back from them to see if that's a step one actually needs to take to become SAQ-A compliant.

Response from Stripe. It's literally the same form letter as what Adam Wood posted in #2 with a few additions based on comments I had about specific aspects of their system:

The PCI-DSS standards support the use of an iframe or hosted payment to collect card details, while remaining eligible for the simplest form of compliance, the SAQ-A.

The latest version of Stripe.js complies with the updated PCI standards by performing all transmission of sensitive card data within an iframe served off of a stripe.com domain. There is no need to adjust markup on your part.

By ensuring that transmission is handled in a Stripe controlled iFrame, a large subset of security and compatibility issues are taken care of. This iframe-based approach has been certified by our external PCI Qualified Security Assessor as conforming with the PCI-DSS standards as eligible for the SAQ-A, however we still recommend ensuring appropriate security practices are followed for the rest of your site and systems since.

As far as practices on your side do not give name attributes to the payment details form elements! This prevents that data from touching your server, which means you do not need to worry about redacting logs, encrypting cardholder details, or other burdens of PCI compliance.

Stripe does not replace the individual input elements themselves with iframes, however Stripe.js performs all transmission of sensitive card data via an iframe appended to the page.

The bottom line is that our external PCI QSA has certified our Stripe.js solution as conforming with the PCI standards and as eligible for SAQ-A.

As always, we continue to work with our auditors to meet the needs of our users and evolving PCI standards.

I guess this does clear things up. With Hosted Fields from Braintree, they have you change the markup to regular div instead of input fields, whereas Stripe does not have this requirement. That's the part that still concerns me, since the PCI documentation does make mention of the fields themselves being key; I would love to get an unbiased opinion from a 3rd party, but so far this is the best I can do. If I can get some additional color like that from someone who is not actually paid by Stripe I'll post that here.

@torgosPizza thanks so much for continuing to investigate this!

@torgosPizza: From a rickmanelius blog post:

Hi wizonesolutions. Briefly, if the form itself is within the iframe, that is what provides the boundary that prevents an on-page keylogger in the parent DOM from accessing credit card data. The best way to verify this for yourself is to inspect the form elements to prove that it's within the iframe.

I'm pretty sure Stripe.js does not enclose the form within an iFrame, correct? But Stripe Checkout does.

@wizonesolutions: Right, exactly. Stripe's response was basically "We 'transfer all data' through an iFrame that is appended to the end of the JS file." I still don't quite understand how that gets you anything more than SAQ A-EP but there you go.

With Hosted Fields from Braintree, they have you change the markup to regular div instead of input fields, whereas Stripe does not have this requirement.

Yes, this is what makes me concerned, too. It's mostly for technical reasons. Leaving serious hacking aside (phishing sites etc.), let's take a look at standard Javascript & iframe security as implemented by well-behaved browsers.

In case of Braintree, if the input elements are created inside iframes which are being created by Braintree.js, then there is no way for any Javascript code originating from your web domain to access the values in the input elements (unless the iframe itself implements a backdoor - JSONP, iframe proxying - which gives access to its contents from the domain of your website, and I'm somewhat sure that Braintree iframe does not do that because that would defeat the purpose).

I don't have experience with Stripe's Direct-Post, but if I understand it correctly, it is using input elements created by *your* website (Drupal or whatever) and then sends the values through iframes. But technically it means that the input values entered by the end-user are available to Javascript code (at least for some time period) on your website and you can harvest them without user's consent! This is what makes me highly doubt SAQ A compliance of Stripe's Direct-Post solution.

But PCI specification has an ambiguity. Quoting:

If any element of a payment page delivered to consumers’ browsers originates from the merchant’s website, SAQ A does not apply; however, SAQ A-EP may be applicable.

What do they mean by "any element"? This could be interpreted as not only "input element", but also as labels, icons etc., which means that Braintree's solution with Hosted fields might also be out of SAQ A. Even worse - why "payment page" and not just "payment form"? This makes it impossible even embedding iframe into your custom payment page because, well, that's still a page coming from your server.

And, of course, the following quotes also lead to ambiguity:

Examples of e-commerce implementations addressed by SAQ A-EP include:
- Merchant website creates the payment form, and the payment data is delivered directly from
the consumer browser to the payment processor (often referred to as “Direct Post”).
- Merchant website loads or delivers script that runs in consumers’ browsers (for example,
JavaScript) and provides functionality that supports creation of the payment page and/or how
the data is transmitted to the payment processor.

PCI specification does not say that if their SAQ A-EP examples are modified to send data through iframes, they suddenly become SAQ A compliant. Even in Braintree's Hosted Fields there is still that Javascript running and creating the iframes inside the form and managing how the data is transmitted to the payment processor.

What's worse - even if the full iframe with all inputs originating from the payment processor is created by a Javascript code on a merchant's website, this is still ambiguous.

So, which approach does count for "Merchant website creates the payment form" and which does not? Confusing and prone to interpretations. PCI specification should be more specific about it.

I'd say, that currently the only way covered by SAQ A is the good old iframe (and the best way to create it directly in HTML without involving any Javascript) with all form fields, labels and icons coming from fully PCI DSS 3.2 compliant payment processor. Yeah, this is so old-fashioned, but considering all those PCI documentation ambiguities, this is the safest way.

I'm not sure why this popped up as "new" but I suppose it's time to close this out.

From what I understand:

Stripe claims that they do transfer all sensitive information via an iFrame in Stripe.JS, which allows for SAQ-A. However, I don't know how that's possible, since Drupal is (in this case) the creator of the credit card form fields, which automatically relegates us to SAQ A-EP according to the PCI DSS v.3 spec. For true SAQ-A support I would recommend using our module's Stripe Checkout integration, which provides a pop-up widget that is hosted by Stripe. That allows shop owners to have the highest security without requiring users to leave the site.

Ideally, Stripe will introduce something similar to Braintree's Hosted Fields solution, which essentially replaces card form fields with iFrames styled to look like fields, resulting in a truly SAQ-A compliant credit card form.

In this case, though, I would say we can definitely guarantee SAQ A-EP with Commerce Stripe by default, but it is possible to achieve SAQ-A with Checkout.

If anything changes or anyone has anything else to add, please feel free to create a new issue.

As this is linked from the module home page, it would be helpful to have a comment or link explaining what the D8 situation with this is.

#30: You may want to open a new issue for that as this one is closed.