Cracking Drupal - ssl

Drupal Security webinar with Acquia roundup

greggles — Mon, 12 Oct 2009 18:01:12 +0000

This past Thursday several hundred folks joined me for a webinar about security in Drupal as part of the Acquia webinar series.

You can now download the Security in Drupal introduction slides which include the speaker's notes and watch the screencast itself:

I also wanted to answer some questions that were posed in Twitter and in the GoToWebinar chat room. I didn't get to answer all of them in the presentation, so, I'm going to try to answer them all here.

Would you consider something as common as RSS publishing as a potential method for people to steal content?

Not in general. Sure, it makes it easier to copy your content but a determined scraper will always get your data. Now, an rss feed can be an access bypass vulnerability if it doesn't respect Drupal core's node access mechanisms, I have seen that.

What do you tell a client who doesn't want to pay you for your time to perform security updates?

We try to insist on it at the contract stage that as long as they are a development or maintenance client we will do site security upgrades ASAP.

Lots of good information in this presentation. Will you share slides? The zero day attack slide could be really useful.

Yes. The slides are attached.

It seems like Wysiwyg editors open a lot of vulnerabilties. Are there any modules you feel are more or less vulnerable

WYSIWYG editors don't open the vulnerabilities - bad configuration of input formats does. It's true that many sites will install a WYSIWYG and open up their input formats inappropriately and that's the real problem.

Can you talk a little bit about how his firm performs a site security audit? How long does it take and what is the cost range?

We have some details on our security review service. As far as pricing, we'd love to hear your feedback on what kind of price seems good. Please contact us to let us know what you think.

In a preprocess function setting up our variables for our designer, do we need to sanitize content in $vars before passing to tpl?

This isn't a simple yes/no kind of question. The answer depends on a lot of factors. While it's not a complete answer either, the Text filtering cheat sheet for Drupal is intended to make it easier for an educated developer to decide which function to use.

Forms input filtering is not recommended - that is the problem with Webform Report - why is maintainer unable to fix it?

This has more to do with them having the time/motivation/understanding and nothing to do with how technically feasible it is to fix the problem. It's actually another new service that we're offering is that we will take a module which has been abandoned for security reasons and fix it. If you'd be interested in sponsoring the work to fix that or any other module please let us know.

Can a lot of this security be built into a theme?? Will any of this be corrected in Drupal 7?

The theme layer is not an appropriate place for security protection. Themes can be switched quite easily, by admins and sometimes by end users, so if you put the protection in the theme then it's easy to mistakenly create a vulnerability.

Security related code belongs at the module or core layer. Now, Drupal 7 does have a much better rendering system (great presentation on render by Moshe Weitzman) which will hopefully make it easier for themers to not have to think text filtering.

I've read your book (good job, by the way) but it's not for beginners. Are you planning an seochecklist sort of module for security auditing drupal?

Well, I have to disagree ;) I think many parts of it are for beginners. But yes, as part of our security offering we do plan to create many new tools and enhancements to core that will be helpful to site builders.

What are some bad practices for theamers? Are there things that themers can do to make the site more secure?

This is not easy to answer. It's basically the fundamental question that the book answers. However, we do plan another webinar for the spring so perhaps that can be the focus.

Is that a FireFox addon that allows you to change your user agent? What is it called?

Yes, I use the User Agent Switcher by Chris Pederick.

Can t() be considered a substitute for check_plain()?

Yes, if you use the @ or % placeholders then t will automatically include check_plain style filtering as the text is substitutde.

How much scrubbing is necessary for FormAPI based forms? Do you risk XSS type attacks without checkplain, for example?

First, all forms should be Form API based (unless they post to an external site, which is very rare). Second, yes, if you use user modifiable text for labels or titles then you will need to do filtering. The exact nature of the filtering depends on a lot of factors

How can we do SSL or HTTPS with Drupal

I just blogged about this recently: Recipes for SSL / HTTPS in Drupal.

That's it!

Drupal and SSL - Multiple Recipes to Possible Solutions for HTTPS

greggles — Mon, 03 Aug 2009 22:35:02 +0000

As Matt Cheney likes to say "Much like Scrabble, the S is an important letter on the internet." If you really care about the data you are sending across the internet you want to make sure you are using SFTP instead of FTP, SSH instead of Telnet, and HTTPS instead of HTTP. So, within a Drupal site how can you use HTTPS to secure the data sent to and from your site and prevent sessions from being hijacked?

There are four basic solutions, though each has its benefits and drawbacks. I'll try to describe each one and give some guidance on the problems. They are covered from what seem to be the most common to the most secure. Note that the third technique is somewhat novel.

Note: All of these assume that you have configured your webserver to use SSL which is well documented elsewhere - I don't think that's useful to try to cover here.

Use the Securepages Module to Encrypt Login and Admin Pages

The Secure Pages module is a relatively old module and quite popular. It's goal is to only make certain pages of the site use HTTPS by using two lists of urls which should either by HTTPS or not. The benefit of this module is that you can use regular old HTTP for most of the site and only encrypt the traffic where you really need it. By default it will encrypt traffic for adding content, editing content, anything related to users, and for the admin area.

SSL processing is taxing on a server. Using SSL on just the most important pages helps make sure that the data sent back and forth on those pages is encrypted. However, the session cookie is still unencrypted so a user who authenticates over HTTPS and then visits a non secure page sends their sesssion identifier in the clear which allows for an attacker to steal their session and login to the site which gives them the access to the very data that was supposed to be protected. This is largely "security theater" but it sure makes people feel good.

Pro: Reduces load on server compared to a full SSL solution while encrypting important data transmission.
Con: Doesn't protect against session hijacking so data can still be compromised.

Using Securepages and Securepages Prevent Hijack

Noticing this weakness, the user grendzy created the Secure Pages Hijack Prevention. This module creates and sends along a second cookie that is marked as "secure" so that the browser will only send it over HTTPS. The module then tracks access to the site and logs out any user who attemps to visit an "important" page without sending along that second cookie.

Pro: Still reduced load on server with reduced damage from hijacking.
Con: Session hijack still possible, but limited in what damage can be done and data is still sent in the clear sometimes (may be an acceptable risk).

Use HTTPS for a session after login

This is a solution that one of my clients created to provide HTTPS pages for all logged in users, and keep all anonymous users on HTTP, but could be extended for other rules as well.

The major piece of the idea is in settings.php:

if (!empty($_SERVER['HTTPS'])) { ini_set('session.cookie_secure', 1); $base_url = 'https://example.com'; } else { $base_url = 'http://example.com'; }

This little bit of code says "if the user is requesting a secure page, make sure that their cookie is marked as secure and that the base_url variable (used in many parts of Drupal) includes https - otherwise, use the regular http values." The use of the secure cookie flag prevents hijacking but does have one drawback: If the user has a bookmark for the homepage that is not https then their cookie won't be sent along to the site and they will appear to be logged out.

Combine that with a redirect from the regular "user/" pages to the https version and you should be all set.

Pro: Still simple, more complete than a "per path" SSL system, limited possibility to hijack a session.
Con: Potentially confusing to users under certain conditions.

Just Make All Drupal Pages SSL

This is the most secure solution, but also the most resource intensive on the server. If you just make all traffic to the site over HTTPS then it will all be encrypted - problem solved!

You can use Apache's mod_rewrite to achieve this:

RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R,L]

php_value session.cookie_secure 1

Pro: Complete solution. Simple - no extra modules required.
Con: May require more expensive servers, or additional servers.

Which Secure Page Solution Is the Best?

The best solution depends on your specific site, end-users, and privacy needs. Many sites don't need to worry about HTTPS at all. Some want to keep performance up as much as possible and only care about the security of the data en-route, but aren't concerned about session-hijacking (e-commerce where the credit card is not stored). As is often the case, you must balance multiple facets when considering the right solution for your site.

Got any other solutions? See any other pros or cons with the ideas presented here? Please let me know.