Cybersecurity often feels like another world, yet in recent years it’s a topic that I’ve become mildly obsessed with. As web and software developers, security is an integral part of what we do, but for the most part it is self-contained in terms of the code that we work on directly. That has to change.
Having done a deep dive into authentication and session management, cross-site scripting (XSS), encryption, injection and security configuration (still just a small subset of the broad field that is cybersecurity), I’ve attempted to boil what I’ve learned down to a few key points that when followed, should help to minimise the risk of your Craft site being compromised. The keyword here though is minimise. I believe that, given the current state of web servers and software, with enough incentive, time and budget, a seasoned hacker would be very capable of compromising a modern web server running modern software.
While one could argue that most of the data stored in a Craft site is intended to be public, there are situations in which you may be using Craft to store and manage personal user data and other sensitive information. If that is the case, and you do not have a tried and tested security policy in place, then be sure to read to the end.
Attack Mitigation #
When we talk about securing a Craft site, or any site for that matter, it is important to understand that we are talking about mitigating attacks. In other words, minimising the risk of being breached, reducing the damage that such a breach could have, and maximising the chances of detecting and being able to recover from such a breach, rather than preventing it altogether.
The most obvious piece of advice might be, don’t store any sensitive information on a server connected to the Internet. But what is sensitive is subjective and given the pervasineness of the web, not to mention the proliferation of the Internet of Things, a deeply worrying phenomenon from a security perspective in which everything from household devices to utilities is networked, security is no longer simply a matter of protecting our secrets, but of keeping our electricity, water and communications in working order.
In December 2020, Google suffered an authentication system outage that took down Gmail, Google Calendar, Google Docs, Google Meet and other services. The cause of the error was “the company’s internal tools failing to allocate enough storage space to the services that handle authentication”. So instead of making more storage available when it was full, the system just crashed. The outage also affected Google’s Smart Home services, including smart speakers, thermostats and smoke alarms, which fortunately were able to remain operational in fail-safe mode.
–The Guardian
We all rely on the services provided by Google, Amazon AWS, and other Tech Giants, so let’s not dwell too long on what we cannot change. Instead, let’s get into what steps you can take to secure your Craft sites today.
Run the Most Secure Version of Everything #
This one may sound obvious, if somewhat unrealistic. Obvious because we can all intellectually understand that running outdated, insecure versions of any software opens us up to the possibility of being hacked. Unrealistic because of the rate at which software is updated and a general lack of transparency when it comes to understanding the severity of updates and bug fixes. It is not unusual to witness vendors downplaying the gravity of their security fixes in the name of “protecting” their reputation, due to a vulnerability being considered “edge-case” and due to plain negligence.
Keeping software up to date is not hard, but it can be time-consuming and expensive, especially when you realise the extent of package dependencies and how dependency graphs work. Craft CMS, for example, currently has 46 dependencies listed in its composer.json file. Each of those dependencies may have one or more dependencies of its own, which results in a total of 127 PHP packages required in the composer.lock file (most of which will end up on your web server). Similarly, there are 815 JavaScript packages required in the main package-lock.json file that are used in the build process.
The very website that you are reading this on currently requires 153 PHP packages and 300 JavaScript packages for its (relatively lightweight) build process. And this begs the question, whose responsibility is it to keep all of these packages continually updated? And even with unlimited time and budget, would such a task even be possible? Given that version constraints are commonly used, restricting updates for compatibility reasons, the answer would appear to be no, it is not always possible to run the latest version of all software.
I urge you to look at Craft’s dependency graph, as well as that of your own site if you have it in a GitHub repository. While dependencies are not necessarily bad, it is important to keep in mind that each dependency is a potential back door for a vulnerability to be introduced.
Speaking of back doors, I recently heard freakyclown, a physical penetration tester whose job it is to break into buildings to test their security, tell a story of the time he was tasked with seeing if he could steal a bar of gold from a gold bullion vault in a bank. This is a B2B bank, so there is no lobby in which members of the public can freely enter, just security guards.
After some reconnaissance, he discovers that the front of the building had recently received a major security upgrade (hence the client’s confidence when giving him the assignment), but that the back of the building had not. He manages to bypass a restricted area to reach the back, and there he finds a service door that he is able to get through. Once inside, nobody gives him a second glance and he manages to walk right up to the vault. To his surprise, he finds it wide open. Apparently, during business hours they keep it open, as it needs to be accessed multiple times a day. So he grabs a bar, puts it in his backpack and leaves the way he came in.
He calls the client and asks them to meet him in the lobby so he can return what he has in his possession and go through the security issues with them.
Take the following thought experiment, to bring it closer to home. Say you run a cat photo site that you care deeply about. A dog lover comes along and, feeling jealous and having far too much time on their hands, decides to target your site with the malicious intent of defacing it.
Rather than targeting Craft or a plugin directly, they target a seemingly inconspicuous PHP dependency that provides string manipulation functionality. If the malicious actor was able to find and exploit a vulnerability in that package, or if they took a simpler path of becoming a maintainer of that package, then they could slip some malicious code into it, that if went unseen would find its way onto your web server. From there they could perform a privilege escalation attack and finally compromise your site… Oh, the Humanity!
The fact that pulling off something like this is not unfeasible and that your site will never be 100% secure is an inconvenient but inescapable truth. The sooner we come to terms with this, the better.
Something like this actually happened in 2018 with NPM, the Node package manager on which most build systems depend. Jarrod Overson reverse-engineered the attack and explained it in detail in his excellent technical presentation Analysis of an Exploited NPM Package. Interestingly, his last slide is as follows.
If, like this developer, you subscribe to the belief that “In Pixel & Tonic We Trust”, then you likely also assume that the very smart people at Pixel & Tonic do everything they can to keep Craft secure. You may also assume that every plugin developer does everything they can to ensure that their plugins are secure. But what about the dependencies — won’t somebody please think of the dependencies?
Listen to the Critical SEOmatic SSTI Vulnerability Post-Mortem devMode.fm podcast episode in which the SEOmatic plugin exploit is discussed.
Always Apply Critical Updates #
Before I tell you how bad things really could get, let me tell you what you can do right now to help keep the software running your site secure. The first thing is to always, always, apply “critical updates” immediately. Craft will tell you when a critical update to Craft itself or one of the installed plugins is available by displaying a big red banner at the top of every page in the control panel. This looks too similar to the warning about a licensing issue for my liking (shown below), and will only be visible to users who have permission to perform updates in the control panel.
Unfortunately, there is a good chance that you will not know about a critical update until you (or another privileged user) happen to log into the control panel and see this banner.
Critical Update Notifications #
To stay abreast of critical updates, some recommended options are to follow @craftcmsupdates, which tweets every time Craft is updated (except for very minor releases), to follow the critical Craft updates RSS feed (and the plugin update feeds at feeds.craftcms.com/plugin-handle.atom), or to install the Sherlock plugin.
The Sherlock plugin was developed shortly after the Panama Papers revelation, which I’ll come to later in this article. Initially built for our own use and then released into the Craft plugin store, Sherlock scans your Craft site for security issues and, possibly more importantly, monitors the results. If a security scan fails (you can and should schedule it to run daily) then you will be notified immediately by email. A critical update to Craft or a plugin that is installed on that particular site will force a scan to fail, so you will automatically be notified of this too.
Create an Update Strategy #
Updating Craft and plugins is not always simply a matter of clicking the big UPDATE button. In fact, this YOLO approach is likely to bite you in the behind eventually if you don’t have an update strategy in place. Your update strategy need not be complex, but it should be predictable and fail-safe.
For technical details of developing an update strategy, I refer you to Updating Craft CMS Without Headaches by nystudio107. The TLDR version is: update locally via the CLI. But I strongly recommend you read the entire article.
Enable Auto-Renewal of Licenses #
Whenever you buy a license of Craft or a Craft plugin, auto-renewals of licenses is disabled by default. To ensure that you or your client is eligible for updates after the first year, it is highly recommended to enable auto-renewals in your Craft ID account. This way there won’t be any nasty surprises when an update gets forgotten about or ignored after its update eligibility period.
License renewals are also an important source of income for plugin developers and incentivise them to release regular updates and provide better support.
Use Third-Party Security Tools #
There are countless third-party security tools to choose from that can help you monitor the security of your site. I can personally recommend the tools below, all of which offer free plans.
Dependabot was acquired by GitHub in 2019 and is now integrated into repositories by default. It can detect vulnerable dependencies and send you an alert if a known vulnerability is detected in the repository that contains your site. Vulnerabilities can be detected only if they have been added to the GitHub Advisory Database or the WhiteSource Vulnerability Database, so the effectiveness of this tool is questionable for vulnerabilities in Craft and plugins, which may or may not publish formal security advisories.
Continuous code quality tools such as SonarCloud check your site’s code for potential bugs, vulnerabilities and code smell. They can generally be integrated with GitHub repositories very easily and can provide useful insights into how to improve your code. The downside of such tools is that they sometimes report too much, resulting in information overload and ultimately in developers ignoring them.
Error monitoring tools such as Sentry can notify you of errors that occur on your site. Their user interfaces make the process of reviewing site logs much more user friendly than wading through a massive .log file. They therefore make it easier to review and react to errors and issues with your code, which may otherwise go unnoticed.
Add Security Updates to your Maintenance Contracts #
If you have ongoing relationships with clients then you can and should add regular security updates to your maintenance contracts. If you don’t have the capacity to do so then you can always outsource this to one of the many partners in the Craft partners network.
But please, don’t build a site for anyone and then simply disappear without at least first explaining to them how updates work and the potential consequences of not keeping their software updated. This ends up looking bad on the community at large. Have that conversation and better yet, make delivering a security policy, described later in this article, part of every project.
Follow (Basic) Best Security Practices #
Finally, follow best security practices wherever possible. Even a few simple steps can go a long way in making it much harder for a potential attacker to exploit your site. The likelihood is that when they find no glaring vulnerabilities, they will simply move on to easier targets.
Cybersecurity is an infinite game. The surest way to stay ahead is to make your security practices just marginally better than the majority of other targets out there.
Following best security practices, however, is easier said than done, and that is exactly why we created the Sherlock plugin. At the very least, read and understand the concepts explained in the securing craft article and the security FAQ in detail.
A new major version of Sherlock was released a few days after this article was published, including a free version. Staying on top of security in Craft is now much more accessible to everyone. Read more in Stepping Up Security with Sherlock 3.
What Could Go Wrong? #
I wrote an article entitled Security Concerns in Craft CMS about the Panama Papers story back in 2017, but much of it feels as relevant today as it was back then. The following is an extract.
In April 2016, the Panama Papers story broke:
“The Panama Papers are an unprecedented leak of 11.5m files from the database of the world’s fourth biggest offshore law firm, Mossack Fonseca. The records were obtained from an anonymous source by the German newspaper Süddeutsche Zeitung, which shared them with the International Consortium of Investigative Journalists (ICIJ). The ICIJ then shared them with a large network of international partners, including the Guardian and the BBC.
What do they reveal? The documents show the myriad ways in which the rich can exploit secretive offshore tax regimes. Twelve national leaders are among 143 politicians, their families and close associates from around the world known to have been using offshore tax havens.”
The scale of the data leak at the time was unprecedented:
“The Panama Papers include approximately 11.5 million documents – more than the combined total of the Wikileaks Cablegate, Offshore Leaks, Lux Leaks, and Swiss Leaks. The data primarily comprises e‑mails, pdf files, photo files, and excerpts of an internal Mossack Fonseca database. It covers a period spanning from the 1970s to the spring of 2016.”
What shocked me even more than the scale of the leak, however, was the nature of the exploit:
“Mossack Fonseca (MF), the Panamanian law firm at the center of the so-called Panama Papers Breach may have been breached via a vulnerable version of Revolution Slider. … The MF website runs WordPress and is currently running a version of Revolution Slider that is vulnerable to attack and will grant a remote attacker a shell on the web server.”
– Source: Wordfence
That’s right, one of the biggest leaks of all time may have been caused by a vulnerability in a $25 WordPress plugin!!
“A theory on what happened in the Mossack Fonseca breach: A working exploit for the Revolution Slider vulnerability was published on 15 October 2014 on exploit-db which made it widely exploitable by anyone who cared to take the time. A website like mossfon.com which was wide open until a month ago would have been trivially easy to exploit. … Once they establish that the site is vulnerable from the above URL the robot will simply exploit it and log it into a database and the attacker will review their catch at the end of the day. It’s possible that the attacker discovered they had stumbled across a law firm with assets on the same network as the machine they now had access to. They used the WordPress web server to ‘pivot’ into the corporate assets and begin their data exfiltration.”
– Source: Wordfence
The Revolution Slider plugin exploit was made public in October 2014, that is a full one and a half years before the leak was revealed. The plugin vulnerability was actually patched with a security update in February 2014, yet the seriousness of the update was either not communicated or simply ignored.
Mossack Fonseca’s WordPress-powered website was running an outdated version of a plugin that contained a known and easily exploitable vulnerability, so the hackers could have gotten access to the CMS. From there, they were able to access credentials that were stored in the database in plain text, which may have ultimately given them full access to the company’s email server.
Regardless of whether WordPress was fully up-to-date at the time or not, the point is that a single outdated plugin with a known vulnerability was what likely granted unauthorised access to the CMS and database. And even if this theory is not what actually happened in reality, we nevertheless know that it very easily could have.
Read the original article or an explanation of the exploit.
Sites will be Hacked #
Even the sites of companies with enormous tech budgets get hacked. According to Fintech News, more than 80 percent of companies saw an increase in cyberattacks in 2020. They also published some other insightful stats, not the least of which is that 85% of people posting puppy photos are trying to scam you!
- 75% of cyberattacks start with an email
- 67% of data breaches resulted from credential theft, human error or social attacks
- 43% of data breaches are cloud based web applications
- 41% of customers would stop buying from a business victim of a ransomware attack
- 21% of online users are victims of hacking
- 11% of online users have been victims of data theft
I love the work of Information is Beautiful and feel that this visualisation captures the extent of the situation, well, beautifully.
Use Software You Trust #
In part 2, we discuss the importance of using software you trust, which should already be obvious from the reality check that you just got. But how exactly do you know which software developers are trustworthy and which are not? And what about other services your site depends on, such as those provided by web hosting companies?
Have a Security Policy #
In part 3, we discuss the importance of creating and enforcing a security policy. This can apply to a single site or to all the sites you develop, even to your entire company. But not having a security plan is like not having a data backup plan. Tell me you have a data backup plan!!
Perform Regular Security Audits #
In part 4, we’ll discuss the importance of performing regular security audits. Remember how you used to have fire drills in school? They weren’t just a reason to get out of class, although that was a major bonus.
It is only by regularly performing a security audit that you will be able to know whether everything you have done to secure your site and implement your security policy has been worthwhile. If you don’t have the capacity or skills to perform an audit yourself then bring in an external company to do it. External audits are often recommended over internal ones, as skilled people looking at your site from the outside are bound to see it differently and you are guaranteed to learn a ton from them.
Part 4 of this article is coming eventually, but don’t let that stop you from drafting a proposal to perform a security audit today!
Learn More #
The world of cybersecurity can initially feel strange and intimidating. For an easy and fascinating introduction I can recommend listening to two of my favourite episodes of the Darknet Diaries podcast, NotPetya and Olympic Destroyer.
OWASP (Open Web Application Security Project®) is the authority when it comes to software security. Their Top 10 Web Application Security Risks is a good place to start exploring the vast amounts of information that they publish.
