This is a port of the anti-hijacking patch for Drupal 6. Without this countermeasure against session hijacking, the protection afforded by securepages is easily bypassed.

Related issue for Drupal 5: http://drupal.org/node/284132
Original issue for Drupal 4.7: http://drupal.org/node/66970

bjaspan:The attached patch makes Secure Pages able to detect and prevent hijacked sessions from accessing SSL pages. See http://drupal.org/node/65371#comment-123944 for my explanation of how it works and why it is useful.

CommentFileSizeAuthor
#7 securepages-hijack-D6.patch8.03 KBgrendzy
#6 securepages-hijack-D6.patch4.47 KBgrendzy
securepages-hijack-D6.patch3.91 KBgrendzy

Comments

niklp’s picture

niklp commented

Subscribing (sorry!)

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
commented

I've been using this patch on several sites for a few weeks now. It appears to work as advertised.

One comment though, getting kicked out of the admin session when enabling secure pages (with this patch applied) is a bit scary, and the user should probably be better prepared for this experience.

armyofda12mnkeys’s picture

armyofda12mnkeys commented

cookie.session_secure has to be enabled right to use this patch? Pretty sure, but just wanted to get a nod.

Also in http://drupal.org/node/170310... is this a patch needed or Secure Pages patch does the same thing and changes the session to use different name? aka if you werent using Secure Pages and running your own rewrites, then you'd want that patch installed maybe?

Thanks!
Arian

grendzy’s picture

grendzy commented

cookie.session_secure has to be enabled right to use this patch?

You don't need this option, no. This patch creates a second cookie with the secure flag set by the module. The session cookie is not secured. In fact, enabling cookie.session_secure would defeat the purpose of this patch - which is to make it reasonably safe to run a site with some, but not all, SSL pages.

If you do enable cookie.session_secure, what will happen is logged in users will no longer be logged in when visiting non-SSL pages. This is a problem if you have the securepages "redirect back to http" option checked. Users would basically get booted out when they are redirected to http.

To be clear - this proposed patch does not prevent session hijacking, since the session cookie is not secured. This is by design. What it does instead, is allow hijacked sessions to be detected, and blocked from accessing SSL-protected pages.

IMO, this is actually more useful -- because you can redirect back and forth, and stay logged in. The fact that hijacked sessions can access unprotected pages is of little consequence, because if those pages contained sensitive information / actions you would include them in your SSL protected list!

Now, one could make the argument that this patch is obviated by the support in core for cookie.session_secure. As I said, I think this patch is more useful, but I'd be interested in hearing opinions from the group.

grendzy’s picture

grendzy commented

A revised patch, with some refinements:

  • Keeping up with HEAD
  • Added a #submit callback to the settings form, that automatically sets the cookie when hijack prevention is enabled for the first time. This addresses the usability issue mentioned in #2.
  • Set the 403 Forbidden header when called for
  • Tightened up the formatting to meet Drupal standards.
grendzy’s picture

grendzy commented
StatusFileSize
new securepages-hijack-D6.patch4.47 KB
grendzy’s picture

grendzy commented
StatusFileSize
new securepages-hijack-D6.patch8.03 KB

One more refinement, I added a hook_requirements() to warn users if their site is vulnerable to session hijacking.

grendzy’s picture

grendzy commented
Status: Needs review » Fixed

This patch has been re-packaged as a stand-alone module:
http://drupal.org/project/securepages_prevent_hijack

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.