Improving the security of Drupal's securepages module
A common scenario we encounter is where the bulk of a site's traffic is anonymous users, for whom it would be an unnecessary burden on the server to transfer pages with SSL. However, it is still desirable to serve some parts of the site with SSL (typically the admin pages, or perhaps some commerce-related pages). Luckily, the securepages module accomplishes this nicely.
This approach has a drawback, however. The same session cookie is used to access both SSL and non-SSL pages. Since this cookie is passed around in plaintext, it's easily hijacked by an attacker, who can then access your SSL-protected pages with the hijacked session.
Druapl contributor bjaspan has written an excellent patch for the securepages module which prevents this, by setting a separate cookie used only on SSL pages. I have ported the patch to Drupal 5 and Drupal 6, along with some improvements. If you are using securepages, please consider trying this out and posting some feedback: http://drupal.org/node/286499
There are still a few caveats:
- Serving mixed SSL and non-SSL content is tricky, and fraught with peril. Don't rule out running your site 100% on SSL -- for a moderately trafficked site the overhead is less than you might think. This is still the most secure option.
- You still must be careful to use relative paths, so that your SSL pages don't contain any inline content that's unencrypted. An unencrypted javascript file could be particularly deadly, but images and other files matter too.
- This patch does not prevent hijacking in general, since you are still serving some pages unencrypted. It only prevents hijacked sessions from accessing your designated secure pages.

Comments
Cross domain javascript?
In my limited experience on this issue, the browser should consider javascript running from a non-ssl version of a site, to be cross domain, and prevent any issues, if the page itself is served via ssl. See some issues that people have had with trying to use scurepages module to serve node/add/* via SSL, and then their FCK/IMCE/ breaks, because some of it's AJAX work is making non-ssl requests.
Post new comment