PCI Compliance and Ajax

Question

I have this idea, but I am unsure if it is PCI compliant. I'm new to the arena of PCI compliance and am curious to know if this scenario violates PCI.

So, let's set up the scenario. Company A is PCI compliant and has a web service on https exposing bits of functionality around payment processing. Company B is not compliant, but their website is secure.

Here are the steps of the scenario.

1. B's website contacts A's webservice via server side code. This service sends back an encrypted authetication token.
2. B injects this token into a page containing a form for accepting credit card information.
3. The user enters their credit card information on B's website.
4. The form information, along with the token, are sent via an ajax call to A's webservice.
5. A's webservice processes the data and spits back a status (Approved/Denied/etc)

The question is, since the javascript goes directly from the user's machine to Company A's compliant servers, is it PCI compliant? I'm very interested to know what experts in this arena think.

Joliejoliet

What is PCI exactly? I'm guessing it's some sort of certification, and not the bus ;) – Osanna

@Ranieri PCI - payment card industry I believe, as in the PCI:DSS, Payment Card Industry Data Security Standards. – Adulthood

Payment Card Industry compliance - it is a compliance standard around accepting and storing credit card information. pcisecuritystandards.org – Joliejoliet

Josh, I would suggest not relying on the answers here. I had to implement PCI compliant tech before, and 90% of the build time was devoted to Lawyers. Get advice that will remove your liability. – Flavorous

@Joliejoliet - Oh, I plan on it, but before I spend time proofing something out I'd like to get an idea as to if I'm way off base or not. – Joliejoliet

@Joliejoliet Just a quick check - the JavaScript for the post to Company A is coming from Company A, otherwise JavaScript domain restrictions will apply. Or am I missing an iframe cross-domain trick? – Release

@Joliejoliet It's a gray area I believe. With PCI, your card info is not stored anywhere, not even sessions, and sent to another process for authorization, etc. You receive back the results, much like you describe above. If you look at how Paypal does it, it's a similar process. As long as you clear the CC data from your javascript variables immediately after it's sent, you're all good. – Varga

@Release - we were going to look at using jsonp to go cross-domain, but just to be safe, Company A will be hosting the script, but it is served up on Company B's website. – Joliejoliet

@Josh, I think cross domain restrictions still apply. It's the domain the code is running at, not where the code comes from that determines these things. Otherwise, googleapi jquery for instance would not be able to do XHR to the server clients are on. – Flavorous

So.... now that we are a few years in the future... what was the end result? – Henrie

@Henrie - We have developed PCI implementations that allow credit card data to pass via ajax using jsonp as well as a method for using an http post to send the data from the form to only our server. The problem with the jsonp implementation is the requirement of javascript, which can (and did) have problems if you weren't forcing people to have javascript enabled. However, performing an http post directly has fewer problems, but requires some creative development if you want to get a response that you can process without moving the user forward to a separate page. – Joliejoliet

Interesting, thanks... and the ajax / jsonp bit is kosher with the PCI-DSS powers that be? – Henrie

I think it is. I've actually never had a client use the jsonp service, even though I was told to set it up. My problem with jsonp is that you have to embed all of the data in the querystring - which according to what I've read, the qs becomes part of the encrypted payload when using https. BUT, you cannot store credit card numbers on the web server due to PCI compliance, so you have to make sure that the querystring is not saved in your server logs. It is compliant that we can tell, but paranoid me is worried that QS will be saved somewhere. Luckily no one uses it. – Joliejoliet

Answer 1

Pamphlet on PCI DSS All of the PCI Standards

PCI DSS (Payment Card Industry Data Security Standard) has the concept of "Scoping" -- determining which systems come under the PCI umbrella.

Are you a Merchant or a Software Vendor? If the PAN (Primary Account Number), the long credit card number, is never sent to your website, then your website is usually not under the PCI Scope. -- Assuming that you're the merchant. If you're a software vendor, then your software would probably be in the scope of the PA-DSS (see below).

PAN transiting your server The old idea was that the PAN would be sent to your website (through a browser form submission), then your website would turn around and send it to a payment gateway (eg Authorize.Net). In this scenario, the PAN was never stored on your server, but did transit your server. This used to mean that your merchant systems would not be under PCI DSS scope since they never stored the PAN. But those days are ending quickly or are already gone. (Which depends on how aggressive your acquirer/Merchant Account supplier is about PCI.)

Controlling your web page Since your web page doesn't transmit any PAN to your server, you're not in the PCI scope. But how do you know that someone hasn't changed your webpage to transmit the PAN back to your server (or elsewhere, using JSONP techniques)? The answer is that you need to assure yourself that no one will tamper with your payment forms page.

How you assure yourself of this is up to you. You could use the PCI techniques or other techniques. This is a matter of your internal computer security and auditing.

Payment Application Data Security Standard (PA-DSS) If you sell your sw to merchants then it would probably be within the scope of the PA-DSS standard. See the standard.

PCI is political, not technical Remember that PCI scoping is up to you. If you're a big enough merchant, then you'll also need to work with a QSA (Qualified Security Assessor) who will review and ok your PCI compliance and scoping plan.

It is certainly possible that a QSA could say that since you control your web page it needs to be under PCI since it could be corrupted by someone. But that would be a pushy argument. After all, you could then say that every web page of any internet merchant needs to be under PCI since any web page could be corrupted to ask people for a PAN and then do something bad with it. On the other hand, this is exactly the sort of argument that Visa is using to increase PCI scope for corporate franchisors. Article.

PCI certification is not an excuse Also note that the card associations reserve the right to kick you out if you have a break-in--even if you were PCI compliant. So you want to be sure that you're a much tougher target than anyone else on your block.

Added: More on Scoping As you can tell from the above, a key issue is which systems are in or out of PCI Scope. The PCI Council now has a Special Interest Group (SIG) examining this whole issue of what is in and what is out of PCI scope. And my guess is that they'll want the envelope to grow, not shrink.

Added: It's between you and your lawyer Your scenario has the start of the PAN processing done on your customers' browsers. The PAN never reaches your systems, not even for an instant. So my interpretation is that you're out of Merchant PCI DSS scope. But you're the one signing the PCI compliance statement which is a contract between you and your acquirer. So it is up to you and your lawyer to interpret the PCI DSS standard, not me.

Bottom line You should never ever store PAN data on your systems. You shouldn't even have it transit your systems. New Payment Gateway protocols from Authorize.Net and Braintree enable the no-transit technique. Depending on your volume of credit card transactions, PCI compliance varies from a self-administered checklist to a huge project.

For more PCI war-stories, check the StorefrontBacktalk blog and their PCI coverage.

Yawning

Answer 2

Larry K's answer is good. It is mostly a political/layer thing.

It seems that using an iframe for posting from B to A is an accepted solution, while using Ajax - with CORS or JSONP - is somewhat more questionable but still, at least for some big players, acceptable.

The Information Supplement: PCI DSS E-commerce Guidelines v2 seams to say that this solution (direct-post API) is OK but that you should take care to code safely (though PCI DSS does not prescribe anything concrete you would need to do) - see the section 3.4.3.1 Third-Party Embedded APIs with Direct Post and the related 3.4.3.4 Security Considerations for Shared-Management E-commerce Implementations, which reads:

Direct-post API Approach: With the direct-post API approach, the merchant is still responsible for the web page that is presented to the consumer, and the merchant hosts the fields on the payment page that accept the data—only the cardholder data is posted directly from the consumer to the service provider. Since the payment pages are hosted by the merchant, the payment pages are only as secure as the merchant’s web site, and a compromise of the merchant’s system could lead to a compromise of payment card data. ... Specifically, for all of the above scenarios, the merchant should monitor for any evidence that systems have changed and respond quickly to restore systems to a trusted state when unauthorized changes are detected. Merchants who adopt these shared-management outsourced models to minimize applicable PCI DSS requirements should be aware of the potential risks that are inherent to these types of system architecture. To minimize the chance of attack in these scenarios, merchants should apply extra due diligence to ensure the web application is developed securely and undergoes thorough penetration testing.

For example the Stripe payment gateway uses direct-post over JSONP since 2012 instead of the iframe approach they have used before.

On the other hand, WePay also provides a direct-post API but recommends iframe to get completely rid of PCI requirements [WP] (claiming that with the direct-post API "[..] you’re still required to be compliant with the Payment Card Industry Data Security Standards (PCI-DSS) and the Payment Application Data Security Standards (PA-DSS) whenever applicable." (without specifying what exactly "whenever applicable" means).

[WP] WePay link: https://www.wepay.com/developer/tutorial/tokenization

Kilar

Thanks for the complement and for the updated PCI info. – Yawning

Answer 3

I've recently gone through some PCI-compliance work for our servers, so this is right in front of me. The short answer is no.

PCI compliance requires that each step of the path through which the sensitive information passes meets PCI requirements in and of itself. Something can be secure but not compliant, as you noted regarding company B. Because you already stated that company B is not PCI-compliant, yet company B is collecting the credit card information via their own web site, then the entire process, logically is not compliant.

Whether a PCI-compliance service actually connects these dots and how they would certify it as passing or failing may be another matter.

Redeem

The sensitive data itself never reaches B's server. The form is hosted on their webpage, but the data itself is sent from the client machine directly to A's server. – Joliejoliet

Answer 4

Regardless of whether it "technically" meets PCI standards (or not), I would not put my trust in this way of doing things.

If the form is on a page within B's hostname, B has complete access to what is in the form fields. (B's server is capable of sending the user malicious JavaScript if it wants to.)

The safest way of doing it (in terms of protecting credit card numbers) is to put the form completely within the hostname of the payment processing service rather than on an untrusted hostname.

Hevesy

We currently do that through iframes, however some clients do not wish to use iframes or even send the user off to to our site. – Joliejoliet

Answer 5

Here is the PCI Website

Fundamentally, if you could possibly see the card number or any identifying information about the card, you will need to comply with pci requirements. I'm not sure that they are necessarily a legal document 'yet', but if you are found in violation, your ability to process, or be a part of a transaction process can be revoked. Further as a merchant you sign an agreement about your liability and opt-into a process where the credit card companies can fine you. All for the privilege of accepting credit cards.

For fun here is a (pdf) link to the 38 page 'Quick' Guide.

Perithecium

I understand what compliance is and what can happen if you are not compliant. I'm more interesting in knowing if the above scenario is compliant or not. – Joliejoliet

"Compliance" is a matter of opinion/agreement between you and your QSA. If you don't have a QSA, then it's up to you to decide if you're in compliance or not. Given a specific set of facts, reasonable people can come to different conclusions about DSS compliance. Your facts are on the borderline between in and out of scope for a merchant's system. – Yawning