5 ms·

I think you're incorrect. An attacker could simply change the code on your server to make the form submit to a malicious location. The user would never know t

I think you're incorrect. An attacker could simply change the code on your server to make the form submit to a malicious location. The user would never know there was an attack going on. The entire point of SAQ A-EP is to cover the edge case that was letting people use offsite, iframe, and js checkouts. It puts the web server that is doing the hosting of the site in general into PCI scope.

Silhouette 12y ago
It puts the web server that is doing the hosting of the site in general into PCI scope. So essentially, every card payment service where the merchant's web site touches the payment flow beyond directly linking to an entire page hosted by a third party is dead? Because on a literal reading, I don't see how any of those services or the merchants using them can possibly be exempt from the new rules, and I don't see how it is going to be commercially viable for any small merchant using any of those services to comply. Say goodbye to Stripe and its various clones, Checkout or otherwise. Forget using any sort of A/B testing on your sign-up pages that isn't entirely self-hosted, or using any third party analytics to track visitors through the flow. Basically, you can use a fully hosted service provided by a major bank (and we all know how well those convert and how well the giant financial services firms typically treat small businesses) or you're out of luck. If that is really what the new rules are meant to say then this appears to be dumb on an EU VAT mess scale of dumb, with the added dumbness that since it's not actually a legal requirement to comply with PCI DSS, roughly 0% of merchants who should in theory be affected actually will. All it's going to do is reinforce the image of the card payment industry as a dinosaur and hasten its demise by destroying the best idea they've had in years: allowing small businesses to actually take card payments on-line without jumping through silly numbers of hoops.
- grandalf 12y ago
  > beyond directly linking to an entire page hosted by a third party No, including payment pages hosted by a third party: https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-e-commerce-merchants-using-payment-redirects/ https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-... The important thing to note is that it would not be very difficult for Heroku to allow websites to gain compliance. One should be able to type: $ heroku document:network and it should spit out a csv with ingress and egress ports, virtual server IPs, etc. That would cover half of the requirement from SAQ A-EP. The other half would easily be covered by publishing general policy documents about data center policies, etc., similar to what Amazon already publishes. Heroku can simply reference all the existing AWS service provider documentation and then add a few of its own documents covering the stuff it manages (things like password control policies, etc.) Also it would be helpful to allow the admin panel to require multi-factor auth. So it's not really all that absurd. For all we know Heroku has a few massively glaring security holes and as we type people are skimming lots of payment information... PCI is not a legal requirement, simply a moderate quality list of best practices. That Heroku and other PAAS vendors have trouble doing this should probably be cause for some actual concern.
  - Silhouette 12y ago
    If that summary is accurate then it's even worse -- not only are Stripe and friends dead, but so are all the "hosted" solutions offered by banks. You literally can't run a web site and take card payments without either (a) building the entire site using some sort of marketplace or other compliant service, or (b) complying with exactly the kind of onerous PCI DSS burden that all those hosted payment pages and services like Stripe were designed to avoid. As far as I can see, the only significant attack that this addresses is someone compromising your site and changing it to redirect to a malicious alternative instead of your real payment service. But since any fool can set up a site that looks the same, has a similar domain name, ranks about the same in Google, but is entirely fictitious and exists only to harvest cardholder data, and moreover following that strategy would be far easier than compromising a legitimate merchant's site in many cases, this is a poor attempt to mitigate a threat that is in practice impossible to avoid. If this is really all true then I'm pretty sure PCI DSS just became irrelevant to most small on-line businesses. There's no commercially reasonable way for them to comply with those terms. There's no legal threat if they don't (at least not in most places; YMMV) so we're purely talking about financial liability here. And from a financial point of view, you might as well just accept that if you get a breach and card data leaks then your business will go bankrupt paying the fines whatever you do, so you can ignore the whole thing anyway. The only other meaningful sanction the card services have is refusing to allow the same company representatives to take card payments at other companies in the future, but if they would do that for this reason then probably you were never going to work with them again anyway.
    - grandalf 12y ago
      You are missing the details. Stripe and similar services are themselves PCI compliant and have extensive documentation, audits, etc. Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope. PAAS vendors are one of the most likely attack vectors which is why they are in scope with SAQ A-EP. If you are seriously under the impression that you could easily set up silhouettesfakeamazon.com and start harvesting credit cards, I challenge you to try it :)
      - 12y ago

Silhouette 12y ago

It puts the web server that is doing the hosting of the site in general into PCI scope. So essentially, every card payment service where the merchant's web site touches the payment flow beyond directly linking to an entire page hosted by a third party is dead? Because on a literal reading, I don't see how any of those services or the merchants using them can possibly be exempt from the new rules, and I don't see how it is going to be commercially viable for any small merchant using any of those services to comply. Say goodbye to Stripe and its various clones, Checkout or otherwise. Forget using any sort of A/B testing on your sign-up pages that isn't entirely self-hosted, or using any third party analytics to track visitors through the flow. Basically, you can use a fully hosted service provided by a major bank (and we all know how well those convert and how well the giant financial services firms typically treat small businesses) or you're out of luck. If that is really what the new rules are meant to say then this appears to be dumb on an EU VAT mess scale of dumb, with the added dumbness that since it's not actually a legal requirement to comply with PCI DSS, roughly 0% of merchants who should in theory be affected actually will. All it's going to do is reinforce the image of the card payment industry as a dinosaur and hasten its demise by destroying the best idea they've had in years: allowing small businesses to actually take card payments on-line without jumping through silly numbers of hoops.

grandalf 12y ago
> beyond directly linking to an entire page hosted by a third party No, including payment pages hosted by a third party: https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-e-commerce-merchants-using-payment-redirects/ https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-... The important thing to note is that it would not be very difficult for Heroku to allow websites to gain compliance. One should be able to type: $ heroku document:network and it should spit out a csv with ingress and egress ports, virtual server IPs, etc. That would cover half of the requirement from SAQ A-EP. The other half would easily be covered by publishing general policy documents about data center policies, etc., similar to what Amazon already publishes. Heroku can simply reference all the existing AWS service provider documentation and then add a few of its own documents covering the stuff it manages (things like password control policies, etc.) Also it would be helpful to allow the admin panel to require multi-factor auth. So it's not really all that absurd. For all we know Heroku has a few massively glaring security holes and as we type people are skimming lots of payment information... PCI is not a legal requirement, simply a moderate quality list of best practices. That Heroku and other PAAS vendors have trouble doing this should probably be cause for some actual concern.
- Silhouette 12y ago
  If that summary is accurate then it's even worse -- not only are Stripe and friends dead, but so are all the "hosted" solutions offered by banks. You literally can't run a web site and take card payments without either (a) building the entire site using some sort of marketplace or other compliant service, or (b) complying with exactly the kind of onerous PCI DSS burden that all those hosted payment pages and services like Stripe were designed to avoid. As far as I can see, the only significant attack that this addresses is someone compromising your site and changing it to redirect to a malicious alternative instead of your real payment service. But since any fool can set up a site that looks the same, has a similar domain name, ranks about the same in Google, but is entirely fictitious and exists only to harvest cardholder data, and moreover following that strategy would be far easier than compromising a legitimate merchant's site in many cases, this is a poor attempt to mitigate a threat that is in practice impossible to avoid. If this is really all true then I'm pretty sure PCI DSS just became irrelevant to most small on-line businesses. There's no commercially reasonable way for them to comply with those terms. There's no legal threat if they don't (at least not in most places; YMMV) so we're purely talking about financial liability here. And from a financial point of view, you might as well just accept that if you get a breach and card data leaks then your business will go bankrupt paying the fines whatever you do, so you can ignore the whole thing anyway. The only other meaningful sanction the card services have is refusing to allow the same company representatives to take card payments at other companies in the future, but if they would do that for this reason then probably you were never going to work with them again anyway.
  - grandalf 12y ago
    You are missing the details. Stripe and similar services are themselves PCI compliant and have extensive documentation, audits, etc. Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope. PAAS vendors are one of the most likely attack vectors which is why they are in scope with SAQ A-EP. If you are seriously under the impression that you could easily set up silhouettesfakeamazon.com and start harvesting credit cards, I challenge you to try it :)
    - 12y ago