[grandalf]

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]

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]

> 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-...

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]

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]

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 :)

[Silhouette]

I understand that the payment services are PCI compliant. But on a literal reading of the actual PCI DSS 3 documentation, specifically who is covered by the new A-EP case, that doesn't appear to help unless the entire "shopping" part of the site is also hosted by a merchant or third party service that is PCI compliant.

Otherwise, the merchant still appears to come into scope, because at some point they must redirect their customer to the externally hosted payment pages or load the externally hosted checkout system from the merchant's site, one way or another.

So basically, it looks like anyone who has any sort of shopping site they run themselves (as opposed to hosting entirely on a third party marketplace site) but who uses Stripe, PayPal, a hosted card payment page offered by their bank, or literally any other third party card payment system, will fall into scope and be required to operate and audit the entire relevant part of their web site according to the PCI DSS 3 rules. But that is obviously far beyond the reasonable capabilities of most merchants who might find themselves in that position, either technically or commercially.

Edit: In short, when you wrote:

Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope.

I haven't yet found anything that says why such a site doesn't fall into scope now just like everyone else. Indeed, the new rules seem to be clearly aimed at such sites as I read them.

[grandalf]

You are correct, however if you read over the requirements, they are not all that crazy. If you have an e-commerce website that has all ports open stores credit cards in clear text, etc., then you will fail, but it's actually pretty easy for a shop with its own servers and network team (in-house or outsourced) to come up with a network diagram that satisfies the PCI DSS 3.0 SAQ requirements.

The issue is that Heroku, because of its lack of transparency about what is actually going on in its routing mesh, is not necessarily secure, and it's not possible to just download a list of relevant firewall rules, etc. (the way you could if you set up a site on Amazon VPC).

SAQ A has always required the merchant using his/her own servers to provide some documentation and do some security scanning, the new thing with SAQ A-EP is that it no longer allows for the loophole of using a PAAS and claiming that simply b/c it is not managed by the e-commerce shop that it is out of scope.