4 Drupal Security Issues
Mon, Feb 8, 2010 by Arnold
UPDATE: There is some controversy about 1), see more information here: http://drupal.org/node/475858. As pointed out by some readers, there are other ways to figure out the Drupal version of the site.
While Drupal is a secure system, there are 4 configuration issues that are often overlooked when developing a Drupal site. By following a few easy steps, we can make a Drupal site much less vulnerable.
1) Leaving Drupal Version Information Text Files on Server
A lot of developers forget to delete the Change Log and other text files that come with the Drupal package. By leaving the text files on the server and having them accessible, you enable potential hackers to know about the exact version of Drupal that you are using. Once the hackers know about the version, they can more easily find the exploits to hack into the Drupal site.
2) Cross Site Scripting
Cross site scripting can happen if you allow visitors to post any HTML code and JavaScript into form boxes. This will allow hackers to post malicious code onto your web page. It is critical to either ensure that only filtered HTML is allowed for postings or to run the check_plain() function against all user input.
3) Exposing Apache/Server Tokens
Server Tokens is information about the version of the Apache/PHP server and the modules that are loaded. A lot of servers a configured to display this information when a user goes to a "Page not Found" page. The issue with this is that it allows hackers to identify the server version and figure out exploits for that server version.
4) Allowing Users to Create Accounts on a Private Content Site
Users should only be able to register and create accounts on community web sites. Users should not be able to register if the site is a private corporate web site where content is only managed by the administrators. There have been various occasions where I find that users can register for a account on a corporate Drupal web site. The security risk this poses is that users may be able to create profiles (if Node Profile is an enabled module). They may then be able to use that page for link spamming purposes. The simple fix for this is to change the configuration to only allow administrators to approve user signups.
Chris Cohen posted on February 10, 2010 9:30 am
I think the two reasons given in the comments above are enough to conclude that hiding CHANGELOG.txt is not a good security measure. It might be good practice, but it shouldn't really be grouped in a security-related post.
The first reason was that an attacker is likely to bombard your site with every attack know to man anyway, so being unable to determine the specific version is not an issue.
The second is that there are plenty of other ways to determine that a site is not running the latest version of Drupal, so unless you hide all of those too, which would be very difficult, you're really not accomplishing anything.
If you take security seriously you will be updating Drupal as a routine part of your administration, so you won't need to worry about whether CHANGELOG.txt is visible or not.
admin posted on February 9, 2010 4:35 pm
I agree that updating Drupal version is the way to go though.
admin posted on February 9, 2010 4:34 pm
Thanks for all your input.
I agree that things like cross site scripting protection is a way more important than hiding the Changelog file.
While the whole ChangeLog hiding scenario remains controversial as we have seen in the various Drupal.org posts/issues, I think that it is good for people to be aware of it. If we ask 10 developers, some will say it is important, others will say it doesnt matter.
greggles posted on February 9, 2010 2:56 pm
And yet more information why we shouldn't http://drupal.org/node/475858
Also, the top of the page you linked to says quite clearly "This is not an important issue."
The handbook is not gospel.
Anton posted on February 9, 2010 8:57 am
The other reason why hiding versions won't help is that lazy script kiddies and bots don't even bother to check versions - or even what the server software actually is a lot of the time.
They just blast every exploit they have at everything in sight. My Apache logs are full of attempted phpBB exploits, FrontPage extension exploits, Wordpress exploits etc etc despite never having used any of them.
Obscurity is no defense against those tactics.
zzolo posted on February 9, 2010 8:19 am
Please do not suggest that hiding what versions of software you are using is a security measure. As Bruce Schnieder would put it, this is just Security Theater. The problem is that sites are not upgraded. It is a better secuity suggestion to ensure site admins are on security mailing lists. If you are uncomfortable sharing the version of your software, then maybe open source is not for you. (also, I once thought as you did, but I would suggest updating this post.)
dalin posted on February 9, 2010 6:07 am
Hmmm, not following your own advice:
Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.3 with Suhosin-Patch
PHP/5.2.6-2ubuntu4.3
Also you are running Drupal 6.11, 6.12, or 6.13 (i.e. not the latest security release). And I found that without CHANGELOG.txt etc.
It's just as easy to do a
cvs update -dPr DRUPAL-6-14
as it is to remove the text files.
In regards to directory indexing and CHANGELOG.txt et al, as noted twice on the page that you linked to:
http://drupal.org/node/244642
This is not an important issue. There are other ways in which an attacker could determine information about your site.
Again, it's more important to review other aspects of Secure Configuration of your site rather than worry about this information disclosure.
Those being:
- Preventing execution of untrusted PHP
- Securing user input (which you mention)
- Securing file permissions and ownership
And of the more minor security hardening configurations you skipped:
- send PHP errors to the log only, not the screen
lyricnz posted on February 9, 2010 1:53 am
Hiding changelog etc is not really an effective way of hiding the versions of your core/contributed modules. It's still pretty easy to determine which version they are by determining the version of individual files. For example by looking at CVS headers in JS/CSS/etc files, or comparing checksums of various downloadable files. This will allow you to narrow in on the release (when combined with Drupal's public CVS repository).
For some releases, you'd need to also look at the behavioural changes caused by the individual releases - eg: looking at source/output when attempting openid logins in 6.15, etc.
admin posted on February 9, 2010 12:30 am
More info why we should hide ChangeLog.txt and other info files: http://drupal.org/node/244642
Post new comment