5 February 2018 | 217 views
So, how secure is Tuskfish CMS?
I honestly can't say. Web development is a blood sport1. You can certainly reduce risk and mitigate impact through various practices and through testing, but there is no magical way to eliminate all bugs. What I can do is tell you about the measures that I have taken to reduce security risks. These may suggest aspects of Tuskfish that you may wish to personally review:
Single admin system
There’s only one admin in Tuskfish and that’s you2. There is no user rights management system to worry about; they don’t have any. So you don't have to worry about insider threats, malicious users or clueless colleagues.
Explicitly minimised attack surface
The Tuskfish code base is deliberately as small as possible. Most of the Tuskfish code lives outside the web root (ie. outside of public_html) where it cannot be directly accessed by browser.
Tuskfish explicitly avoids use of third party libraries as far as is practical, as they will inevitably contain their own collection of bugs and vulnerabilities3. The libraries that Tuskfish does use on the front end are as follows:
- HTMLPurifier, for validation of HTML fields in data submission forms.
- Bootstrap 4, for front end presentation purposes.
- JQuery, which is a Bootstrap dependency.
- Popper.js, which is a Bootstrap 4 dependency.
- FontAwesome 5 vector icons.
On the backend Tuskfish also uses a few libraries and plugins to enhance the data entry form:
- TinyMCE, to provide a WYSIWYG editor in the HTML teaser and description fields.
- Bootstrap-datepicker plugin, which provides the calendar widget for the date field.
- Bootstrap-fileinput plugin, which provides the file upload widget for the image and media fields.
Rigorous multi-level validation
Tuskfish components do not trust one another. Every public-facing script and public or protected method independently validates its own parameters, so a validation error in one component is unlikely to provide leverage against others. This results in a fair bit of redundant validation as data is passed from (say) a controller script to a content object to the database layer, but this is a design choice.
Validation is conducted against standardised methods in the TfValidator class.
Prepared statements and bound parameters
Database queries are exclusively made using prepared statements with bound parameters (PDO) to guard against SQL injection. Parameters are never directly used in a query, they are always inserted via a placeholder. Identifiers are validated as well.
Strict type definition
Strict type definition (available as of PHP 7.2) is used in method parameters as far as is practicable. Strict return types are not yet in use, but will probably be added at some point.
Slow password hash
Passwords are hashed with PHP's native password_hash() function and the default algorithm (currently Bcrypt). The password_hash() function salts and recursively iterates the hash calculation according to a configurable 'cost' parameter, which is cranked up a bit higher than standard, to resist cracking attempts.
Optional two-factor authentication
An alternative login script is available if you wish to use a Yubikey hardware token as a second authentication factor, in addition to your password. In the event that someone compromises your password (or if they steal your Yubikey) they will not be able to hijack your site, because they need both to login. If you have a Yubikey I encourage you to use this option.
No online password reset
If someone breaks into your email they can typically discover your online accounts and take control of them by resetting the passwords. But they won’t be able to gain access to your Tuskfish website, because it doesn’t have an automated online password reset system. An offline (manual) password reset tool is provided.
Single origin code
With a couple of small exceptions (which I have reviewed) all of the native Tuskfish code has been hand crafted by me. All of it has been through the same careful review and testing procedures. By contrast, most other CMS have dozens or even hundreds of people contributing code and plugins over many years. Consequently, the security of their code tends to be highly variable (especially when it comes to third-party plugins, which are the main issue), whereas mine is just uniformly terrible :-)
What I have not done
- I have not reviewed the external libraries used by Tuskfish (see list above) and have no plans to do so. However, they are mainstream libraries and actively maintained by their respective communities. I do track these projects and will update the libraries that ship with Tuskfish when vulnerabilities are found.
If you do find a problem
If you do find a security problem please contact me with the details so that I can fix it.
1. Yes, I stole this line. The full quote is Web development is a blood sport. Don't wander onto the field without a helmet. It's from Securing PHP Web Applications by Tricia and William Ballad, although it's well out of date now.
2. If you're wondering why, I spent many years trying to get professional colleagues involved in website management as section editors or contributors. What I discovered was that I had to edit nearly everything they wrote, fix images and reapply consistent styling. There is no escaping the need for an editorial process, and editing is best handled in word processors. So, let your contributors write in Word and send you the files for web publishing; you'll have less work to do and get a better result.
3. More code means more errors. More errors means more vulnerabilities. This relationship holds true whether you are the best programmer in the world, or the worst. Realistically I don't have the time to forensically examine other project's code. I also don't want to get caught up in a spiderweb of dependencies or trapped on a security update treadmill, trying to keep tens of libraries patched.
Copyright, all rights reserved.