use_trans_sid not working for cookie-disabled users

molesquirrel

So, with a firm understanding of the security risks inherent with url-passed session ids, I still would like to make this available for the .1% of my user base that has cookies disabled (or whatever). Everyone with cookies would still use cookie based session ids, so there wouldn't be a problem with them, right?

Anyhow, working with php 4.3.11. These are the relevant settings in php.ini

url_rewriter.tags a=href,area=href,frame=src,input=src,form=fakeentry
session.use_cookies On
session.use_only_cookies Off
session.use_trans_sid On

I've got Internet Explorer 6 with cookies turned completely off. I set up a couple of stupid little test pages for this, since the actual site is a mess of code, and I wanted to localize the problem at hand:

test1.php

<?php
session_start();
?>
<a href='test2.php'>test2</a>

test2.php

<?php
session_start();
?>
<a href='test1.php'>test1</a>

Of course, I don't see PHPSESSID appearing on any of the links.

As a side note, I noticed that the sids were being propagated in a local install of phpbb, but when I perused that code base, it looked like they used an append_sid() function about a million times. Surely that's not necessary, is it?

toplay

Everything you said is fine. Make sure you close your browser before each test so any left over cookie is deleted (assuming of course that 'session.cookie_lifetime' is set to zero).

I would display the SID constant. If it echoes out the session name and ID, then the cookie was NOT created. If it's empty, then there's still session cookies being created. Example:

test1.php

<?php 

session_start();

if (!isSet($_SESSION['cnt']))
    $_SESSION['cnt'] = (int) 0;

echo 'SID = ', SID, '<br>';
?>

<a href="test2.php">test2</a>

test2.php

<?php 

session_start();

if (isSet($_SESSION['cnt']))
    $_SESSION['cnt']++;
else
    $_SESSION['cnt'] = (int) 0;

echo 'SID = ', SID, '<br>';

echo 'Count is: ', $_SESSION['cnt'], '<br>';  // Should display 1, 2, 3, etc.

?>

<a href="test1.php">test1</a>

Let us know the results of this test.

molesquirrel

Very interesting results. First off, thanks for the response. In firefox, where I had cookies enabled, it exhibited the response you mentione of having "SID = ". In IE, with cookies disabled, it displayed "SID = PHPSESSID=bf44959b6bea618f0b45f876db01233d", and when I click on the links, the urls have been rewritten to as to include the phpsessid.

Now, that leaves me with the gap between these simple test pages and the rather complex site that is not exhibiting this behavior. I'll see what I can do to disable one module at a time until I can get the expected behavior to appear, and report back. The only thing off the top of my head that I can think of is this: would output buffering affect the url rewriting? I do use ob_start and ob_end_flush, passing a function into ob_start so it can catch fatal errors (and allow cookies to be set).

molesquirrel

Well, I spoke too soon. Here's a loose version of my site:


//this is inside of a TemplateEngine object, hence the $this
ob_start($this,'parse_buffer');

//the page runs, blah blah

ob_end_flush();

This is also in the class:

	function parse_buffer($buffer)
	{
		if (ereg("(error</b>:)(.+)(<br)", $buffer, $regs))
		{
			trigger_error('Fatal error caught: ' . $regs[2]);
		}
		else
		{
			if( function_exists('ob_gzhandler') )
				return ob_gzhandler($buffer, 5);
			else
				return $buffer;
		}
	}

Now, I need this function to be called so it can grab fatal errors, but I also want the output to be compressed. If I short-circuit the if/else conditional and simply return the buffer, the rewriting takes place. If I run ob_gzhandler, then no rewriting. So, I guess I'm stuck with finding an alternate method of gzipping up the material on the way out. Any ideas?

toplay

molesquirrel wrote:
Very interesting results. First off, thanks for the response. In firefox, where I had cookies enabled, it exhibited the response you mentione of having "SID = ". In IE, with cookies disabled, it displayed "SID = PHPSESSID=bf44959b6bea618f0b45f876db01233d", and when I click on the links, the urls have been rewritten to as to include the phpsessid.

Now, that leaves me with the gap between these simple test pages and the rather complex site that is not exhibiting this behavior. I'll see what I can do to disable one module at a time until I can get the expected behavior to appear, and report back. The only thing off the top of my head that I can think of is this: would output buffering affect the url rewriting? I do use ob_start and ob_end_flush, passing a function into ob_start so it can catch fatal errors (and allow cookies to be set).

So, your test is behaving like I would expect in FF and IE considering the settings of cookies enabled and disabled.

No, output buffering should have no impact on this issue. However, please note that you have to pass manually the session name and ID on any redirects you have. That's where the SID constant comes in handy. You can use it without any 'if' conditions. Example:

header('Location: http://www.example.com/script.php?' . SID);
exit;

In your FF test, the SID will be empty and the session name & ID will not appear in the URL. With IE and the same code, it will show and pass the session name and ID (which is what you want when a session cookie couldn't be created).

FYI - Please note that the header() with location command does not redirect right there and then when it's executed. It actually redirects when your script ends or an exit is reached. So, to ensure no logic flow problems in your script, you should have an exit right after every header() with location to force redirection to occur immediately.

toplay

I can't see how this ever worked:

ob_start($this,'parse_buffer');

For it to call the right method/function within the class, it should be like this:

ob_start(array(&$this, 'parse_buffer'));

hth.

molesquirrel

Whoops, misread the code. It's actually this:

ob_start(array($this,'parse_buffer')); //for error handling

Anyhow, I'll let you know if I come up with anything else from this gzipping business.

toplay

molesquirrel wrote:
Whoops, misread the code. It's actually this:
ob_start(array($this,'parse_buffer')); //for error handling
Anyhow, I'll let you know if I come up with anything else from this gzipping business.

It's best to have it with the '&' as I showed in my previous post.

molesquirrel

Alright, so I made a lot of headway. Essentially, I stopped using the ob_gzhandler, and switched to zlib.output_compression to On. This allows the url writing to take place, huzzah!

This opens up a smaller but still obnoxious problem. I use a dhtml tooltips library that allows for fun little tooltips with html in them. A few of them have popup forms. The function call is something like:

<a href='blah' onmouseover="ttip(this,'tooltipcontents');">link</a>

tooltipcontents can contain plain text or html. In this particular case, it has a form, input tags, the whole thing. Because of this, the url writer adds a hidden PHPSESSID value into the form. No problem, right? Unfortunately, it comes in the form:

<input type="hidden" name="PHPSESSID" value="5e11b4c585801298281c49e2093080de" />

All those double quotes break the literal string in the ttip() call, and...well..blech. I've tried using the following in .htaccess

php_value url_rewriter.tags a=href,area=href,frame=src,input=src,form=action

and it properly adds it to the action value (default is form=fakeentry), but it also adds the hidden value. Any idea as to how to circumvent this?