[Phplib-users] block fake user-provoded session

[Giancarlo P. <gia...@na...>]

I've tried it, but things should be changed since that, because now it
works only in cookie mode.

I base myself on 4 tests, 2 with cookie enabled and two without. I use
Netscape and while enabling/disabling cookies, I keep 'warn me when a
cookie is issued', so I can see them.
Between each test, I close the browser and have a script that erases all
cookies.

For the 4 tests I use the latest php-lib-stable from the cvs, opening
the 'simple page' provided in the distribution. In both modes (cookies
enabled and disabled) I try the bare URL (index.php3) and one with a
fake session appended. Every new test with the fake session is done
modifying its value, eg adding a letter or a number, so that the session
is not eventually found, as it should be if provided by the user.
In The index.php3 I echo the session sid as a check.

the test and the expected results are
1) clean cookies. Start browser. Open index.php3, cookies enabled. This
should work pretty straight anyway, URL with session the very first
time, counter increases. I should see a single warn for a cookie left.

2) clean cookies. restart browser, index.php3?Example_Session=byebye: 
-I should see a cookie left on the browser (get has not to be forced by
user) 
-its value must NOT be 'byebye', (sid has not to be forced by user)
-the page is redirected to itself with the correct session in the UrL
too (the 302 cookie test needs that)
-the counter increases

3)Restart browser, disable cookies. Open index.php3
-I should be redirected to index.php3 with a new  session written in the
URL. Further reload increase counter

4)Cookies disabled. Open index.php3?Example_Session=byebye22
-I should be redirected to index.php3 with a correct session in the URL
(sid has not to be forced by user). Further reloads increase counter.

Now that test on the existence of a sid does not work in get mode for
various reason. First because when the id is found in the url, even if
it does not exists, you are never redirected to the newly generated url.
By the code now, that situation occurs only if there no Session in the
url.

Before the 302 redirect, there is no freeze, so you'll never find a
newly created session that has been redirected to itself with it in the
URL. 
The trick is to $this->freeze before the 302.
And not to be mislead by the presence of a session in the URL, leave a
cookie in any case, get too. And a few other changes that I applied.

Anyone interested can see the patch at the phplib project on
sourceforge.
http://sourceforge.net/tracker/index.php?func=detail&aid=563700&group_id=31885&atid=403613
The patched session.inc has an added session variable
var block_bogus_sid = true;
This commands all the behavior. 
At the moment it passes all 4 tests on true (blocking ON).
On false (no blocking applied) test no 2 gets the fake cookie release
twice. I'll check that.
There's some overhead, a read at every page to see if session exists.
My previous patch didn't have this, because it was based on the idea of
'signin' every 'original' session with a fingerprint, so that post-and
create session would not have it. But I prefer this, is more clean.

Also I've seen that the situate between the release_token and get_id
functions is getting quite complicate.  get_id was first supposed to be
invoked after release_token, but now release token invokes get_id too. 

Peter Kursawe wrote:
> 
> Hallo Gian,
> 
> > Can we control that a new session id has been effectively issued by us,
> > and only create new session id that we have generated?
> 
> I included in my session.inc ( as of $Id: session.inc,v 1.7 2001/07/09 15:33:29) the following code
> in function get_id after the first if ( "" == $id ) { ... }:
> 
> ---- snip ----
> 
>     if($id != "") {   # somehow an id was provided by the user
>        if($this->that->ac_get_value($id, $this->name) == "") {
>           # no - the id doesn't exist in the database: Ignore it!
>           $id = "";
>        }
>     }
> 
> ---- snip ----
> 
> in the next if ( "" == $id ) the programm then generates a new id.
> 
> Disclaimer: I am not sure if this behaviour is safe and I do not know if subsequent versions of phplib
> have taken care of this problem.
> 
> Peter Kursawe
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users