Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 2 down vote favorite

Consider following situation:

  • We have location A where we have our online store.
  • We have location B where we have payment processing. Server is dedicated to do only payment processing jobs

We can ask for credit card details at server A, and send it via POST to server B - OR - We can ask for credit card details at server B using iframe, and send it via POST to same server - OR - redirect user to payment gateway B, then redirect user back to my site A

  • Server A fails vulnerabity test
  • Server B passes vulnerabity test

So basically B is our small payment gateway. And we don't store any card details at any time.

Is it PCI compilant?

share|improve this question
It isn't currently absolutely clear but my reading of the question is that in the first example, the HTML form is sent from A with an action parameter such that the POST goes directly from the user to B. In the second example, a page is sent from A that uses an <iframe> to pull the form from B, and then the POST goes directly from the user to B. Can you confirm or clarify this? – Ladadadada Mar 12 at 10:32
@Ladadadada yes <iframe src="site B"> where is card details form which sends data to itself – user21886 Mar 12 at 11:32
Can you confirm that I've described the first example correctly too? It would change the answer @JoeGatt gave a little. (Although I guess the answer will still be no.) – Ladadadada Mar 12 at 11:37
"Is it PCI Compliant" This could not possibly be answered, for obvious reasons. Perhaps what you mean is, can this feature comply with requirement X of PCI, depending on implementation. Or are you asking "does this system need to be PCI compliant". Or something else... Please clarify and focus your question. – AviD♦ Mar 12 at 14:32
@AviD i mean we want to use store A but server doesn't pass ASV tests, and we can't physically monitor server (which is also PCI requirement) so I was looking for some workaround. Moving whole store to dedicated server is much expensive. – user21886 Mar 14 at 11:08

3 Answers

up vote 1 down vote accepted

As far as PCI-DSS is concerned, any system which touches (not stores, not processes, but touches) or CAN TOUCH (ie, on the same network segment as a system that touches) must be PCI-DSS compliant. Server A is clearly touching PCI and would almost certainly need to be compliant.

By doing a tokenized redirect, you fix the problem because the user does not enter the PCI details on your site and your systems never handle the PCI data. All you send out is the details about what needs to be charged and then get back a token that is effectively the receipt for the payment. Since neither of these pieces of information is PCI and you have no direct physical network connection with the payment gateway, the storefront should not fall under PCI at the time of this writing(as far as I know, I am not a lawyer nor actively involved with PCI compliance at this time).

As for the case that you described about a keylogger compromising the security, PCI-DSS is a data security standard for protecting PCI on the server/vendor side. A client side exploit would be a compromised client and is on the customer's end, thus it is outside the scope of PCI-DSS. This is why if the user gets a virus from you prior to redirect, it does not compromise PayPal's PCI compliance as the virus came from a non-covered system and is on the client side. It isn't a compromise of PayPal, just a compromise of a random site that doesn't need to be PCI compliant leading to a compromised client machine.

share|improve this answer
Now that I read your answer, I realized that I didn't phrase my comment correctly. – Adnan Mar 12 at 13:23
This is great, thank you. Tokenized redirect is exactly what I am going to do. – user21886 Mar 12 at 14:48
@user21886 - just to clarify, if you are using your own payment processing server, it requires more than just vulnerability testing to be PCI-DSS compliant and the full scope of such compliance is beyond the scope of this Q/A. If you are not redirecting to a third party provider to handle all the PCI, I suggest that you hire a local PCI-DSS expert to review your payment processing system. – AJ Henderson Mar 12 at 15:13
As far i concern we need pentest/vul test perfomed by AVS, proper network and server configuration, we need to keep software up-todate and some things like education etc. and that really is. As long as we don't need to scan store website (where card details are not processed at any time) it's OK for me – user21886 Mar 12 at 15:29
up vote 2 down vote

As a former PCI QSA, my opinion is no. With the detail available, it appears that Server A would be considered part of your card holder environment since credit card transactions are transfered through it via the POST. In this situation, you would not be compliant with Requirement 6: Develop and maintain secure systems and applications, and Requirement 11: Regularly test security systems and processes.

share|improve this answer
1  
So how Paypal works? – user21886 Mar 12 at 11:43
And how about I redirect user to my payment gateway, then redirect back to my site? – user21886 Mar 12 at 11:50
PayPal is a separate entity. When you use PayPal, you are redirecting to their website where the transaction takes place. So if you were to implement PayPal, you could preclude your organization from the majority of PCI DSS requirements. – Joe Gatt Mar 12 at 13:24
up vote 2 down vote

No, it's not PCI compliant.

Why? Because "A" is the part of the card holder information processing chain. In this case, "A" is an essential part of your IP-based POS.

- In the first case: Breaking PCI-DDS 6.5 (specifically 6.5.7) [Page 42]

We can ask for credit card details at server A, and send it via POST to server B

This is straight forward, "A" compromised = card holder information compromised. An attacker can inject malicious code (most commonly JavaScript) in order to steal the card holder's information.

- In the second case: Breaking PCI-DDS 6 [Page 38]

We can ask for credit card details at server B using iframe, and send it via POST to same server

Fortunately, thanks to the Same-Origin Policy, the attacker cannot access the contents of the iFrame served by "B" using scripts on a page served by "A" (I'm assuming you have them on two different domains).

But, if the attacker has access to "A" then he's able to use Java or Flash exploits to install maleware/keylogger on the client's machine leading to the compromise of the card holder's information. Another possibility is tricking the user to voluntarily install some malware disguising as a required/recommended plugin or "bank security software".

share|improve this answer
1  
So basically if I put paypal on my website it gonna breaks Paypal PCI compilance as well? As attacker can install Java/Flash exploits before I send user to paypal processor? – user21886 Mar 12 at 11:28
@user21886, if your website is vulnerable, then AFAIK, yes. With the help of a third-party (PanOptic) PayPal conducts Quarterly Security Scans to ensure the security of the merchants themselves. Please keep in mind that using PayPal would change the first case, because PayPal doesn't allow submitting card holder information through the merchant. (In some cases, they do, but it's a whole different story). – Adnan Mar 12 at 11:43
1  
But it breaks keylogger theory. Even with Paypal Express Checkout you are providing your card details. So attacker can install java exploit+keylogger, and he is still able to steal card details on paypal express checkout. – user21886 Mar 12 at 11:46
@user21886 Again, I'll quote myself. "PayPal conducts Quarterly Security Scans to ensure the security of the merchants themselves." In general, if your website is compromised and actively spreading malware to the visitors you'll eventually be blocked by Google and many browsers (Firefox, for example) and you'll most certainly be blocked by PayPal and prevented from processing Credit Cards through them. – Adnan Mar 12 at 11:50
@user21886, I didn't phrase my first comment correctly. What I meant by "if your website is vulnerable, then AFAIK, yes." is not that you would cause PayPal to break PCI compliance. I meant that you would break the PCI compliance. – Adnan Mar 12 at 13:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.