We occasionally hear from potential concrete5 clients who are concerned about security. It’s very true that the world (and Internet) can be a dangerous place. There’s no absolute catch-all solution here so what we’ve done is put together some of our most frequent questions and answers along with some best practices. While this isn’t going to be the perfect “BUY THIS AND HAVE NO RISK!” solution your client’s would hope for, it’s all actually true.

Q: Is concrete5 secure?

A: Yes. It’s been around since 2003 as commercial software, and since early 2008 as open source. In that time countless developers and IT teams have beaten it up in unique ways.

Q: If people can see how it works, it has got to be easier to break. Isn’t open source software inherently more subject to vulnerabilities than closed source?

A: Well we’ve been both, so we’re uniquely suited to answer this one. The truth of the matter is when we were commercial we had any number of holes in our software that we shouldn’t have. We simply didn’t know about them. The security reviews we went through tended to deliver irrelevant results. When you buy a security review, it tends to be a fixed price gig. That firm wants to show you some holes, but they need to make a profit. Rarely is there a performance bonus, so these reports tend to be long winded and shoot for things they know they can find. Open ports on webservers, older versions of system software. Things that are easy to detect, easy to upgrade, and read well in bold and red on an excel sheet. These guys aren’t going to meticulously review tens of thousands of lines of code looking for out of the box ways to abuse logic. It’s just not in their interest to do so.

Now, a 16 year old kid with nothing else to do but prove they’re smart? That’s the properly motivated creative mind you want trying to break your machine. Not someone who gets paid either way. When we went open source, some issues were identified (and resolved!) in just weeks. So was concrete CMS version 2.0 more secure than concrete5? Empirically no, but practically yes. It was really more an issue of popularity than transparency. Write your own CMS from scratch as a one off and chances are no one will bother to care about what you’re doing, or try to hack it.

Personally, I prefer living in a world where I know what I’m getting into, be it good or bad. The open source community is generally very good about communicating on security issues in a safe fashion. I’d rather have tens of thousands of developers competing to discover a hole over somehow believing the 50k I just dropped on a security review actually caught every potential abuse that might happen.

Q: What types of issues does the community come up with, and how long do they take to get resolved?

A: These days the only thing we occasionally hear about are cross site scripting vulnerabilities. Typically these are found in dashboard pages for obscure parts of the CMS or add-ons. In English that means: 1) You log in as admin to your site. 2) You leave that window open as you wander around the web. 3) You go to some nefarious website in another window. 4) Something you click on at that new site is able to do something to your concrete5 site as the user you’re logged in with.

To give you a sense of scale, we typically hear about something like this once every 6 months or so, and we have a fix available within a few days of hearing about it.

One might also point out, you probably don’t need to leave your admin account logged into the dashboard while you go troll torrents... just sayin’.

Q: I’ve been overwhelmed by the number of security updates I get from other open source CMS projects - I just can’t keep up. Why isn’t this going to happen in the future with concrete5?

A: Too much of a good thing is still too much. I can’t promise we won’t want to roll out security fixes quickly if real problems are bought to our attention at a faster rate in the future. I can tell you we tend to be pretty conservative with approving code for the core. A lot of open source projects are run by volunteers in their free time, with revolving management teams. We actually have a small core team and every line of the code in the core passes through our CTO’s hands. That helps us eliminate a whole lot of “oh, I thought you were gonna do that” type of issues.

Q: Is there any priority to the core team's security concerns?

A: Yes. We tend to worry about security breaches from external sources over internal ones. That means you’re far more likely to find some potential vulnerability in a deep page of the dashboard settings for some add-on than you are to find a SQL injection hole in a front end facing form. Our sense is just that you should have a level of trust with your fellow admins that’s higher than the general public.

Q: Do you know of concrete5 sites that have been hacked?

A: Not through concrete5. Sometimes someone will jump in our forums and claim their site was hacked through concrete5 because they see nefarious code introduced into the PHP files of concrete5. Invariably what’s happened is they’ve got some malware running on their local PC. It sniffs out popular FTP clients and looks for accounts where you’ve saved passwords. It then uses those logins to get into your webspace and add its crap to any PHP file it can find. Does concrete5 end up infected? Yes. Was concrete5 the hole the thing got in through? Nope, that was a sloppy client PC.

Q: So what should I actually worry about?

A: Too often businesses worried about security fail to think of the actual threat. It’s easy to imagine an army of black hat hackers trying to take you down. It’s easy to want to “buy more security” to combat them. In the real world, the vast majority of security breaches come from internal sources. Maybe it is a sales guy who left to join the competition, and you failed to delete their account. Perhaps there’s a middle manager who asks for admin access to get that press release up on time, and months later realizes he can see some financial reports he probably shouldn’t be able to. These are the kind of breaches you can really do something about. If you create policies and stick to them, you’re going to get a lot more bang for your buck than you will hiring firms to do port scans on your webservers.

Q: What are some best practices I can sink my teeth into?

A: 1) Backup. All our hosting clients get backup on a local hard drive once a week. A remote backup occasionally is a smart thing to do.

2) PCI Compliance. If you’re hosting data like credit cards or social security numbers, get a dedicated webserver with a PCI compliance option. We pay an extra $50/month for our PCI compliant box that we run hosting billing from, and it helps me sleep well at night.

3) Be smart about passwords. Make them mixed number/character sets. Don’t save them in applications, even if they’re hashed. More than anything, just change them frequently. If your password is in this list, you’re wasting your time reading this: “admin, 123456, fred, password, qwerty, monkey, letmein, companyname, abc123” Also do yourself a favor and use SFTP, not FTP. It's "Secure"FTP for a reason.

4) Pay for and run good security software. If you’re on a PC, this should be the first thing you do when setting up your box.

5) Have HR policies that include password/account management for new hires and anyone who leaves. Get yourself a pushy IT guy who doesn’t break the rules.

Enjoy.