Keeping a WooCommerce webshop up to date and secure
ACME starts as a webshop built on WordPress and WooCommerce, with about thirty plugins. Most attacks on shops like this use known weaknesses in plugins that were not updated, or stolen administrator passwords. This chapter tells how ACME's shop was broken into through an old plugin in 2020, and what a small shop does to prevent it: few plugins kept up to date, protected administrator accounts, card payments left to the payment provider, and backups that have been tested.
- Keeping a WooCommerce webshop up to date and secure (you are here)
- Deploying through a CI pipeline instead of by hand TBA
- Handling passwords, keys and other secrets TBA
- Code review as a security control TBA
- Code your product uses but your team did not write: libraries, licences and the SBOM TBA
- Shipping only what the product needs to run (container images) TBA
- Access to the production systems (Kubernetes) TBA
- Delivering software that customers run on their own servers TBA
- Updates and support periods for software on customer sites TBA
- Receiving and handling vulnerability reports TBA
- Supplier security requirements from an industrial customer in 2020 TBA
ACME in 2020: three people, a WordPress webshop with WooCommerce and about thirty plugins on one rented server, selling smart plugs and meters to households. Card payments happen on the payment provider's page.
Plugins, updates and backups
- Plugin
- Code from another company that adds a feature to the shop, such as a contact form or a file manager. It runs inside the shop with the same rights as the shop.
- Update
- A new version of WordPress, a plugin or a theme. Many updates fix weaknesses that are already public, so attackers know about them as well.
- Staging site
- A private copy of the shop where updates are tried before they reach the real one.
- Backup
- A copy of the shop's files and database, kept somewhere other than the shop's server, that can be restored.
- Multi-factor sign-in
- Signing in with a password plus a second proof, such as a code from an app on the phone.
The incident in September 2020
In 2019 Andrew installed File Manager, a popular plugin, to edit the shop's files from the browser. He used it twice and forgot about it. At the start of September 2020 attackers began exploiting a flaw in File Manager versions before 6.9, which let anyone upload and run their own code on a site without signing in (CVE-2020-25213). The plugin had about 700,000 installations, and attackers were using the flaw before most sites had installed the fixed version.
On ACME's server, the attacker uploaded a small program that gave them control of the shop. They copied the customer table and changed the checkout so that some customers were sent to a fake payment page that looked like the real one.
Each level saw something different:
- Customers noticed first. Two of them emailed support that the payment page looked different, and a week later one reported a card payment they had not made. A review that mentioned the fake page stayed online for months.
- Michael, the CEO, took the shop offline for a day and told the payment provider. He also decided to write to every customer whose data was in the database, and the notice to the data protection authority had to go out within 72 hours of finding the breach, where feasible.
- In operations, the only backups were on the same server, so nobody could trust them. Andrew rebuilt the shop on a new server from a clean copy of WordPress, restored the database after checking it, and changed every password and key.
- In engineering, the uploaded program sat in a folder where nobody looked. A comparison of the files with the checksums that WordPress publishes found the changed checkout file in minutes, a check that could have run on the first day.
Changes after the incident
Most of the changes cost little, and together they close the path the attacker used:
- Fewer plugins, each with a named owner. Unused plugins are deleted, because an inactive plugin's files are still on the server and some flaws can be reached through them directly.
- Updates every week, first on the staging site and then on the live shop, after a backup. A fix for a flaw that is already being exploited goes in the same day.
- A feed of plugin weaknesses, so that the owner hears about a flaw on the day it becomes public.
- Personal administrator accounts with multi-factor sign-in, and the file editor inside WordPress switched off.
- Card payments stay on the payment provider's page. The payment provider's short self-assessment form for shops like this (PCI DSS SAQ A) also asks the shop to confirm that scripts on its own site cannot be used to attack the payment page, so the shop's own security counts too.
- Backups kept away from the server and restored once a month on the staging site, to prove that they work.
- A weekly comparison of the shop's files with the published checksums.
Who reads these records
| Reader | What they ask for | What answers it |
|---|---|---|
| Payment provider | That card data never touches the shop, and that the shop's own site cannot be used to attack the payment page | The hosted payment page setup, the update log and the file checks |
| GDPR, the data protection authority | Security of processing, and the notice of a breach within 72 hours where feasible | The breach record, the notice sent and the changes made afterwards |
| Customers | That their data is safe, and that they hear about it when it is not | The privacy notice, and the letter they received |
| Later business customers | How updates and administrator access are handled | The update log and the list of administrator accounts (chapter 3.1) |
Cost
These are estimates. Depending on the company and how it operates, the real numbers can be higher or lower.
- Setting up
- One to two days for the staging site, the backups away from the server and multi-factor sign-in.
- Each week
- One to two hours for the updates and the file check, plus the restore test once a month.
- Skill
- Someone who runs WordPress sites and knows the shop's plugins.
- Money
- A few euros a month for the staging site and the backup storage. Several feeds of plugin weaknesses have a free tier.
- Too early
- None of this is too early for a shop that takes orders.
Keeping all of this under control also takes attention, beyond the hours. It can break the concentration needed for product work or for leading new business, and in a small company the same person often does both.
Limits
This chapter covers a shop on WordPress and WooCommerce. A hosted shop platform takes over the updates and part of the risk, under its own contract. The payment provider's self-assessment rules change from time to time, so check the current form with the provider. The incident at ACME is made up, and the File Manager flaw it uses is real.