How did the attackers get the JS onto the cart page? That's the interesting part to me that the article leaves out. They managed to break into a PCI-compliant website that presumably has significant defenses and auditing in place.
https://www.riskiq.com/blog/labs/magecart-british-airways-br...
It seems like we just don't have enough information to know how exactly the attackers got the JS onto the page. What it looks like, though, is that some machine serving static files for the website got compromised, and the attackers replaced an innocent file with one that had some custom javascript tacked onto the end, that skimmed the credit card numbers.
For what it's worth, PCI compliance doesn't really help you keep your webservers secure, or to keep people from breaking into your servers at all, it's more about the way you permanently store credit card numbers.
It could well have been included in a legitimate re-deploy if that was the case.
Of course, if you own the parent site you can replace the iFrame with anything you want.
Are we talking about a server intrustion where they modified the actual cart code, or something between Newegg and the payment servers? (Sorry this isn't my domain, I'm just curious)
As an aside, while it's certainly true that if one can compromise a web server (whether serving static HTML or generating dynamic HTML) then it's game over, the modern style of JavaScript-centric development greatly expands the attack surface. An attacker can compromise any of a number of different servers (e.g. analytics providers), via numerous means; moreover, he can serve dynamic malicious code, and quickly respond to changes the targeted site makes (his implant needs to survive for awhile, but his access can be revoked and folks can still be compromised).
Websites which served static pages and received credit-card information via simple forms would be far more secure than dynamic web apps stitched together from JavaScript served from multiple servers in countries across the globe, with data inserted into the DOM retrieved from multiple servers across the globe.
I contend that a more traditional, static architecture would tend to lead to better architectural isolation. As an example, if one needed to install server-side analytics software rather than simply injecting it into a page at runtime, then one would download and install it once: any compromise of the analytics provider after one had download it would be irrelevant. But with dynamic JavaScript, one's users download the analytics software with every single page load: a compromise instantly affects users.
Moreover, with traditional server-side software one tends to have reasonably-well defined protocols for interaction, rather than just saying, 'hey, I'll run all your code in the same process as everything else.' But with client-side JavaScript, any piece of code can see everything.
As an engineering community, we've adopted a style which has great costs as well as great benefits. My opinion is that we moved too quickly, and now we're feeling the pain. While a universal portable app framework is pretty awesome, JavaScript layered over a document system is probably not the best way to achieve that.
As I wrote years ago, JavaScript delenda est.
Also, developers and engineers at Newegg are probably changing lines of code every day. Which means, at any point in time someone could have accidentally introduced a vector that allowed the attackers to inject their code.
Auditing and security reviews only work if every line of code is tested, reviewed, and verified. However, that be extremely costly and slow, which isn't "good for business".
Maybe, we as consumers, engineers, managers, and executives should demand that code safety and security is prioritized over profit. I would rather have a secure website then a new redesign every two years.
Also, "profit" is the reward for doing things efficiently, it is not some kind of scoreboard for how much a company is ripping off consumers. NewEgg is in such a hyper-competitive & mature space with margins in the low single-digits on average. Incidents like this can absolutely tank them, especially this close to the holiday season.
E-commerce companies do not make money on security breaches, they lose it. Lots of it. I think you should be a little more open-minded to how businesses operate, that's all.