By castellan on

A significant luddite movement has formed in my organization since the implementation of Drupal. They're demanding the removal of any cookie requirements at all from our site.

Frankly, I'm unsympathetic. However, for the sake of completeness, what is the likelihood of a Drupal installation without any cookies at all? Does it work? Yes? No?

Thanks!

⋅ Categories: Drupal 4.6.x

Comments

kae’s picture

kae commented

i've wondered about this

markus_petrux’s picture

markus_petrux commented

Drupal needs a method to pass the session id between requests, otherwise, f.e. you cannot stay logged in. This is done by setting a cookie (named by default PHPSESSID, but it can be changed) or appending PHPSESSID=session_id to all URLs, which depends on PHP settings.

Note that once you have been logged in, you need to pass the PHPSESSID to the server, so Drupal knows who you are. Using cookies is cleaner (URLs are cleaner) and also safer! Anyone could use the PHPSESSID of any logged in user to impersonate that user (this is called session hijacking, [more]). It is much easier to get anyone else's PHPSESSID if it is passed via URL (posting links, referrers, logs, etc.). If the PHPSESSID is passed only via cookies, the attacker would have to use another kind of exploit to get that information (protected by browser settings, security zones, etc) like say cross-site scripting, etc.

Doubt is the beginning, not the end of wisdom.

castellan’s picture

castellan commented

This is a good basic summary of how cookies work, but it doesn't really address the overall question: can I disable cookies at the server and get Drupal to work? The whole point is for people who want to leave cookies disabled or whose companies have blocked cookies at the firewall to be able to log into the system.

I'm not interested in actually doing this. But the folks who are demanding this want what they want. I'm trying to explore the options to make sure that I've covered my bases.

If Drupal can do this, how do I set it up? If not, why can't it? I'm not trying to be critical of your explanation or of Drupal's ability (I did choose it over other CMSs, after all!). I just want to be sure I'm as well-educated on Drupal's abilities as possible.

Thanks!

binford2k’s picture

binford2k commented

I think that what he is saying is that Drupal doesn't care how PHP handles the session. To find out more, you should read up on sessions at http://us3.php.net/manual/en/ref.session.php

Why not try setting session.use_cookies to 0 in your .htaccess file and see if that does the trick.

markus_petrux’s picture

markus_petrux commented

My answer was aimed to comment about a security related issue related to your question. I don't know anything about you or the motivation of those that request such a "feature". I just felt the need to point that out. It is not up to me to secure anyone else's site. ;-)

Second, yeah, Drupal uses custom session handlers, but that's still part of the PHP session APIs. session settings are configured at PHP level.

Doubt is the beginning, not the end of wisdom.

geme4472’s picture

geme4472 commented

Thanks markus_petrux for the clarifying info on sessions. I am replying in order to muddy the waters even further...

Only yesterday I received a report from a client's security group within IT (ugh!). They relayed the following to me:

Vulnerability 1: User Impersonation - Session ID Management

The first issue is related to the handling of session ids (SIDs) by the web server. When a user connects to the web server, a random SID is generated by the web server and provided to the client in the form of a session cookie. This SID is used by the server to determine who is connected and what privileges they have within the application. If a malicious user is able to obtain the SID of another user, they could impersonate that user and perhaps have access to information beyond their privilege level.

Any thoughts?

markus_petrux’s picture

markus_petrux commented

http://drupal.org/node/19845

Doubt is the beginning, not the end of wisdom.

geme4472’s picture

geme4472 commented

quick question. After reading the thread you posted above, it is quite obvious that you're the person with whom I need to speak...

It seems to me (which means very little) that when you set session.cookie_lifetime to 0, the cookies are never created locally. Now, admittedly, that makes no sense if drupal requires the cookie for authentication on every page load, but with the sites I have running session.cookie_lifetime 0, I can't seem to make/find any cookies (except seeing them through javascript).

If the cookies are never permanently stored on the local machine, is the only real way to get a SID and thereafter hijack via XSS? If so, a combination of the new >4.6.6 drupal release and good input filters should go a long way towards security, no? Also, throw in a batch of https. All my client sites are under SSL. Perhaps I am just trying to make myself feel better?

Or should I just shut up and use your include file from http://drupal.org/node/19845? I've read that thread back and forth and it makes my head ache. Too many differing opinions on things about which I know so very little!

Thanks for all your help.

markus_petrux’s picture

markus_petrux commented

It seems to me (which means very little) that when you set session.cookie_lifetime to 0, the cookies are never created locally. Now, admittedly, that makes no sense if drupal requires the cookie for authentication on every page load, but with the sites I have running session.cookie_lifetime 0, I can't seem to make/find any cookies (except seeing them through javascript).

That's right. session.cookie_lifetime in the PHP manual: The value 0 means "until the browser is closed.".

But there is another consideration. If you open a new browser window from the desktop, that's another instance of the application that may not have accesss to the memory of the previous instance, where the cookie was stored, so the user could be logged in on one instance and logged out on the other. This problem might happen ...and is really confusing. It doesn't happen if the new browser window is opened from the browser itself (it is the same application instance) or it is opened within a tab.

...or it might not happen if session.cookie_lifetime is set to an arbritrary value greater than 0, say 3600 seconds (1 hour) or 84600 (1 day), etc. The cookie is written to disk (and updated for each page load) so it is probably accessible from all instances of the browser application. The one caveat here is if the user is using a shared computer. Ideally, Drupal would have to ask the tipical "remember me" in the login form (as other web applications do) and set session.cookie_lifetime accordingly.

If the cookies are never permanently stored on the local machine, is the only real way to get a SID and thereafter hijack via XSS?

Any cookie could potentially be accessible, depending on how the attack is deployed.

All my client sites are under SSL. Perhaps I am just trying to make myself feel better?

SSL doesn't protect from session fixation/hijacking. SSL encrypts the communication between the client and the server, that protects from a "man in the middle" kind of attack, but XSS is still possible... or another vector opened from a browser bug. All they need to be is up to date in browser vulnerabilities. ie. the fresh and new createTextRange vuln. in MSIE (22sd March), with known exploits in the wild and officially unpatched until next 11th April. And that happens every now and then. This is, of course, beyond anything Drupal could do, but hey, such a vuln. could avail the oportunity to hijack a session, but at least that could be prevented from code such as the fix I posted in that issue.

Or should I just shut up and use your include file from http://drupal.org/node/19845? I've read that thread back and forth and it makes my head ache. Too many differing opinions on things about which I know so very little!

Ah, that fix may protect from session hijacking (and offer better protection against session fixation, it would cover gaps opened from modules such as logintoboggan, etc.), but then again, this is something that in my opinion should be included into core. Otherwise the fix may get out of sync with core, hence it could generate a false sense of security. Also, if you choose to use it, think about users behind proxy farms (the famous issue :-), they may get sudenly logged out, oh well. Other web applications offer this kind if protection (against session hijacking).

PS: I hardly monitor the forums, although it was closed, maybe better to move any discussion to that issue?

Doubt is the beginning, not the end of wisdom.

geme4472’s picture

geme4472 commented

Salutations, markus_petrux, and thanks for your excellent reply. I'd move this conversation to node/19845, but it doesn't quite align with the conversation there, since I'm asking naive questions, and that group seems pretty well informed.

One more thought for you. If one was to use session.cookie_lifetime 0 and only allowed one session per user via the session_limit module, would that circumnavigate the need for session fingerprinting?

anders.fajerson’s picture

anders.fajerson commented

I'm also interested in this, in my case for the ability to retrieve authenticated feeds.

My dream scenario would be to use securesite to handle the authenticaten with http_auth, and it should be possible to do that in a clean way without cookies.

castellan’s picture

castellan commented

Strangely, on my test server, logging into Drupal is not possible without cookies. I've tried various combinations of turning cookies off in Apache, and disabling cookies in the browser.

So, if Drupal is supposed to be sending session data on the URL when cookies aren't available, why isn't it? Is there a setting I am not seeing in the configuration files?

erdemkose’s picture

erdemkose commented

There are 2 configuration options about cookies in sites/default/settings.php.

ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid',    0);

Add one more directive to force PHP not to use cookies.
Also You should change 1->0 and 0->1

ini_set('session.use_cookies', 0);
ini_set('session.use_only_cookies', 0);
ini_set('session.use_trans_sid',    1);

This MAY work. It is not certain because Drupal makes lots of things with URL. And if you use sessions without cookies and your logs will be full of session keys. But at least try it.

--------------------------------------------------------------
http://www.students.itu.edu.tr/~koseer/drupal/ - works on PHP-TXT-DB database layer.

paddywwoof’s picture

paddywwoof commented

There seems to be something else needed to get this to work on IIS. On an apache site I can just swap the use_only_cookies and use_trans_sid over but the people wanting to do without cookies are hosted on windows!

Incidentally the argument against cookies is because the site will be used significantly by people travelling and logging in from internet cafes. In my experience these all have cookies switched on - what is the real situation and security risk?

styro’s picture

styro commented

Incidentally the argument against cookies is because the site will be used significantly by people travelling and logging in from internet cafes. In my experience these all have cookies switched on - what is the real situation and security risk?

Cookies are probably no real increase in risk - the internet cafes are probably full of keystroke loggers anyway ;)

Changing to session cookies that vanish after closing the browser would probably be a small step in the right direction. eg like Outlook Web Access 2003 does - actually it asks you whether you are logging in from a public place.

There's not many good answers for securing access from untrusted machines. Some bigger more drastic steps (that might not be allowed in some more restricted internet cafes):

Could you possibly supply them with (or show them how to use) Firefox from a USB key?

Or get them to boot from a live CD (eg a CD based Linux distro) to do their browsing?

--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Example Knowledge Base built using Drupal

WonderClown’s picture

WonderClown commented

I was able to disable cookies and enable URL-based session IDs with the right stuff in settings.php, but this is not really what I want. My site is entirely public except for the administrator features. I do not want to use cookies for most visitors, and I really have no need to track their sessions either. Ideally I would like to use cookies to create sessions only when authentication is required (i.e., administrator logins), and not do any session management (neither cookies nor URL-based) otherwise. Is this possible?

paddywwoof’s picture

paddywwoof commented

I have managed to sort something out on this problem if anyone is interested:

http://drupal.org/node/58019

www.eldwick.org.uk