Every major version of UserSpice since 4.0 has been audited by an outside security firm. Usually they come back with 5-10 mild to moderate things that need to be fixed and we fix them as quickly as possible and issue an update. For our 2019 / v4.4 audit they examined both 4.4.04 and 4.4.09 (the latest version as of April 25, 2019). For the first time ever, there were zero security vulnerabilities found. In fact, this is why I had them go back and do version .04, just to see if we happened to have fixed some early bugs. Before we get too excited, it’s important to understand what this means and what this doesn’t mean.
The primary audit was performed by giving the auditor an account with “user” level access. It should be understood that with great power comes great responsibility and you should give your average user basically no power. Attacks were performed on things like clickjacking, cross site scripting, SQL injection, and escalation of privilege. No vulnerabilities were found. Additionally, for the first time ever, we gave them ADMIN access (although not master_account access) and they were unable to do anything that a normal admin could not do anyway (i.e. injections or clickjacking).
Simply put, this does not mean that UserSpice is impervious to hacks. While we do our best to prevent attacks, mistakes happen. It is a very large code base (something we’re hoping to address in UserSpice 5 as we make the application more modular). We actively invite white hat hackers to probe the system and report their findings in a RESPONSIBLE way by contacting a lead developer, ideally via private message on Discord.
1. Your site is only as secure as your server. It must be patched and up to date.
2. You must get a TLS certificate, enable TLS 1.2 and turn on the “force_ssl” setting in the dashboard
3. Your site is only as secure as your server. It must be patched and up to date.
4. Plugins, widgets, and templates are all awesome tools, but you need to trust the developer (and verify the code on your own). One line in a plugin can delete your database.
5. We can do everything possible to secure UserSpice, but the user will spend most of their time interacting with YOUR code, not OURS. We can offer sanitize functions on form inputs, but if you do not use them, they don’t do any good.
It’s very difficult for a developer to audit their own code. This is why we use a disinterested 3rd party firm. That said, I have also been pounding on UserSpice with the TIDoS framework on Kali Linux and there are a few things I can do to make the project more secure. We’re going to be examining those things and making sure that we can implement them in a way that doesn’t break anyone’s code. There are a few autocompletes that will be disabled and some security-hardening techniques that we will employ.
Brandin and I are committed to reducing the size of the code base and making the core code as tight as possible. We want you to have as much UserSpice as you want… but only as much as you want. Things like social logins, messaging, notifications, and other resource-heavy parts of the code will be moved to plugins. This not only shrinks the main code itself, but offers people the opportunity to choose WHICH messaging system they want to use. There are lots of cool things that we’re not ready to announce yet, but we want you to know that good stuff is coming.
To date, users have submitted over 550 bug reports and feature requests to the new-ish bug reporting system. As you guys find our mistakes (often submitting the fixes as well), UserSpice gets better and more secure for everyone. You have all persevered as we have made and fixed mistakes and we can’t thank you enough for that.
– Happy Coding,
Dan & Brandin