(D6) Preventing hijacked sessions from accessing SSL page [#286499]

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.

Comment	File	Size	Author
#7	securepages-hijack-D6.patch	8.03 KB	grendzy
#6	securepages-hijack-D6.patch	4.47 KB	grendzy
	securepages-hijack-D6.patch	3.91 KB	grendzy

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

NikLP CreditAttribution: NikLP commented 25 July 2008 at 00:06

Subscribing (sorry!)

Comment #2

jhedstrom

English

Portland, OR

CreditAttribution: jhedstrom commented 4 August 2008 at 18:23

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.

Comment #3

armyofda12mnkeys CreditAttribution: armyofda12mnkeys commented 28 October 2008 at 16:12

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

Comment #4

grendzy CreditAttribution: grendzy commented 28 October 2008 at 17:55

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.

Comment #5

grendzy CreditAttribution: grendzy commented 5 December 2008 at 20:27

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.