3 ms·

Though to be fair, if you've got an XSS vulnerability, you can also just change the URL of the off site payment page to a phishing site, which most people will

• jtheory 15y ago
  All of these things fall into the same boat, security-wise -- so by my interpretation, the PCI rules make sense here. If the attacker can insert their own code that says "hi there, we may have to close the site unless we can get some donations ASAP - please help!" followed by a form for CC data, that's that. It doesn't matter if they normally accept payments by redirecting to PayPal, or if they use an iFrame, or the Stripe JavaScript approach. It's all the same at that point, security-wise. So let this be Bucket A, for websites where CC info doesn't touch their servers -- this is their risk profile. If a site in Bucket A is compromised and it takes a month before the complaints add up and the host shuts them down, that's a month's worth of stolen credit cards (this is not "worst case", but let's assume the thieves aren't terribly patient and start selling card info soon after stealing it). Bucket B is for sites where the CC info DOES touch their servers. For them, CC data may be recorded on the server (intentionally into a data store, or even accidentally into log files of some kind). This is a different security risk. A site in this category could be compromised, and in half an hour 10 years worth of their credit card info could be stolen. To steal 10 years worth of CC data from a site in Bucket A is naturally much more difficult. If you've got to draw a line somewhere, that's a reasonable one.