Securing your admin area with SSL in drupal (and other systems)

jadwigo's picture

This article is here to start a discussion about this topic, and maybe go on making this into a GSOC proposal or a new module.

Securing your admin area with SSL in drupal

Setting up a secure administration environment in drupal is still complicated, and might even be an important security flaw in several configurations. A large part of this is due to the architecture of drupal that does not have a dedicated admin area and not much difference between normal (unprivileged) users and admin users.

Securing the session cookie

At the moment drupal does not set the login/session cookie flag to secure only when a user logs on using https. Users that login over http can switch to https and will still be logged in.. meaning an attacker might steal an insecure cookie and use it to logon a drupal site over https.

This seems to be easily prevented by adding a little php code to your settings.php file ( http://fscked.org/blog/fun-snags-drupal-cookies ) or a little more complicated with some .htaccess magic. Users that login over https will have a secure connection, and will not be logged in over normal http. But this only fixes the cookie stealing issue, if an attacker steals a http session of an admin user, the attacker can still change the password and use the new password to enter the site securely.

So you need to enforce https logon for admin users, where normal users may browse the site over http. This also means all users must login over https, because if an admin user forgets to use https the password will be transmitted over an insecure connection.

The solution would be to require that all users always logon using https://www.example.com/user and then the admin users continue to browse the whole site over SSL while the normal users continue over https. Unfortunately the currently available tools are unable to enforce that, an admin user can simply forget the one simple "s" and login with an insecure session, and then continue in the insecure site. For normal users this is less of an issue.

Some modules that try to do this are secure pages ( http://drupal.org/project/securepages ) and secure login ( http://drupal.org/project/securelogin ). Both of these modules are inadequate.

Using secure pages

This is impossible with secure pages. Secure pages enforces SSL for certain paths and does not allow those paths to be accessed without it. This might be good but the problem lies elsewhere. Without the patched settings.php file a user will be logged in with an insecure cookie and the secure pages will be still using the insecure cookie. An attacker can then steal the cookie and logon into the secure pages.

If you use the secure cookies setting your site will be almost unusable with secure pages, because for all non SSL paths you will not see the administration links, and you'll have to access those paths (eg https://www.example.com/admin/settings/securepages ) manually.
If you want to make your site usable for normal people that's unacceptable.

Using secure login

Secure login redirects the login form action to the secure version. This is good, but after that secure login does not do anything else. For a secure admin area you have to enforce that admin users will be redirected to the secure version of your site.

A solution: role based secure pages

For the solution the following should be set up:

  • All login forms, password recovery forms as well as the profile edit pages are redirected over https.
  • The session cookie for admin users will be set secure only, the session cookie for normal users will be insecure.
  • The admin users will always be redirected to https always and normal users will be browsing the site normally over http.
  • There must be a differentiation between the normal user roles and the admin user roles.

Because there is no module that does this at the moment it should be built, preferably into one of the already existing modules, where secure login would be the logical choice.

Comments

I think that this project is

gordon's picture

I think that this project is too small for a SoC project. The main solution would only take about half a day to implement into secure pages.

even if you did every crazy idea that could be thought of then it would not really take that long to develop to fill up an entire SoC project. For example secure pages only took half a day to create the inital version.

Also allowing for usability of a site, it only makes sense for the admin users as you still need to be able to jump back and forth to allow the site to scale. About the only user you want to keep in ssl 100% of the time is user 1.

A large part of this is due to the architecture of drupal that does not have a dedicated admin area and not much difference between normal (unprivileged) users and admin users.

This statement is incorrect because there is a huge difference between user 1 and all other users. You can set a role up to be able to handle similar things but there are still major differences between user 1 and everyone else.

--
Gordon Heydon

--
Gordon Heydon

unencrypted posts

jyamada's picture

This might not be the right thread for this but I'm a newbie to Drupal and I'm bound to make mistakes. I'm doing most of this project describes with htaccess rewrites and well drupal roles, so this is not necessarily a project I would endorse. My problem now is that my posts are unencrypted, has anyone experienced this too? So while my page is hosted via a https channel, if i submit then my browser tells me I'm sending unencrypted. Gordon, are you sending unencrypted posts?

Gordon, thanks for the

jadwigo's picture

Gordon, thanks for the feedback.

I agree with you about the SoC scope, but then again, I had to ask :)

--

I have to disagree with you about that the only user you want 100% in ssl is user 1.

Suppose user 4 also has administer users privilege (and should be considered an admin user) You want that user to be logged in over SSL all the time. If user 4 logged in insecurely the session can be stolen by an attacker, and that attacker can then view the username and change the password of user 1 - thus gaining access as user 1.

The whole idea of this proposed setup is not suited for a small site. On sites with a few users where one of them is the admin you won't have to delegate user administration to other people. Also, for small sites it's usually not feasible to pay for a SSL certificate.

So I assume that sites that want this kind of security have the budget, and the number of users that justifies the complicated setup. (Or a client who wants it anyway)

In a case like this it's not a good idea to trust the admin users to always remember to switch to https every time they do one of their tasks, because they will make a mistake and sometimes don't even know the difference. It's better to enforce it. If they have other tasks on the site that they don't need secure acces for it's beter for them to have another less privileged account for that, so the switching will be between different accounts, and not only a letter in the url.

--

The difference between user 1 and user N is only that user 1 cannot be demoted to normal user privileges is the only difference. If I create a role "admin" that has all privileges available, any user can be promoted to that role, and is potentially as dangerous as user 1.

A large difference to me would be that the administrator users would be stored in a different database table, with independent access control from the normal users of the site.

more relevant work

greggles's picture

I'd love to see a project for the SoC that deals with security. It's a great area for students to expand their knowledge.

There is also the Secure Pages Hijack Prevention module which attempts to provide a different solution - setting a "secure only" cookie and then rejecting the session if it fails to provide that cookie on https pages.

The Secure Pages Hijack Prevention solution to the problem creates less load on the server than the solution you provide of using roles. I'm not sure if the role based solution provides much additional benefit.

--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book

Greggles, thank you for your

jadwigo's picture

Greggles, thank you for your comment too.

I lookes at Secure Pages Hijack Prevention too, but discarded it because one of the requirements for me was that some information on the site would be only available over SSL connections to users that have access to that information. ( http://drupal.org/node/365761 )
In my case it was user profile information - a phone number and the email adress of a user - that was only available to the owner of a profile and administrators.

For a general use case this might be a bit far fetched, and in that case the Secure Pages Hijack Prevention module could be adequate.

--

I guess if a SoC project dealing with security would have to be a little bit larger than only this use case it would have to be something along the lines of integrating / combining all three modules (securepages + hijack and secure login) into a project and providing documentation and use cases...

Very pleased to find this

pbowyer's picture

Very pleased to find this thread. I'd been asked this morning if I could secure areas of a Drupal site to remain under HTTPS after logging in - but links to other sections to rever to HTTP. This seems not to be possible at present - as you say the lack of distinction between admin areas and the 'main site' makes it hard.

Looking forward to seeing what comes from your discussion.

Peter

Cracking Drupal Article

johnbarclay's picture

I also found this article on SSL and Drupal useful:

Drupal and SSL - Multiple Recipes to Possible Solutions

http://crackingdrupal.com/blog/greggles/drupal-and-ssl-multiple-recipes-...

SSL secure admin

Tigerboy's picture

funny it is too small a project to add SSL secure 100 percent of ADMIN from logon until end session but yet this micro project is still left undone. Drupal has become a mess with undone or never done projects and very difficult to find support on many issues. There is nothing more important than admin security and SSL properly done offers a great part of that. I have used securepages but then it bounces me out to none ssl at the point where I change an admin password... that is very bad.

It would take less than half a day yet months later it's still not done.