Hanna Andersson’s SF Commerce Cloud Site Hacked: The UV Take

February 14, 2020

Building a high-security ecommerce site is hard, very hard. But building an ecommerce site that is so bulletproof that it is never once infected by a virus or other sort of malicious hack attack? Now that is impossible.

This is why, while Hanna Andersson’s site, which runs Salesforce Commerce Cloud (Demandware), and UV has no relation to this client, has been getting some press for having been hacked between September and November 2019 — indubitably driven by the lawsuit that followed from Bernadette Barnes’ credit card information having been stolen after a $119 purchase on the site, among others — there are a few points about this event that are important to articulate that we haven’t yet seen mentioned in the media. These have compelled our team to pen this article.

The first point is possibly the most important: we feel for you, Team Hanna Andersson. Even if the site was built by a competitor of ours, this is not the time to mock them but to empathize with them. UV’s websites and work have been astoundingly lucky in the face of the constant threat of attackers and hackers, but our day will come. It is a statistical inevitability. And do unto others as you would have them do unto you is ancient, received wisdom always worth remembering.

The second point is that, having analyzed the cause of the attack, it is clear that it is not a problem nor hole in Salesforce Commerce Cloud itself. As a company that lives and breathes Salesforce Commerce Cloud, we felt compelled to investigate it, to be sure that our preferred platform was as safe as we have thought. Trust, but verify — and we trust Salesforce Commerce Cloud, but constantly verify that our trust is worth it. Our review of the causes has led us to verify that the problem wasn’t with Salesforce Commerce Cloud but rather with how the developers developed on top of it.

Which brings me to our third point: the developers made a mistake. They are, after all, human — believe it or not. This hack attack was a classic case of cross-site scripting, one of the most common ways in which sites are hacked. And as the Commerce Cloud documentation makes clear, “XSS” (that’s the common developer abbreviation of cross-site scripting) is prevented by default on SFCC, except there is a flag in which you can disable the protection if you need to for some reason — such as if it creates an incompatibility with another part of the code. And those situations sometimes happen:

It seems overwhelmingly likely, to the point where we would bet our farm on it (well, at least I would bet my non-existent farm on it) that they just forgot to include this line and, as such, left a door wide open for the attackers. A bit like leaving your front door wide open for weeks on end to your luxury mansion that’s right next to the city shantytown.

Fourth, and finally, United Virtualities, being a very security-conscious company, with a veteran team experienced in dealing with many forms of attacks and hacks — to use today’s rhyme — has a security checklist that we insist on always implementing on each client project. We do our classic XSS-prevention codes and check to make sure they’re there. We do third-party site scans to try to expose any holes. We use various cartridges and add-ons specifically to strengthen the security of our sites, like Wordfence for WordPress, for example.

Based on all of this, there are a few conclusions. One is that paranoia pays off: perhaps there is wisdom in Woody Allen’s joke that, “Just because I’m paranoid doesn’t mean they’re not after me.” Another is that we must remember that publicity doesn’t just happen, it’s paid for: yes, the site was hacked, but why is it that so many publications are wanting everyone to talk about it now? And the final lesson is the importance of investigating when others make mistakes — even those not directly relevant to your work at hand, but more broadly to the platforms and systems you’re dependent on. You’re only as strong as the platform you’re on.