Cracking Drupal - Planet Drupal

Anything you can do XSS can do better

Ben Jeavons — Fri, 01 Oct 2010 05:25:55 +0000

Cross Site Scripting (XSS) is the number one vulnerability in Drupal code¹ and one of the scariest forms of exploits, because anything you can do XSS can do better².

More serious than <script>alert('xss')</script>

During XSS demos and vulnerability testing it's easy to use some code like <script>alert('xss')</script> to see Javascript executed where it shouldn't be. But an alert box isn't scary.

It's scary when Javascript can put your Drupal site offline. And it's even scarier when it locks you out of logging back in because it changed your administrator account username, password, and email address. Watch the short video below to see a demo of this.

The malicious Javascript entered by the attacker, when unknowingly executed by an administrator, does the following evil evil things:

Changes the site title and site email address
Changes the administrator's username, email, and password
Sets a site-offline message and puts the site in offline status
And finally, logs the current user out of the site³

How do you protect against this?

Against this exact demo? You disable the use of the Full HTML input format by anonymous users. In general you should understand how to configure your site securely and know what actions you allow untrusted users to perform.

The attack vector in the video is a comment that has Full HTML enabled for anonymous users. Note that Drupal does not come by default with Full HTML enabled for anonymous users.

Be mindful of contributed modules

It's also common that contributed modules print user-supplied data insecurely, opening up for an XSS attack. Popular modules are often more vetted and secure, and thus safer to use. Greg has written recently about some tools to use in picking modules. Also, if you're writing code, make sure you're correctly using the APIs and following best practices.

Stay safe, community!

¹XSS is the number one vulnerability in Drupal code based on times reported in Drupal core and contributed project Security Advisories as published by the Drupal Security Team. Read the report on Drupal Security for more information and stats.

²Javascript can't exactly change admin settings better than you can :). It can certainly change it "faster" than you can though.

³The final piece of the attack ran by the Javascript is actually a different class of attack known as Cross Site Request Forgery (CSRF).

Mitigation against CVE-2010-1584 Drupal Context Module XSS

greggles — Mon, 10 May 2010 18:04:36 +0000

Recently Justin Klein Keane posted information about a vulnerability in the Context Module for Drupal.

Justin included information about mitigating factors:

In order to execute arbitrary script injection malicious users must have 'Administer blocks' permission.

Here are some more concrete steps for mitigation of this particular vulnerability.

1. Ensure only trusted roles have the "Administer Blocks" permission

My coworker Ben Jeavons wrote previously in this blog about the importance of understanding trusted and untrusted users on your site and how roles play in. We also built a check for some important permissions into the Security Review module that Ben built as part of his work with GVS.

To put it simply, while it's not on the list of roles that the Drupal Security Team considers to be site owning permissions that mean there is no need for a Security Advisory, "Administer blocks" is an important permission and shouldn't be given out to untrusted people who might ~~inject XSS into a block title~~ reconfigure or disable all the blocks from the site.

Update: Heine Deelstra asked me to clarify that last line. In general, injecting XSS into a block title would merit an SA in the opinion of the Drupal Security Team. Granular permissions are a strength of Drupal and only permissions which allow for privilege escalation are included in the list we will not do an SA for.

2. Upgrade Context to the latest code from the repository

As often happens, the Drupal community can move quite quickly and in this case the issue has been fixed in the development version of code that exists in the source code repository. A big thanks goes to Steven Jones and to Young Hahn - two of the volunteer module maintainers - for helping out in this particular case . I say "volunteer" because Steven and Young are not paid by the Drupal Security Team to do this kind of work, though their employers may pay them for it, their employers are only one of many companies that benefit from the existence of the modules.

To get the code from CVS a site administrator could use this single command:

cvs -d:pserver:anonymous:[email protected]:/cvs/drupal-contrib checkout -d context-DRUPAL-6--2 -r DRUPAL-6--2 contributions/modules/context/

There is an issue to create a development snapshot release for this vulnerable branch so it would be easier to download the new code and that release will be created automatically by the Drupal packaging system within 12 hours.

Update: a new release has been created.

You should of course test an updated module in a test environment prior to releasing it onto a live site.

3. Disable the Context module

Only do this if you can't do steps 1 and 2. Really, both of those should be entirely possible and they are simpler.

The Context module provides a variety of features, but the most common one is a new way to show blocks on a site. So, if you can live without the features provided by context you can simply disable it.

Go to Administer > Site building > Modules and uncheck the checkbox next to the module and submit the form.

My personal commentary

My personal take on this is that it's been given a bit more hoopla than it deserves. The mitigation steps are simple and most sites would not be vulnerable in the first place. The Drupal Security Team has a policy of not creating "Security Advisories" in the case of Release Candidate (RC) software and, ideally, the broader world of "Security Researchers" would respect that.

Of course, it would also be ideal if site administrators respected the "developer" nature of these kinds of modules, but the project usage for Context shows that it is on well over 10,000 sites. Another solution to that would be for module developers to create official "1.0" releases of their modules if they are serious about letting them get used on lots of sites.

On a somewhat related note, the Verizon Security blog recently had a post about Security Researchers vs. Narcissistic Vulnerability Pimps.

Creating a sanitized Drupal database dump

greggles — Sat, 27 Mar 2010 15:06:55 +0000

People often want to create a backup copy of their site database and give it to someone else to create an environment similar to the live environment for testing or development. However, doing so exposes all of your site data being leaked if that backup copy is ever placed on a CD that gets lost or a harddrive which is not destroyed at the end of its life or a laptop which is stolen.

I blogged about one solution to this problem earlier with using Virtualbox and an encrypted disk image on Mac for easier and more secure development. However, another simple solution exists: munge the data.

Sanitizing a Drupal database export

The basic idea of this strategy is five easy steps:

Export your database
Import it into a new temporary place
Overwrite sensitive information with dummy data
Export from the temporary place
Share this new export

-- CAUTION: DO NOT RUN THIS ON DATABASE WHERE YOU CARE ABOUT THE INFORMATION!!!

-- Munge emails for security.
UPDATE users SET mail = CONCAT(name, '@localhost'), init = CONCAT(name, '@localhost'), pass = MD5(CONCAT('MILDSECRET', name));
UPDATE comments SET mail = CONCAT(name, '@localhost');
UPDATE directory SET mail = CONCAT(name, '@localhost');
UPDATE authmap SET authname = CONCAT(aid, '@localhost');
UPDATE client SET mail = CONCAT(cid, '@localhost');
-- Only important if you use project and project_issue module
UPDATE project_issue_projects SET mail_digest = 'foo@localhost', mail_copy = 'foo@localhost';
UPDATE projects SET mail = CONCAT("empty", '@localhost');
-- Only important if you use simplenews module
UPDATE simplenews_subscriptions SET mail = CONCAT(snid, '@localhost');

-- Clear out old webform entries which likely include e-mails
UPDATE webform_submitted_data set data='scrubbed';

-- Get rid of irrelevant data it contains IP addresses and bulks up the database
TRUNCATE accesslog;
TRUNCATE access;
TRUNCATE cache;
TRUNCATE cache_filter;
TRUNCATE cache_menu;
TRUNCATE cache_page;
TRUNCATE devel_queries;
TRUNCATE devel_times;
TRUNCATE flood;
TRUNCATE history;
TRUNCATE search_dataset;
TRUNCATE search_index;
TRUNCATE search_total;
TRUNCATE sessions;
TRUNCATE watchdog;

-- Alter sensitive entries in the Variable table
update variable set value = 's:4:"fake";' where name = 'smtp_password';

The above script is a slightly modified version of a fairly specific script that works for one specific database: drupal.org. However, you can see the techniques used here and imagine how to adapt them for other sites.

Modify the script to protect data for your specific site

One important step that I take when adapting this to a new site is to make my export from step 4 above and then do a search through the text of the export for common e-mail providers like yahoo or gmail to see if any more addresses exist. If you find one then you figure out which column they are in and use a similar "munge" process on the column updating it to null.

Take special care with some modules like twitter that may store account credentials (twitter usernames and passwords) in a database table.

And take extra special care with modules like smtp or mailhandler which store credentials for important email accounts in the variable table or other locations in the database.

Once you've got this script tuned for your site you may need to update it as you add new modules or upgrade existing modules.

And that's it - now you can share copies of your database with greater confidence that your site won't be the source of a data leak.

Edit: Updated to include webform example based on jbrauer's similar blog post.

Free resources online for protecting your Drupal site

greggles — Mon, 11 Jan 2010 21:09:40 +0000

There are lots of great resources online about how to secure your Drupal site. The CrackingDrupal.com site is meant to be one of those resources, but there are also others available elsewhere. Here are some of the best resources available from around the internet with Drupal specific security information.

Drupal.org Handbooks

The Drupal.org handbooks are probably the most natural place to look and in fact they have three great areas of resources.

Writing secure code provides advice about secure code. It can be a bit hard to understand the flow and examples, but this is still a great resource.
Secure configuration looks at the non-code aspects of configuring your site.
Security team provides insight into the policies and procedures of the Drupal Security Team. It's the policies which are most important to a typical user.

University of Pennsylvania School of Arts and Sciences Pages

The University of Pennsylvania is using Drupal for a lot of different sites. They have been actively reviewing and finding problems in Drupal's contributed modules for over a year now. They are also providing documentation (on their site) about how to secure Drupal.

Some examples:

Drupal Security Configuration
Drupal approved modules which means that they have reviewed the modules for security problems.
Drupal security considerations provides some Penn specific and some general advice about Drupal sites.

Nadeau Software Consulting

The Nadeau Software Consulting company provides an extensive online resource in 3 parts. Their advice comes from a strong system administrator perspective about how to secure Drupal within the Context of Linux/Apache.

From CrackingDrupal.com

Aside from this blog there are a few other resources on this site:

List of security focused contributed modules
Text filtering cheat sheet for developers and themers
A PDF version of Cracking Drupal Chapter 1 and the table of contents.

Other blog sites

Safe string theory for the web by Steven Wittens is a great resource. One final mention is Heine Deelstra's Blog which covers a lot of things but also frequently covers security.

Edited to include more resources from this site and Steven Wittens site.

Protecting your Drupal module against Cross Site Request Forgeries

greggles — Fri, 11 Dec 2009 04:49:12 +0000

Cross Site Request Forgeries (CSRF) are the 3rd most common vulnerability in Drupal and yet they are quite easy to protect against. The precise solution depends on where the problem is, but is never too complex to implement. To start, of course, we need to understand what CSRF actually is.

What is Cross Site Request Forgery - CSRF

When you take an action online - submitting a blog post, delete a photo, registering on a site, transferring money in a bank account - you are making a request to a site to perform that action for you. Several things happen automatically when you make a request to a site: lots of data is sent using either a "POST" or "GET" method and your browser sends along any cookies you have for the site. The cookies often contain your session identification for the site which is how the site knows who you are and what permissions you have.

A CSRF occurs when a malicious user can trick you into making a specific kind of request to a site that you did not really intend to make AND when the site performs that action. A simple example follows:

Your site has a list of accounts and presents links to delete accounts. That link points to a URL like http://example.com/admin/delete/user/2 which contains the account identifier for the account to be deleted (2 in this example)
A malicous attacker determines that you are an admin on the site and becomes your "friend" on a social networking site like twitter. They post a message to twitter @your_attention with a TinyURL that redirects to http://example.com/admin/delete/user/2
By the time you realize where the redirect is going, you've already deleted account #2. Depending on the system that may also delete all of the content associated with account #2.

Major bummer.

The solution to this problem is a secret value associated with the action that is not easy to calculate called a token. When the form or link to take an action like deleting the account is sent to the browser the site sends along a string that includes something unique and only known by the site and the user. When the request is submitted the site validates that the token is still present and is appropriate for the action being taken. If it doesn't validate, the action is denied.

Protecting against CSRF in Drupal with Forms

As of Drupal 4.7 there was a Form API in Drupal core which people used to create forms. This form API provided a central place to do form creation, validation, and submission processing. Part of that creation and validation is to ensure that the special "token" is sent to the user and validated on form submission. Drupal uses a "hash" that is composed of at least three values: the user session ID, a string associated with the action being taken, and a string that is private to the site. If an attacker could figure out this token then they could add it to the request and force the site to take the action. Fortunately, this combination of information cannot be calculated by a typical malicious attacker (they would need a super computer and an additional weakness like session fixation...pretty unlikely).

So, how do you build a form? Well, the Forms API Quickstart Guide gets you most of the way there and the small form example in our Drupal 6 API cheat sheet should finish it off. So, you use forms for every major action on the site that changes data and you will be protected against CSRF.

Some of the time a form won't work in the design or user interface. You just want a tiny little link. So, if you want to use a link for an action like deleting a user or deleting content that is really destructive then you should use a confirmation form. It makes sure the user wants to take the action and acts as a small confirmation.

Side note: usability people say we should not do confirmation forms and that is right, but their concern is flow and their solution is to simply "archive" in an easy to undo way. Our point is to get a form token in there.

So, how do you do a confirmation form? Well the User Protect module did just that a little while ago. You can study that patch to learn it.

Protecting actions in Drupal by leveraging tokens directly

So, what if the action being taken isn't as extreme as deletion? In that case you can use an alternate trick that directly leverages Drupal's token generation more directly. A great example of this comes from the Security Review module.

The token is added to links in the security_review_reviewed function:

$token = drupal_get_token($check['reviewcheck']); $link_options = array( 'query' => array('token' => $token), 'attributes' => array('class' => 'sec-rev-dyn'), );

That token is then checked in security_review_toggle_check:

if (!drupal_valid_token($_GET['token'], $check_name)) { return drupal_access_denied(); }

There are a variety of ways to actually insert the token into the link and write the Ajax code to submit the request and then validate requests. This just shows the basic idea: you add a token into the page that will be returned with the request for the action and then validate it before performing the action.

For an example of this being added to a module on Drupal.org you can see the patch to fix Plus 1 from 2008.

One special note: many people feel that it's semantically inappropriate for a site to take actions in response to links (which initiate an HTTP GET request as opposed to a POST request which is commonly used in forms and which are defined in the HTTP spec as being associated with changing data on the server). There are also potential problems with using links such as http accelerators that pre-fetch all the links on a page. You can mitigate the pre-fetchers by adding a rel="nofollow" attribute to the link, but really the pre-fetchers are relatively uncommon these days so hopefully you don't have to deal with them.

Summary on Cross Site Request Forgeries & Drupal

Protecting against CSRF in Drupal is not particularly hard to do, but to date there have not been any easy recipes on how to handle it. Hopefully this resource will enable people to write their code properly the first time and fix any vulnerabilities you may find in existing code.

The Importance of User Roles and Permissions for Site Security

Ben Jeavons — Tue, 10 Nov 2009 19:18:49 +0000

Rethink your roles

When discussing site security we often use words like "attacker", "malicious user" or "untrusted" to define site visitors who may be intent on abusing resources, stealing, or altering data. Within Drupal, visitors can achieve these goals using the permissions granted to their roles. This is the key component. We have to think of visitors in terms of what roles they have and what permissions we've granted those roles. Then instead of just thinking about trusted vs. untrusted users, we are thinking about trusted vs. untrusted roles.

On your site, which roles are trusted and which are untrusted? What permissions have you given to those roles? What permissions have you granted to the Anonymous role and thus to anonymous visitors? As you build and add features to your site you are also widening the available points for attack. If you have allowed users to create accounts without administrator approval you should also consider what permissions you've granted the Authenticated role. Can authenticated users create content or post comments without approval?

Know the defaults

Community contributed modules as a whole are more insecure than Drupal core so it's especially important to be cautious about administrator permissions created by contributed modules. Role management can be burdensome so there are modules that grant roles to users upon account creation. Know the defaults, because most Security Advisories for contributed modules are because of cross-site scripting vulnerabilities and often exist on module administration screens where user-supplied data is not properly filtered. Whenever possible, utilize the principle of least privilege and give roles only the permissions they absolutely need. Grant those roles appropriately based on trust and what features need to be exposed for use.

"Super-permissions"

A few Drupal permissions should never be added to untrusted roles, as they allow or open up full control of your site. These permissions are:

Administer filters
Administer users
Administer permissions
Administer content types
Administer site configuration

To help keep your site secure, rethink which roles are trusted and untrusted, then evaluate what roles are granted to which users.

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!

Talking about security in Drupal

greggles — Wed, 30 Sep 2009 23:55:32 +0000

This coming fall we'll be talking about security in Drupal so much I can barely believe it.

Acquia Webinar - October 8th online

First up is an Acquia Webinar, which will be a review of security in general and then we'll show two common mistakes that cause the majority of the problems in Drupal sites and modules. The talk will discuss the topic area broadly covering the perspectives of business users, technical users, and developers.

Note, you must register for the webinar before it happens.

BADCamp - October 17th and 18th near San Francisco

Ben Jeavons, a recent addition to the Growing Venture Solutions team, will be speaking on our behalf at the Bay Area Drupal Camp out in California. He will be giving a talk aimed at beginners and site admins called Drupal Security for site administrators and beginners

AppSec - November 12th and 13th in Washington DC

Ben and I will both be headed out to AppSec - the Application Security conference hosted by OWASP - the Open Web Application Security Project. We'll be there mostly to learn and share ideas, not give any presentations per se. But I do think that Drupal's security tools and philosophies could one day form the basis of a presentation at OWASP conferences. We particularly look forward to learning from other folks about security team process - the Drupal security team is always looking to follow best practices and improve upon them.

Do it with Drupal - December 9th, 10th, 11th in New Orleans

I'll be headed down to New Orleans for this year's Do It With Drupal conference. The feedback from last year's event was quite positive and I'm sure that it will be a great event again this year. My talk at DIWD will probably be a mix of sysadmin and developer and general security education - I've got over an hour to play with, so I'm looking forward to it.

Free copies of Cracking Drupal ;)

Yes, that's right, at all of these events we will be giving out free copies of Cracking Drupal to a few lucky audience members. So please come on by and say hello, ask great questions and you may be a lucky winner as well.

Security Review for your Drupal Site

These presentations are nothing new for Ben and I. I've been giving them since Drupalcon DC and Ben since Drupalcamp Colorado. Historically we've given them with the goal of educating the public and hoping to reduce the work the Drupal security team has to do. Educated developers make for secure developers.

What is new is our security review service. More details about that after the Acquia webinar, but if you're interested in having a site or module reviewed for its security please contact us.

Easier and Safer Drupal Development with Virtualbox / Virtualization

greggles — Tue, 25 Aug 2009 12:39:51 +0000

As a developer there is often a point in your career where you take a look at the number of client databases installed on your hard drive and start thinking "boy, I hope that data never falls into the wrong hands." And, if you're like most web developers and use a laptop, the chances of having a laptop lost or stolen are surprisingly high. It happens to the best of us.

Further, chances are quite good that you are using Windows or Mac for your working environment but want to run your sites in a Linux environment just like you have on your servers.

How about this: create a Linux server that runs inside of a virtual environment and then put the disk image for that virtual server into an encrypted drive image. Perfect! This tutorial assumes you use Mac OSX - but the same principles could be applied to any operating system. This setup is meant to be reasonably safe against typical thieves, but doesn't protect the data completely.

Virtualbox Virtualization to the Rescue

Of course I'm mostly an open source fan so I'll try the Open Source virtualization option first. And...Virtualbox works quite well.

First create some space for your disk image. I fired up the Mac Disk Utility, selected compressed and 128 bit encryption like so:

Give yourself enough disk space - at least 5-10GB depending on what you'll do with the server. Creating a "sparse" image just means that it will create the image at a relatively small size and then increase the size as necessary. It's a performance trade-off to save disk space which is worth it for development.

The decision to use 128 or 256bit encryption is up to you and how sensitive your data really is. I'd rather get slightly better performance than have super-duper encryption.

Next, install Virtual box and follow their documentation to setup a Linux environment, like Ubuntu. I chose the 9.04 Desktop version of Ubuntu so that I can use some of the Linux GUI tools directly (that's especially handy to show how Ubuntu works to someone who is interested in it). Virtualbox 3.0 just came out with lots of improvements like faster Disk I/O. In my testing so far, it's good enough.

Once you've got Virtualbox open, click the "New" button where you'll get a wizard. Answer the questions depending on your preferences, the only important step is the "Virtual Disk Location and Size" where you should be sure to put your disk image inside the encrypted disk (which you may have to mount by double clicking on it).

I chose to use a "Bridged" adapter for the network where the guest operating system (Linux in my case) latches onto whatever network device my host is using and grabs an extra IP address from the DHCP server. This has the benefit of allowing other people in the office to quickly and easily connect to your Linux Virtualbox server directly using an IP address.

I spent a bunch of time messing with shared folders and couldn't get it to work. My solution now is simple: sshfs via macfuse.
1. Install macfuse.
2. Create a directory to use as the mount point like mkdir ~/shared_directory
3. Find the IP of your virtualbox and run the command sshfs [email protected]:/ ~/shared_directory

That's it - you've now got the entire root filesystem of your Linux virtualbox mounted at /Users/greg/shared_directory. From the Host maching you can now navigate this directory using Finder, use shell commands from the Mac terminal or edit files using Mac based editing software (in my case the big one is Eclipse). If you change networks and get a new IP address your mount will stop working and you'll need to create it again. I've gotten pretty quick at re-establishing the mount point.

If you have extra RAM and want to run the Linux system with a GUI, go for it. I did this at first but found I was running out of RAM. So, I used a command to remove the destkop manager from my startup scripts and now the box hums along nicely at 256MB of RAM.

sudo update-rc.d -f gdm remove

If I ever want to add Gnome's desktop manager back, it's a simple command:

sudo update-rc.d -f gdm defaults

Virtualbox and Ubuntu Resources

How to setup an Ubuntu lamp server from the Drupal on Ubuntu group.
Installing Ubuntu inside Virtualbox (it's for Windows, but the idea is virtually the same).
Virtualbox HOWTOs from the Virtualbox site itself. Very helpful.
Virtualbox Forums - I ended up here as a result of searches, but the forums seem pretty active and helpful.

Data Privacy Considerations with Drupal in Encrypted Virtualbox

So, is this really safer? Consider a typical Drupal development environment: someone who gets physical control of your machine and can login as you will be able to read your settings.php files which contain credentials to get all the information out of the database. So, the first steps are:
1. Use a username/password to login to your operating system rather than having it automatically log in.
2. Set your system to "lock" itself and require the credentials if it is unattended for more than a few minutes or is hibernated.
3. Use a firmware level password
4. Use decent passwords ;)

Someone might be able to override this information using the password reset "feature" of the operating system. Ok.

That's where the virtual disk image and encrypting the disk image comes in. If someone reboots the machine to reset the password then the drive will no longer be mounted. Mounting it requires the drive's password which only you know. Yay.

There are probably some areas where this system is vulnerable to an attack. My goal is not to completely prevent a talented attacker from getting my data (it's unlikely that a talented attacker would happen to steal specifically my machine...). My goal is to protect the data if a casual thief steals it. A casual thief presented with this scenario is likely to replace the hard drive and toss out the old one, in which case the data would be lost but not exposed.

Update: Automatically Mount the SSHFS Drives

I've attached a little script that automatically mounts the external drives.

Attachment	Size
mounter.txt	684 bytes

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.