phplib-users — A list for users of phplib to talk / discuss phplib

Re[2]: [Phplib-users] new Session4 changes

[Maxim D. <max...@bo...>]

You talk about implementations, while I pointed out the overall
session strategy limitations. The *implementations* You mentioned use
the same basics, the main of them is HTTP, which is unreliable,
because of it has no *internal* state handling - cookies were invented
to help but they don't always function, as we know. If the HTTP
protocol had its internal session handling, there would be much less
buttache to make the session work reliably and secure. And there could
be 1000+ session implementations in PHP, but all they would be like
twins from the network point of view. That's why the most of them would act
just like backends for the standard PHP session module - just like
another savehandler - because nobody wants to reinvent bicycles. All
the logic needed to implement state propagation has been already coded
there. And weaknesses and unreliability is in the heart of the whole
system - HTTP. the PHP core guys could make the module to check whether the
SID already exists before starting a new session and many more, but
the performance and/or flexibility would suffer, so they preferred to be
wise and leave the exact implementation of security constraints to the users.
And every descent session module, even if it will use its own
start() and SID propagation logic, will face the same dilemma.
Something tells me that the good extensions will go the standard way.


G> Look, now there the msession module that seems to suit different needs.
G> There may come others. That is in fact just one of many session modules, 
G> and with some tight-tied constraints. If you canno't have ir regenerate 
G> into a new session, most mutancy, which means flexibility, is lost. I 
G> saw a php SOAP php module on sourceforge that first and only things it 
G> does is session.





-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re: [Phplib-users] new Session4 changes

[Richard A. <rh...@ju...>]

At 12:39 +0100 2/12/02, Giancarlo wrote:

>Ignorant question: is these something that is going, without user
>knowledge, store URL requests, or is that only true for httpd proxy
>servers? Or we can be under an https or socks proxy without knowing or
>having set anything special. This is about the supposedly encrypted
>QUERY_STRING in an https request being forwarded by proxies.

I use to use an ISP which transparently proxied all traffic -- http
and https. I know this because it broke my internet banking and I had
to change ISPs.

I have no idea why they proxied https... the proxy just tunnels the
requests through to the origin server and no caching can take place.

Any ISPs which run caching proxy servers behind a load balancer will
break any IP address based session scheme. And I hear there are more
of these caches being installed as major ISPs in the US struggle to
remain (become?) profitable in the face of thinning margins.

 ...R.

Re: [Phplib-users] new Session4 changes

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

  > Maxim Derkachev wrote:
  >
  >> =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, Giancarlo,
  >>
  >> The old PHPLib's Session class is damn slow compared to the native P=
HP4
  >> sessions.

I think that comes from the save_handler most of all

  >> 1. The check for session existence is trivial. In my addition to the
  >> Session4 the session exists if the originator's IP is registered wit=
h

Why not 'preissue' a fair enough number of 'second_half of session
info', and save them in the session, so  that only one among those can
be appended or cookie_appended? Use once
random md5 digests. Would that  be really bullet_proof..


  >> the session. If we have a SID in the request and don't have *any* IP=
 in
  >> the session, the session does not exist, so the SID should be
  >> omitted and the new session with the new random SID should be emitte=
d.


  >> 2. We should always try to avoid extra redirects - the main reason i=
s
  >> that those redirects can be misunderstood by the search robots,

This problematic is really at the opposite of the one regarding privacy
and hijacking. That's why you may want more mutations, and more fallback
paths, depending on the situation. Afterall if you have private areas
accessible from anything between cookieless_always_authenticated and
cookie_only_always_reauth (or any mix), and also want robots to sneak
around safe, you need possibility to mutate the policy in different ways=20
for the cases, no one can fit all.


and
  >> the site will not be properly indexed.
  >> 3. We should do something so that session hijacks could be made
  >> [almost] impossible. The old Session class has the same issue and th=
e
  >> session can be hijacked using both PHPLib's Session3 and PHP4 sessio=
n
  >> module weaknesses. The only way I see is to bind the session under s=
ome
  >> circumstances to a marker that can not be forged. The only such a
  >> marker I see is the user's IP address - the others can be easily
  >> rewritten in the request variables. Given that the cookie is one of =
the
  >> hardest thing to forge (just because the nature of the attack - the
  >> attacker tries to persuade the victim to click an URL), we can ease
  >> the restrictions for cookie users.
  >>
  >> So, the site with such restrictive policy could recommend cookies to
  >> everybody and enforce cookie usage by all users that may change thei=
r
  >> IP during the session.
  >>
  >>
  >>
  >
  >

Re: [Phplib-users] new Session4 changes

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

Look, now there the msession module that seems to suit different needs.=20
There may come others. That is in fact just one of many session modules,=20
and with some tight-tied constraints. If you canno't have ir regenerate=20
into a new session, most mutancy, which means flexibility, is lost. I=20
saw a php SOAP php module on sourceforge that first and only things it=20
does is session.


Maxim Derkachev wrote:
> =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, Giancarlo,
>=20
> G> It supposes that in any moment, header problems apart, you can creat=
e a
> G> new session, and then start it. This is what actually is missed in p=
hp4=20
> G> session. We could keep this pieces of code, because the php4 session=
=20
> G> module is afterall an 'optional' module. And phplib's code is known =
to=20
> G> work for years, and gives a better control, so I'dnt throw it away s=
o=20
> G> mindlessly.
>=20
> The old PHPLib's Session class is damn slow compared to the native PHP4
> sessions. So, In My Considered Opinion, there is no way back to the
> "PHPLib for PHP3" Session class usage, it is just the history now.
> And the only reason to use Session class *interface* instead of using
> PHP's session functions explicitly is the nice abstraction, just like
> a "control panel" for tuning the module parameters, cause the module
> is quite complicated and confusing for the unexperienced users.
> 1. The check for session existence is trivial. In my addition to the
> Session4 the session exists if the originator's IP is registered with
> the session. If we have a SID in the request and don't have *any* IP in
> the session, the session does not exist, so the SID should be
> omitted and the new session with the new random SID should be emitted.
> 2. We should always try to avoid extra redirects - the main reason is
> that those redirects can be misunderstood by the search robots, and
> the site will not be properly indexed.
> 3. We should do something so that session hijacks could be made
> [almost] impossible. The old Session class has the same issue and the
> session can be hijacked using both PHPLib's Session3 and PHP4 session
> module weaknesses. The only way I see is to bind the session under some
> circumstances to a marker that can not be forged. The only such a
> marker I see is the user's IP address - the others can be easily
> rewritten in the request variables. Given that the cookie is one of the
> hardest thing to forge (just because the nature of the attack - the
> attacker tries to persuade the victim to click an URL), we can ease
> the restrictions for cookie users.
>=20
> So, the site with such restrictive policy could recommend cookies to
> everybody and enforce cookie usage by all users that may change their
> IP during the session.
>=20
>=20
>=20

Re[2]: [Phplib-users] new Session4 changes | more

[Maxim D. <max...@bo...>]

Hello Giancarlo,

Monday, December 02, 2002, 2:34:00 PM, you wrote:
G> What is really good in php4 session is the URL rewriting ;-)
G> that is something I would like to have built in, but I am not sure one 
G> can wedge PHPLIB's propagation code (so a custom session_start ?), use a 
G> custom_savehandler for storage (is it possible without a session_start 
G> ?), and still use the PHP4 url_rewrite feature.

No. It is not possible without the session_start - it triggers all
the actions performed for URL rewriting, running the custom
savehandler and more. What we do is just making that custom extended
session_start in Session::start :))


-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re[2]: [Phplib-users] new Session4 changes

[Maxim D. <max...@bo...>]

Здравствуйте, Giancarlo,

G> It supposes that in any moment, header problems apart, you can create a
G> new session, and then start it. This is what actually is missed in php4 
G> session. We could keep this pieces of code, because the php4 session 
G> module is afterall an 'optional' module. And phplib's code is known to 
G> work for years, and gives a better control, so I'dnt throw it away so 
G> mindlessly.

The old PHPLib's Session class is damn slow compared to the native PHP4
sessions. So, In My Considered Opinion, there is no way back to the
"PHPLib for PHP3" Session class usage, it is just the history now.
And the only reason to use Session class *interface* instead of using
PHP's session functions explicitly is the nice abstraction, just like
a "control panel" for tuning the module parameters, cause the module
is quite complicated and confusing for the unexperienced users.
1. The check for session existence is trivial. In my addition to the
Session4 the session exists if the originator's IP is registered with
the session. If we have a SID in the request and don't have *any* IP in
the session, the session does not exist, so the SID should be
omitted and the new session with the new random SID should be emitted.
2. We should always try to avoid extra redirects - the main reason is
that those redirects can be misunderstood by the search robots, and
the site will not be properly indexed.
3. We should do something so that session hijacks could be made
[almost] impossible. The old Session class has the same issue and the
session can be hijacked using both PHPLib's Session3 and PHP4 session
module weaknesses. The only way I see is to bind the session under some
circumstances to a marker that can not be forged. The only such a
marker I see is the user's IP address - the others can be easily
rewritten in the request variables. Given that the cookie is one of the
hardest thing to forge (just because the nature of the attack - the
attacker tries to persuade the victim to click an URL), we can ease
the restrictions for cookie users.

So, the site with such restrictive policy could recommend cookies to
everybody and enforce cookie usage by all users that may change their
IP during the session.



-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re: [Phplib-users] new Session4 changes | more

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

 >> Currently the logic in the session module (php3) was:
 >>
 >> if there is no cookie, see if there is a GET sid
 >>   if there is a get sid, accept that anycase
 >
 >
 >       +++ create or update the session
 >
 >>   if tgere's not a GET sid, append a GET sid, leave a cookie as well,
 >>       redirect to Self (with sid appended). On reentering, it is back
 >> to       start
 >
 >
 >       +++ no session creation was made if nothing found, just the
 >           redirect
 >
...

 >> The logic I applied to somehow block the aliens was:
 >>
 >> if there is no cookie see if there'a a GET sid
 >>   if there's a GET sid, see if that exists
 >>     if that no exists, create&freeze a new session, leave the new
 >>        cookie, append sid to GET, redirect to there
 >>   if there's no GET sid, ceate&freeze a new sess, append sid to GET and
 >>      leave a cookie, and redirect to there
 >>  if there's cookie, see if it exists, if not: recookie, redirect to self
 >>
...

 > So the base for checking the preexistance was to create & save, in case
 > a new session, BEFORE redirect, not create_or_update AFTER, as it was
 >
...

PHP4 session is a third example of flow:

it creates or udates the session in any case, before any redirect, no
check if exists or not exists. There seem not to be a redirect when
nothing is found. The first time, with nothing found, url (trans_sid)
are rewritten in  anycase, a cookie is left just_in_case. No SID is
appended to SELF, nor redirect. So if you ghit browser reload with
cookies disabled, counter never increases, which PHPlib didn't because
the very first visit was redirected to SELF with SIDappended & cookie.


Gian

Re: [Phplib-users] new Session4 changes

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

> RA> Well, using IP address is not a viable solution in any case.
> RA> Too many ISPs run load balancing proxy servers. Mine for instance :)

Ignorant question: is these something that is going, without user 
knowledge, store URL requests, or is that only true for httpd proxy 
servers? Or we can be under an https or socks proxy without knowing or 
having set anything special. This is about the supposedly encrypted 
QUERY_STRING in an https request being forwarded by proxies.

Gian

Re: [Phplib-users] new Session4 changes | more

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

> Currently the logic in the session module (php3) was:
> 
> if there is no cookie, see if there is a GET sid
>   if there is a get sid, accept that anycase

       +++ create or update the session

>   if tgere's not a GET sid, append a GET sid, leave a cookie as well,
>       redirect to Self (with sid appended). On reentering, it is back to 
>       start

       +++ no session creation was made if nothing found, just the
           redirect


So the base for checking the preexistance was to create & save, in case 
a new session, BEFORE redirect, not create_or_update AFTER, as it was

What is really good in php4 session is the URL rewriting ;-)
that is something I would like to have built in, but I am not sure one 
can wedge PHPLIB's propagation code (so a custom session_start ?), use a 
custom_savehandler for storage (is it possible without a session_start 
?), and still use the PHP4 url_rewrite feature..

Gian






> 
> The logic I applied to somehow block the aliens was:
> 
> if there is no cookie see if there'a a GET sid
>   if there's a GET sid, see if that exists
>     if that no exists, create&freeze a new session, leave the new
>        cookie, append sid to GET, redirect to there
>   if there's no GET sid, ceate&freeze a new sess, append sid to GET and
>      leave a cookie, and redirect to there
>  if there's cookie, see if it exists, if not: recookie, redirect to self
> 
> 
> It supposes that in any moment, header problems apart, you can create a 
> new session, and then start it. This is what actually is missed in php4 
> session. We could keep this pieces of code, because the php4 session 
> module is afterall an 'optional' module. And phplib's code is known to 
> work for years, and gives a better control, so I'dnt throw it away so 
> mindlessly.
> 
> 
> Maxim Derkachev wrote:
> 
>> Hello Rob,
>>
>> Saturday, November 30, 2002, 1:07:46 AM, you wrote:
>> RH> Currently, if cookies are not set, then you just append the 
>> session id to
>> RH> the get string.
>>
>> Well, I know that. But it does not resolve the session hijack issue.
>>
>>
>>
> 
> 

Re: [Phplib-users] new Session4 changes

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

Currently the logic in the session module (php3) was:

if there is no cookie, see if there is a GET sid
   if there is a get sid, accept that anycase
   if tgere's not a GET sid, append a GET sid, leave a cookie as well,
       redirect to Self (with sid appended). On reentering, it is back 
to start

The logic I applied to somehow block the aliens was:

if there is no cookie see if there'a a GET sid
   if there's a GET sid, see if that exists
     if that no exists, create&freeze a new session, leave the new
        cookie, append sid to GET, redirect to there
   if there's no GET sid, ceate&freeze a new sess, append sid to GET and
      leave a cookie, and redirect to there
  if there's cookie, see if it exists, if not: recookie, redirect to self


It supposes that in any moment, header problems apart, you can create a 
new session, and then start it. This is what actually is missed in php4 
session. We could keep this pieces of code, because the php4 session 
module is afterall an 'optional' module. And phplib's code is known to 
work for years, and gives a better control, so I'dnt throw it away so 
mindlessly.


Maxim Derkachev wrote:
> Hello Rob,
> 
> Saturday, November 30, 2002, 1:07:46 AM, you wrote:
> RH> Currently, if cookies are not set, then you just append the session id to
> RH> the get string.
> 
> Well, I know that. But it does not resolve the session hijack issue.
> 
> 
> 

Re[7]: [Phplib-users] new Session4 changes

[Maxim D. <max...@bo...>]

Hello Richard,

Monday, December 02, 2002, 1:35:36 PM, you wrote:
>>Well, I know that. But it does not resolve the session hijack issue.

RA> Well, using IP address is not a viable solution in any case.
RA> Too many ISPs run load balancing proxy servers. Mine for instance :)

 The check mentioned affects only cookieless clients with changing IP
 (if they change ip several times during the session, providing SID in
 url or POST body only). I suppose we could also check X-Forwarded-For ...
 In any case, a possibility to avoid session hijacks should be added,
 IMCO. The only marker I could see by now is the user's IP address -
 everything else is even less reliable.


-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re[6]: [Phplib-users] new Session4 changes

[Richard A. <rh...@ju...>]

At 11:14 +0300 2/12/02, Maxim Derkachev wrote:

>Well, I know that. But it does not resolve the session hijack issue.

Well, using IP address is not a viable solution in any case.
Too many ISPs run load balancing proxy servers. Mine for instance :)

 ...R.

Re[6]: [Phplib-users] new Session4 changes

[Maxim D. <max...@bo...>]

Hello Rob,

Saturday, November 30, 2002, 1:07:46 AM, you wrote:
RH> Currently, if cookies are not set, then you just append the session id to
RH> the get string.

Well, I know that. But it does not resolve the session hijack issue.



-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

RE: Re[4]: [Phplib-users] new Session4 changes

[Rob H. <rob...@ws...>]

Currently, if cookies are not set, then you just append the session id to
the get string.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Maxim
> Derkachev
> Sent: Thursday, November 28, 2002 3:16 AM
> To: Rob Hutton
> Cc: php...@li...
> Subject: Re[4]: [Phplib-users] new Session4 changes
>
>
> Hello Rob,
>
> Wednesday, November 27, 2002, 8:33:50 PM, you wrote:
> RH> Use GET, just like it is done now.
>
> What do You mean?
>
> --
> Best regards,
> Maxim Derkachev mailto:max...@bo...
> IT manager,
> Symbol-Plus Publishing Ltd.
> phone: +7 (812) 324-53-53
> www.books.ru, www.symbol.ru
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

Re[4]: [Phplib-users] new Session4 changes

[Maxim D. <max...@bo...>]

Hello Rob,

Wednesday, November 27, 2002, 8:33:50 PM, you wrote:
RH> Use GET, just like it is done now.

What do You mean?

-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

[Phplib-users] reload/repost

[Rob H. <rob...@ws...>]

Guys -
  I am having some problems when playing dumb user/do anything.  If I reload
the protected page immediately after logging in, then I get a "You must
repost the data" prompt.  Is there a way around this that you have found.  I
have thought about modifying auth so that auth_showloginform() does a
header("Location: http://site/php-lib/crcloginform.html?from=thispageurl")
so that a successful login would navigate back to thispageurl.  The other
option is to use get instead of post to log in.  It does not exhibit this
behavior, but I don't really like this option...

Thoughts

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

RE: Re[2]: [Phplib-users] new Session4 changes

[Rob H. <rob...@ws...>]

Use GET, just like it is done now.

Rob Hutton
Web Safe
www.wsafe.com 

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Maxim
> Derkachev
> Sent: Wednesday, November 27, 2002 10:33 AM
> To: Rob Hutton
> Cc: php...@li...
> Subject: Re[2]: [Phplib-users] new Session4 changes
> 
> 
> Hello Rob,
> 
> Wednesday, November 27, 2002, 4:55:49 PM, you wrote:
> RH>   You cannot use the remote IP reliably to determine that the session
> RH> applies to a certain IP.
> 
> Of course we can not. But we use the remote IP only in the case when
> cookies are disabled in the browser. What else can be used as a
> marker?
> 
> 
> 
> 
> -- 
> Best regards,
> Maxim Derkachev mailto:max...@bo...
> IT manager,
> Symbol-Plus Publishing Ltd.
> phone: +7 (812) 324-53-53
> www.books.ru, www.symbol.ru 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
> 
> 

Re[2]: [Phplib-users] new Session4 changes

[Maxim D. <max...@bo...>]

Hello Rob,

Wednesday, November 27, 2002, 4:55:49 PM, you wrote:
RH>   You cannot use the remote IP reliably to determine that the session
RH> applies to a certain IP.

Of course we can not. But we use the remote IP only in the case when
cookies are disabled in the browser. What else can be used as a
marker?




-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

RE: [Phplib-users] new Session4 changes

[Rob H. <rob...@ws...>]

Guys,
  You cannot use the remote IP reliably to determine that the session
applies to a certain IP.  There are MANY ISPs that are chaching pages at
this point and there will be more as time goes on.  A person hitting a
chaching farm may come from one of several IPs.  I can't say which one for
contractual reasons, but one of the non-bankrupt remaining ISP/Long Distance
companies is about to start forcing all of there home http traffic through a
caching farm.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Giancarlo
> Sent: Tuesday, November 26, 2002 4:22 PM
> To: Maxim Derkachev
> Cc: php...@li...
> Subject: Re: [Phplib-users] new Session4 changes
>
>
>
>
> Maxim Derkachev wrote:
>
> >First, incorporated all the changes from php-lib-stable version.
> >Second, changed some strings there, performance-wise - trashed repeated
> >ini_get('register_globals') calls (moved the single one to the
> >constructor) and cleaned up some hacks with 'global' & eval
> >
> In the one just downloaded the class is missing
>
> var $register_globals
>
> And I still cannot incremet the counter. It seems as the $__session_ip
> field is not made persisntent in function register;
> I am tryng this with php 4.0.6
> in start meth, I saw that setting
> $GLOBALS[$session_ip] = remoteaddr
> does not work
> changing so does set the global though
>
> <end of method start>
>
> if($this->forgery_check_enabled && $this->session_ip) {
> // save current IP
> $$this->session_ip= $HTTP_SERVER_VARS['REMOTE_ADDR'];
> if(!$this->is_registered($this->session_ip)) {
> $this->register($this->session_ip);
> echo "THIS SESS_IP:".$$this->session_ip."<br>";
> echo "SESS_IP:".$_SESSION[$this->session_ip]."<br>";
> echo "GLOB SESS_IP:".$$this->session_ip."<br>";
>
> .....
>
> But still does not work: I see that is saving a new, different
> sess_file each reload, empty, but no cookie is left after the first
>
> Maybe my 4.06 is too old, but I am runnning apache2 as an devel
> alternative, and couldn't compile php there ;-)
>
> Gian
>
> >Third, and most significant. Added a workaround for the vulnerability,
> >addressed by Giancarlo several times. Please, look at this and test it
> >properly - with coookies and without, reg-globals on/off. It should
> >solve the session hijacking problem. See comments for details.
> >Look forward for your feedback urgently.
> >NOTE - it's in the php-lib repository, not php-lib-stable.
> >Bye for now.
> >
> >
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

Re[2]: [Phplib-users] new Session4 changes

[Maxim D. <max...@bo...>]

G> Anyway I think you should look at the session4* that are in the snapshot
G> .dev, or maybe also those in snapshot.cvs. I remember these were settled 
G> there, the session4/globals_off  fixes used to work, and the overall 
G> standard structure of include prepend/local/*4 suff, auth apart, can be 
G> considered close to final there.

I know nothing about those snapshots. I thought all the changes are in
the CVS (which shold be the only base for such snapshots).
If not, please, point where I can fetch this snapshot (which
one of them is suitable?) and commit all the changes to the devel CVS and
merge it with my changes to continue.


-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re: [Phplib-users] new Session4 changes

[Marko K. <M.K...@os...>]

> Anyway I think you should look at the session4* that are in the snapshot
> .dev, or maybe also those in snapshot.cvs. I remember these were settled
> there, the session4/globals_off  fixes used to work, and the overall
> standard structure of include prepend/local/*4 suff, auth apart, can be
> considered close to final there.
well, looks like we should finally find a quick way to incorporate the
snapshot into a new develop cvs tree, or use it as a replacement for the
current phplib tree. otherwise it will end up in complete chaos, since
there are many people working with different development sources...

marko

Re: [Phplib-users] new Session4 changes

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

 > I have no pre-4.2 setup here, so can not test this...
 >

Anyway I think you should look at the session4* that are in the snapshot
.dev, or maybe also those in snapshot.cvs. I remember these were settled 
there, the session4/globals_off  fixes used to work, and the overall 
standard structure of include prepend/local/*4 suff, auth apart, can be 
considered close to final there.

Gian

Re[2]: [Phplib-users] new Session4 changes

[Richard A. <rh...@ju...>]

At 9:42 +0100 27/11/02, Marko Kaening wrote:

>why? I thought the first version is the new superglobal?


The current version of PHPLIB still supports PHP 3, although
this support will probably be dropped for PHPLIB 8 whenever
that gets released :)

Of course the session 4 stuff escapes the implied restrictions,
however it should still support all versions of PHP 4.
The _SESSION var was introduced well into the 4 series.

 ...R.

Re[3]: [Phplib-users] new Session4 changes

[Maxim D. <max...@bo...>]

Hello, Marko,

Wednesday, November 27, 2002, 11:42:37 AM, you wrote:
>> assignment. I added it, though, and changed $_SERVER to
>> $HTTP_SERVER_VARS in the new code (missed yesterday).
MK> why? I thought the first version is the new superglobal?

We should decide then if we're going to support pre-4.1 versions.


-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re[2]: [Phplib-users] new Session4 changes

[Marko K. <M.K...@os...>]

Hi Max,

> assignment. I added it, though, and changed $_SERVER to
> $HTTP_SERVER_VARS in the new code (missed yesterday).
why? I thought the first version is the new superglobal?

Marko