Every year Drupal tends to end up in a few Top 10s, making us happy and proud. The latest Top 10 we appear in is not something to gloat over however: The Top 10 vendors with the Most Vulnerability Disclosures (source: X-Force 2008 Mid-Year Trend Statistics). We are number 8, just after Cisco (7) and just before Wordpress (9) with being responsible for 1.2% of all tracked disclosures.
While the number of core vulnerabilities has been fairly constant over the last few years, the number of advisories regarding contributed modules has exploded. To illustrate; the first half of 2008 saw as many announcements as the entire year 2007.
Of course, the amount of disclosures does not accurately reflect the amount of vulnerabilities in a product (if we had not disclosed vulnerabilities in contributed modules, they would still be there), but the staggering amount of past vulnerabilities can lead to only one conclusion: this is not good.
Here a few adhoc explanations for the increase in announcements:
When we go looking for bad quality modules, we consistently see a few types of problems in those modules: simple low-level issues (forgotten check_plain) and higher-order issues (properly using check_plain on the label of the little red button marked "Launch Nuke").
Clueless authors simply do not know about the security features Drupal provides; they never use check_plain when inserting plaintext input in HTML, concatenate variables with SQL queries (heck some even use mysql_query) and have no problem using <form>s with $_POST.
Confused authors do not know (and do not check) what kind of input a function expects. They therefore check_plain the title argument to l(), or pass l() the output of t('...@var'). They check_plain the #options values for select elements, or the #default_value for textfield elements and forget to check_plain user-supplied data in the titles of checkboxes.
These usually involve higher-order vulnerabilities but are still pretty braindead.
Some examples of actual vulnerabilities:
The clueless authors can and should be barred at the gate and through education get to know the Drupal way. I see an important role for the CVS account handling team to review code samples provided by new authors before they are granted a CVS account.
To stop authors from being confused we should better document what type of string a function or property expects.
We also need to instill a state of mind where a developer constantly wonders and investigates the security implications of every decision and every function written. I'm totally clueless myself on how we could do this.
If you have suggestions or want tell about the roadblocks you experienced while developing a secure module, please leave a comment.
Comments
Superman syndrome
I've herd it said more than once, it won't happen to me. I know a few people who don't attempt to follow security because they don't think their sites will get hit.
Another reason I commonly hear is that it's a pain to do and the developers are just lazy.
I've, recently, found a number of people developing drupal modules who don't really know how to develop. I give them a lot of credit for trying to learn but they aren't already developers and they can't find much teaching them how to do it. I couldn't find much either. And, after talking to a couple CS graduates who do web development, I learned a lot CS students aren't learning this stuff either.
Education...
This is all about education of the developers.
Let's be honest - the documentation around Drupal is not very good, and finding out the proper security procedures is not easy. And security is hard to do, and very hard to do well.
I'm not sure what the solution is, but a great start would be peppering links to this page - Writing Secure Code - anywhere developers gather.
#8
Heine, personally I read the news about the #8 position as: the Drupal security team is doing an awesome job!
But how to improve the situation?
a few questions
Where would Drupal be on this list if the reported security vulnerabilities excluded contributed modules?
Do Joomla and WordPress also report vulnerabilities found in third-party software?
CPE
Any disclosure related to a wordpress plugin would fall under the wordpress 'vendor' if the plugin can be downloaded from the wordpress site. See http://cpe.mitre.org/specification/index.html.
Not a valid comparison.
This list attempts to compare apples and oranges. Over 2000 different projects fall under the "Drupal" umbrella. Is every Windows application included in the "Microsoft" group?
Our wares
As we are distrubuting these modules from Drupal.org and people need modules for functionality not in core, I think we should take ownership of the problem and find a way to solve / minimize it.
Matter of perspective.
Maybe this could be viewed in another sense, that we have a good security team that keeps drupal in check. I guess that maybe the vunerabilities may not be disclosed and then you have holes in sites without fixes.
Keep up the good work and the watchful eye on drupal. Security is the weakest link on any website, I would rather have a site down vs. someone stealing private data off them.
Thank you and some ideas
It actually makes me feel good that Drupal's in this list. That's partly due to the security team doing a great job in an environment that you described in your article. Thank you for this work.
Yet, I get where you're going at. Many of the security disclosures wouldn't happen if they didn't exist in the first place.
Could http://drupal.org/writing-secure-code need an update?
And could the link to this page from http://drupal.org/node/508 "Module developer's guide" be on a more prominent place?
In addition, could there be a standard letter with important instructions that new CVS account holders receive?
For my personal immediate action: We're having Drupal Lab in DC tonight. We will talk about security there.
Talk & culture
These are all good suggestions, and I'm especially interested in the observations you gained from the DC Drupal Lab. Is security ('proper programming') a subject on people's minds? Was it an eye-opener for some folks?
From our chat at Drupal Lab DC
We chatted about this, for the record:
People at the Drupal Lab (our hands-on meetup) in DC are very curious about Security. Clearly, to a good many of them the security related handbook pages on Drupal.org were new. In my short presentation I also pointed also to your blog post here as I feel it transports well the urgency of the matter while showing that taking care of basic security standards isn't rocket science.
I will keep talking about this issue here and I'll make a point in actually more asking about how people deal with security in their software projects.
Loosely related: Is this a book you would recommend? To what type of person?
http://phpsecurity.org/
Thanks
Thank you for the follow-up.
I do not know the book, but the sample chapters seem to be a bit weak and even confusing. There does not seem to be a unifying look at the issues faced by Web Developers.
Innocent Code: A Security Wake-Up Call for Web Programmers is said to be a good choice for any Web Developer, regardless of language. I have not read that either (shame on me).
Of course, while these books present the important issues, they are not specifically tailored to the functions Drupal uses. Greg Knaddison from Growing Venture Solutions is busy writing a book on Drupal security for, as I understood, a mixed audience. It should be out somewhere at the end of 2008.
We'll see how we can improve the documentation and its visibility as well.