4 ms·

I don't store process or transmit any cardholder data on my premises, but rely entirely on third party services to handle these functions. Lots of people on th

by andrewf 16y ago

I don't store process or transmit any cardholder data on my premises, but rely entirely on third party services to handle these functions. Lots of people on this forum seem to misread this one. If cardholder data is POSTed to your server, and then you send it on to a third party, then you're receiving and transmitting, and you've got to be in compliance.

tptacek 16y ago
I hope I was clear about this. You're right. Cardholder data is radioactive. It can't touch your servers. If it does, I have no sympathy for you: you're in for a lot of pain, some of it reasonable and a lot of it not. Don't touch credit card numbers. Not even to hot-potato it. If it touches you, it leaves a stain, and removing it will cost you high tens of thousands of dollars.
- tbrownaw 16y ago
  So, you need to pay tens of thousands of dollars in order to be a Reputable Business that doesn't disconcert your customers with a third-party checkout page. Got it.
  - modoc 16y ago
    Pretty much:( Usually lots of tens of thousands. Luckily PayPal and Google Checkout are getting more popular, but still, it just feels sort of ghetto, imho. The vast majority of small eCommerce sites out there are almost certain not PCI compliant, or at least not properly audited by an accredited 3rd party. It's sort of like speeding, but with bigger tickets. Most people do it, but it's risky.
lftl 16y ago
If cardholder data is POSTed to your server, and then you send it on to a third party, then you're receiving and transmitting, and you've got to be in compliance. Why isn't anyone offering a thin wrapper service that lets you host a payment form yourself (giving you complete control of the page), and then POST the result to the service which just forwards to one of the major processors? You get full control of the form, and your server never transmits CC data, so it's out of scope for PCI compliance.
- tptacek 16y ago
  Because then the form, which you host, has to comply with the same PCI rules that the processor complies with.
  - lftl 16y ago
    I probably didn't help in describing the idea clearly, but who do you mean by "which you host"? My thought process was that it would work like this: Merchant - Hosts a a payment form, but it POSTs to the service's server basically <form method="post" action="https ://someservice.com"> Service - Receives the POST and forwards it on to Auth.NET, Paypal Pro, or whoever the Merchant is using to process transactions. The user is redirected back to merchantwebsite.com with appropriate response data. Are you saying the merchant website would still need to be PCI compliant or just the Service's? I definitely understand that the service would have to be PCI compliant. But it seems like it'd be a valuable service for a number of small e-commerce providers to essentially outsource online PCI compliance with minimal downside. EDIT: While I haven't used them, my understanding is that Braintree offers pretty much exactly this service, except that they require that they provide your merchant account and act as your payment processor.
    - tptacek 16y ago
      While I can go for hours talking about the actual technical risks here, I'm less firm about how a PCI auditor is going to interpret any specific thing you do. We don't PCI audit; we find and fix vulnerabilities in software. Having said that: The technical risk of you hosting HTML that POST's via HTTPS somewhere else is that any input that influences any dynamic component of the page on which the form is hosted could alter the "action" attribute of the form to point somewhere else, without it even being detectable in the page source. You can say that about any chain of pages, including in-app page flows all the way through Google SERPs, but it's a particularly severe risk on the actual page that asks for the credit card number, since there are no macro-level cues a user has as to whether the page is valid or not. OWASP is making more noise about things like "insecure redirects" for, among other things, this exact scenario. Expect the "host the HTML FORM that asks for the credit card number and send it to the payment processor" technique to run afoul of PCI DSS any year now.

by andrewf 16y ago

tptacek 16y ago

I hope I was clear about this. You're right. Cardholder data is radioactive. It can't touch your servers. If it does, I have no sympathy for you: you're in for a lot of pain, some of it reasonable and a lot of it not. Don't touch credit card numbers. Not even to hot-potato it. If it touches you, it leaves a stain, and removing it will cost you high tens of thousands of dollars.

tbrownaw 16y ago
So, you need to pay tens of thousands of dollars in order to be a Reputable Business that doesn't disconcert your customers with a third-party checkout page. Got it.
- modoc 16y ago
  Pretty much:( Usually lots of tens of thousands. Luckily PayPal and Google Checkout are getting more popular, but still, it just feels sort of ghetto, imho. The vast majority of small eCommerce sites out there are almost certain not PCI compliant, or at least not properly audited by an accredited 3rd party. It's sort of like speeding, but with bigger tickets. Most people do it, but it's risky.

lftl 16y ago

If cardholder data is POSTed to your server, and then you send it on to a third party, then you're receiving and transmitting, and you've got to be in compliance. Why isn't anyone offering a thin wrapper service that lets you host a payment form yourself (giving you complete control of the page), and then POST the result to the service which just forwards to one of the major processors? You get full control of the form, and your server never transmits CC data, so it's out of scope for PCI compliance.

tptacek 16y ago
Because then the form, which you host, has to comply with the same PCI rules that the processor complies with.
- lftl 16y ago
  I probably didn't help in describing the idea clearly, but who do you mean by "which you host"? My thought process was that it would work like this: Merchant - Hosts a a payment form, but it POSTs to the service's server basically <form method="post" action="https ://someservice.com"> Service - Receives the POST and forwards it on to Auth.NET, Paypal Pro, or whoever the Merchant is using to process transactions. The user is redirected back to merchantwebsite.com with appropriate response data. Are you saying the merchant website would still need to be PCI compliant or just the Service's? I definitely understand that the service would have to be PCI compliant. But it seems like it'd be a valuable service for a number of small e-commerce providers to essentially outsource online PCI compliance with minimal downside. EDIT: While I haven't used them, my understanding is that Braintree offers pretty much exactly this service, except that they require that they provide your merchant account and act as your payment processor.
  - tptacek 16y ago
    While I can go for hours talking about the actual technical risks here, I'm less firm about how a PCI auditor is going to interpret any specific thing you do. We don't PCI audit; we find and fix vulnerabilities in software. Having said that: The technical risk of you hosting HTML that POST's via HTTPS somewhere else is that any input that influences any dynamic component of the page on which the form is hosted could alter the "action" attribute of the form to point somewhere else, without it even being detectable in the page source. You can say that about any chain of pages, including in-app page flows all the way through Google SERPs, but it's a particularly severe risk on the actual page that asks for the credit card number, since there are no macro-level cues a user has as to whether the page is valid or not. OWASP is making more noise about things like "insecure redirects" for, among other things, this exact scenario. Expect the "host the HTML FORM that asks for the credit card number and send it to the payment processor" technique to run afoul of PCI DSS any year now.