[PHP-DEV] Re: session_register warnings

[Giancarlo Pinerolo]

phplib's solution has been to re-register s globals ll the $_SESSION
vars.
The register_globals=Off has been placed, I suppose, to prevent GET/POST
(and any user_originated) var to overwrite uninitialized program
variables.
As session vars are not user_originated, and only the programmer can set
it, I'd let them global as always, or write my own globalizing function
after session start 



Sascha Schumann wrote:
> 
> With PHP 4.3, it finally becomes possible to completely
> manage session variables without any dedicated functions.
> Just set or unset variables in $_SESSION and you are done
> with it.  It could not be any easier.
> 
> The streamlining of the serialization process also has
> another advantage -- the extension will notify developers
> that their script might be indeterministic.
> 
> How? you ask.  Imagine a section of code which intents to
> change a session variable.  At the first execution, setting
> the global works.  But when the section of code is run again,
> the exact same code will silently fail.[1]
> 
> You have observed correctly that application developers have
> noticed that disabling register_globals has an effect on
> their session usage.  Those developers have appropiately
> changed their applications to read from and write to
> $_SESSION.
> 
> Now I ask you: Why should the same set of developers be
> afraid or incapable of making their scripts more reliable and
> not complete this transition?
> 
> [1] I hope everyone sees how absurd it is to suggest that
> these kind of semantics were actually intended by the
> session authors.
> 
> - Sascha

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Transparent SID support

[Giancarlo Pinerolo]

There is a flagrant bug there that allows anyone to chose a session ID
of his choice, instead of relying on the random device.

I think this breaks some POSIX-MIT-RFC somewhere and can be the cause
of easy exploits.

I would then say hat for a bugfix release it should be reasonabe to
fix it,.
I am not saying that user choice of the unpredictable session-id
couldn't be a valid method in some cases, as well as other method as
suggested, but this the programmer must decide when and where.

If you are talking about usecurity of trans_sid, then letting anyone
decide it by an url, is even worse.

Giancarlo


Zeev Suraski wrote:
> 
> - Transparent sid support is now disabled by default. (Yasuo)
> 
> I haven't followed the trans-sid discussion closely, but did we decide to
> change the behavior within a bug-fix release??
> 
> Zeev

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Giancarlo Pinerolo]

Dan Hardiker wrote:
> 
> >> Well, more worrisome would be if a bad guy tricks you into clicking on
> >> a link or simply sends you an image in an email that makes a request
> >> to my server with a valid-looking session id.  Then if you go to this
> >> site (that
> >
> > I've debunked that scenario already a few times.  The net
> > result is that this class of attacks is impossible to
> > prevent.
> >
> > The assumption in your scenario and the following is this:
> >
> > The attacker has access to a script X which calls
> > session_start().
> >
> > My scenario:
> >
> > 1.) Attacker A accesses X and stores the SID which PHP assigns to
> > him.
> >
> > 2.) A crafts a link containing SID and sends it to victim V.
> >
> > 3.) A keeps SID alive by repeatedly accessing X using SID.
> >
> > 4.) V opens link and authenticates.
> >
> > 5.) A's script notices (4).  A can overtake V's session.
> 
> Ive extended the session handling so that upon session start, it takes a
> snapshot of the browser string (and maybe a couple of other
> javascript-retrieved variables about the user's os, eg: the resolution)
> and build up as much of a picture of the client as possible.

So you should pick upt that 'initial propagation mode', so later someone
can decide to block a client shift in that while pretending to remain
the same client.

Giancarlo

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Giancarlo Pinerolo]

Rasmus Lerdorf wrote:
> 
> > On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
> >
> > > But could you at least answer the question?  What is the advantage of
> > > allowing user-supplied new session ids?  I see no reason not to add a
> > > check for this.
> >
> > For example, I have a set of C programs for IRCG load
> > testing.  It uses a simple FSM to generate HTTP requests and
> > waste incoming data (like 50K concurrent connections).  If
> > this client could not use arbitrary session ids
> > (mysid$running_number), I'd have to actually analyze HTTP
> > replies and the icky Cookie header.
> 
> Hrm..  Ok, that's what I was looking for.  A realworld reason to allow the
> client to specify the new sids.

There are a lot of cases when that can be useful, but that should be
controllable behaviour in limited places, not a general one.

Giancarlo

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Giancarlo]

Il 00:13, lunedì 19 agosto 2002, hai scritto:
> > Il 23:54, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto:
> > > Hrm..  Wait a second though, Giancarlo is saying that if the user
> > > passes in a session id himself and that session does not exist, then
> > > that will be the session id he will be given if a session is created on
> > > that request. Is that correct, Giancarlo?
> >
> > Well, yor browser has to be 'virgin' with regards to that  cookie.
> > You musn't have received one already. to be an available victim
>
> Even if you haven't received a cookie already, I don't think you can set
> the session id the way you describe. Can you get PHP to create
> /tmp/sess_123 given my example?
>

Yes, I do

[root@pong tmp]# ls -l sess*
-rw---1 nobody   4294967295   12 Aug 19 00:31 sess_123

it contains:

a|s:3:"Foo";

Giancarlo


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Giancarlo]

Il 23:54, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto:
> Hrm..  Wait a second though, Giancarlo is saying that if the user passes
> in a session id himself and that session does not exist, then that will be
> the session id he will be given if a session is created on that request.
> Is that correct, Giancarlo?
>

Well, yor browser has to be 'virgin' with regards to that  cookie.
You musn't have received one already. to be an available victim

Giancarlo



> From looking at the code and testing that assumption, it does not look
> like that is the case.  Try it yourself.  Make 2 files:
>
> file1.php:
>  session_start();
> session_register('a');
> $a = "Foo";
> ?>
> Setting $a to Foo
>
> file2.php:
>  session_start();
> echo $a;
> phpinfo();
> ?>
>
> Then (with register_globals on) load up:
>
>   file1.php?PHPSESSID=123
>
> followed by
>
>   file2.php?PHPSESSID=123
>
> You will find that the session cookie that is generated is not "123" and
> the /tmp session file is not sess_123
>
> -Rasmus
>
> On Sun, 18 Aug 2002, Dan Hardiker wrote:
> > >> But the real issue here is about session hijacking.  Yes, of course
> > >> people can send whatever session id they want to PHP.  Since the
> > >> session id comes from the user we need to accept what is sent.
> > >
> > > This is what I consider unconceivable.
> > > Why ever should  tickets issued  by the user be accepted,  to what pro?
> > > Something clashes here with that 'very umpredictable dedicated device'.
> > > I'd prefer no acceptance of user provided id, if not where expressely
> > > configured.
> >
> > There is a simple solution, make sure your the one generating the IDs,
> > and upon each "proper" session start (where no session id is passed in)
> > set a session "I started this session" variable. If a session ID has been
> > passed in, then check for that variable, if it exists - continue, if not
> > then show an error message.
> >
> > Note: you will experiance the same problem if the session times out.
> >
> >
> > --
> > Dan Hardiker [[EMAIL PROTECTED]]
> > ADAM Software & Systems Engineer
> > First Creative Ltd
> >
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] gc_maxlifetime shouldn't always be INI_ALL

[Giancarlo]

In a vhost environment, it seems tat any script can flush all existing 
sessions that use the common save_path by lowering his gc_maxlifetime and 
seting his gc_probability to 100%.

Both gc_maxlifetime and gc_probability  values are INI_ALL,  even when the 
sessio.save_path is set to everybody's cauldron, on /tmp.
This will make possible for any vhost to block other vhosts' session 
management.

Maybe it should be INI_ALL *only* when a particular save_path is specified, 
so that will influence only his sessions? 
Or does it exist some fault setting by which anyone could have the privileges 
to force gc  on some other vhosts' session by specifying *also*  the other 
vhost's save_path?

Giancarlo


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Giancarlo]

Il 02:48, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto:

> But the real issue here is about session hijacking.  Yes, of course people
> can send whatever session id they want to PHP.  Since the session id comes
> from the user we need to accept what is sent.  


This is what I consider unconceivable. 
Why ever should  tickets issued  by the user be accepted,  to what pro?
Something clashes here with that 'very umpredictable dedicated device'.
I'd prefer no acceptance of user provided id, if not where expressely 
configured.


> Perhaps a check should be
> added to make sure it looks like a proper session id before using it, but
> this can be done easily in user space and it really doesn't affect
> security in any way.  We are trying to protect the existing sessions
> sitting behind the unpredictable PHP-generated session ids.  Why would a
> normal user hack himself and choose a predictable session id?

He'd induct someone else do it, by passing it in the URL, SSL or not, which 
takes us back at the beginning of this thread. 

Gian


>
> -Rasmus
>
> On Sun, 18 Aug 2002, Giancarlo wrote:
> > Rasmus Lerdorf wrote:
> > > > Any propagation, doesn't matter.
> > > > The passed id must exist, otherwise discarded and regenerated.
> > > > I saw that php already creates the session at the start.
> > > >
> > > > The possibility to count on a stable name, because recreable anytime
> > > > and though surviving gc, is a great weaknes for that tipe of snoop.
> > > > php has to have the nicely dedicated devices to generate the id.
> > >
> > > And it does.  The session ids are not predictable, especially if you
> > > set the entropy source to something like /dev/urandom in php.ini
> > >
> > > -Rasmus
> >
> > Sorry, but I feel like speaking with HAL..
> >
> > The unpredictable choice has to be made by a dedicated device except
> > whenever any user decides to create  his favourite one?
> >
> > I mean by appending ?PHPSESSID=foo that is what happens.
> > User choice is ginven priority over that dedicated device.
> > User can force php to create and recreate anytime any known id of his
> > choice.
> >
> >
> > Gian

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Giancarlo]

Rasmus Lerdorf wrote:
> 
> > Any propagation, doesn't matter.
> > The passed id must exist, otherwise discarded and regenerated.
> > I saw that php already creates the session at the start.
> >
> > The possibility to count on a stable name, because recreable anytime
> > and though surviving gc, is a great weaknes for that tipe of snoop.
> > php has to have the nicely dedicated devices to generate the id.
> 
> And it does.  The session ids are not predictable, especially if you set
> the entropy source to something like /dev/urandom in php.ini
> 
> -Rasmus

Sorry, but I feel like speaking with HAL..

The unpredictable choice has to be made by a dedicated device except whenever 
any user decides to create  his favourite one?

I mean by appending ?PHPSESSID=foo that is what happens. 
User choice is ginven priority over that dedicated device.
User can force php to create and recreate anytime any known id of his choice.


Gian 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Giancarlo Pinerolo]

On 02:45, sabato 17 agosto 2002, Rasmus Lerdorf wrote:
> > Edin Kadribasic wrote:
> > > > I absolutely agree with Stefan here. It is *not* PHP's job to
> > >
> > > secure
> > >
> > > > a connection. SSL does this.
> > >
> > > Like that's going to stop users from pasting url with SID in it
> > > to an email, which is what this thread is about.
> > >
> > > Edin
> >
> > The issue is also that anyone can provide an URL wich can force 
> > the creation of  any user-provided ID and, at_the_same_time, force
> > the use of URL propagation instead of cookie propagation, on ANY
> > cookie-enabled client.
> >
> > It is unconceivable that any user is given trust in supplying his
> > 'unpredictable' session ID. At the moment only the (forthcoming?)
> > session.use_only_cookies php.ini directive can block that.
> >
> > I know nothing can be secure 100%, but the fact that 'a horse with
> > three legs can still walk' is no good reson not to shoot that leg
> > (hey, I love horses, but this one is an enemy one...;-)
>
> But any user can just as easily provide his own cookie with the
> session id in it.  The simple move from the URL to a Set-Cookie
> header in the request does not suddenly make it secure.
>
> -Rasmus

Any propagation, doesn't matter. 
The passed id must exist, otherwise discarded and regenerated.
I saw that php already creates the session at the start.

The possibility to count on a stable name, because recreable anytime 
and though surviving gc, is a great weaknes for that tipe of snoop. 
php has to have the nicely dedicated devices to generate the id.

Giancarlo 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Giancarlo Pinerolo]

Edin Kadribasic wrote:
> 
> > I absolutely agree with Stefan here. It is *not* PHP's job to
> secure
> > a connection. SSL does this.
> 
> Like that's going to stop users from pasting url with SID in it to
> an email, which is what this thread is about.
> 
> Edin

The issue is also that anyone can provide an URL wich can force  the
creation of  any user-provided ID and, at_the_same_time, force the use
of URL propagation instead of cookie propagation, on ANY cookie-enabled
client.

It is unconceivable that any user is given trust in supplying his
'unpredictable' session ID. At the moment only the (forthcoming?)
session.use_only_cookies php.ini directive can block that.

I know nothing can be secure 100%, but the fact that 'a horse with three
legs can still walk' is no good reson not to shoot that leg (hey, I love
horses, but this one is an enemy one...;-)

Giancarlo

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] gc impossible if session.save_path depth > 2 ?

[Giancarlo Pinerolo]

Many hosted sites would like to keep their session.save_path separate, within their 
home dir, but are somehow prevented by the fact that gc wouldn't take place if the 
path depth is > 2.

Because they obviously see a problem in implementing their own garbage collection, as 
most hosting sites  do not offer a shell nor the possibility to set up cron jobs to do 
that, most give up that, and decide to drop their session in the common cauldron.

I went through php code, and it seems that this limit is just hardcoded in there.

I mean, is there a valid technical reason for this limit to be there or...

gian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: searching across all open sessions

[Giancarlo]

Yasuo Ohgaki wrote:
> Anyway, you should use db and custom session save handler for that.
> 

Otherwise you run the risk of searching other virtualhosts' sessions
too...

Mr Pinerolo

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: register_globals vs session.force_nocookie

[Giancarlo Pinerolo]

[EMAIL PROTECTED] (Sascha Schumann) wrote:
---
>Let's analyze the meaning of session.use_cookies, shall we?
>
>http://php.net/manual/en/ref.session.php says:
>
>"session.use_cookies specifies whether the module will use
>cookies to store the session id on the client side. Defaults
>to 1 (enabled).
>
>Please note the absence of words like "only".
>
>The combination of session.use_cookies=1 and
>session.use_trans_sid=0 is working perfectly fine at the moment.
>
>This is also not about forgery.  While cookies are user data,
>the thing Mr. Pinerolo worries about is tricking a victim
>into using session ids which are known to the attacker.
>
>While it is easy for an attacker to send a URL to the victim
>containing a session id, injecting a malice cookie into the
>victim's system is a much harder job.  I would say it is
>impossible, if I would not know about user habits and the
>quality of the software coming out of Redmond.  Despite the
>availability of patches, many systems are simply not updated
>in a timely fashion.
>
>You also cannot compare this issue to register_globals,
>unless you are used to compare apples and oranges.
>
>With register_globals=on, a malice user can directly cause
>harm and severe damage to a service, if the scripts are badly
>written.  For example, an attacker could inject SQL directly
>and cause all tables to be dropped.
>
>With session.use_only_cookies=0, an attacker has a tool for
>planting social engineering attacks against unwitting users.
>It does not cause direct damage on the server side.  It is
>one way of thousands to manipulate users.  Just look at how
>many AOL accounts are "pfished" each day, because users
>ignore the warning that noone will legitimately ask them for
>their password.
>
>Mr. Pinerolo's example of online banking is immune to this
>scheme, because all bank transactions are protected by
>a one-time pad (called TANs in Germany).
>
>I would not have come up with the session.use_only_cookies
>idea, if I did not see an advantage for using it under some
>circumstances.  These circumstances are rare though and do

Frankly,  what I think of this is that it is a piece of social engineering in itself.
The new session.use_only_cookies directive, put like that, that can only be set on a 
per installation basis, will never be adopted.
This will leave all sites in the world vulnerable to damn easy snooping.
I understand there are historical reasons for trying to keep the status quo, probably 
too many applications rely on the actual weakness. I do not share that vision.

Anyway this will come back to your face one day, I have no doubts about it. This is 
not my problem, I'll be fairly offshore for the next months, so really you do what you 
want, discuss it or impose it among yourselves, I've done my duty.

Mr. Pinerolo

>not apply to all sites in general.  Badly written PHP scripts
>are more common apparently which was the deciding factor for
>disabling register_globals.  I do not foresee such a
>compatibility breaking step with regard to
>session.use_only_cookies.
>
>- Sascha
>
>

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] register_globals vs session.force_nocookie

[Giancarlo Pinerolo]

Giancarlo Pinerolo wrote:

> 
> Jani Taskinen wrote:
> >
> > I was wondering (I'm propably wrong, it's almost 6am here :)
> > that wouldn't the real fix for this without having to add
> > yet-another-ini-option have been to fix this so that
> > logic with session.use_cookies and session_use_trans_sid
> > worked like it was (?) meant to work.
> 
> I agree. That should be the same.
> But what about use_cookie=1 and use_trans_sid=1 situation?
> When should we allow to fallback from cookie to URL propagation?
> Shouldn't the GPC rule apply here too?
> 
> I know the problem with the very first hit, when we know nothing of
> cookies enabled or not..
> But the session offered in the url is checked and eventually created,
> before the firts redirect/cookie_check.
> SO at this point, before the initial redirect, we know if  this is a
> 'living' or a 'newborn' session.
> 
> I wonder if, even at the application level, it would make sense to
> trigger this with the canges in the propagation mode, and block any
> downgrade in propagation mode. But I slept only a few hours too.


I mean by writing, once we know the session has just been created, a
mode=new variable into the session... 

Then, returning from the very first redirect (mode==new): 
if a cookie is available, change mode=cookie 
if a cookie is not available, change mode='get'.

On subsequent reenters, comparing the availability of the cookie with
the mode setting, simply do not accept any change that has 'cookie' in
only one of the two.

Does it make sense as an interpretation of 'use cookies if they are
available'?

Giancarlo



> It is unusual that the same client would switch cookies on/off amid the
> way, and if this happens we are probably facing a  client qui pro quo.
> Once the client has proven to be cookie-enabled, why should we accept a
> lower level, if we don't expressly want it (use cookies if they are
> enabled).
> 
> I know counting on the possibility to force a downgrade in the
> propagation mode is a very common practice of writing code, but we
> should be able to do the same with a little bit more of control. So
> these directive should be overridable on a per script basis.
> 
> Giancarlo
> 
> >
> > ie. session.use_cookies=1 and session_use_trans_sid=0
> > would not use any other session id but the one provided
> > by the cookie? btw. Cookies can be forged too..
> >
> > --Jani
> >
> >
> 
> > On Sat, 15 Jun 2002, Giancarlo Pinerolo wrote:
> >
> > >Hi.
> > >Last here, same period, I found that nasty thing in
> > >?_PHPLIB[libdir]=http://
> > >It was the nefarious start of the register_globals=off saga.
> > >
> > >Now Sascha has agreed to add a session.use_only_cookie directive,
> > >because session.use_cookie wasn't doing it really all the times. In
> > >fact, contrary to what advertised, session.use_cookie doesn't uses
> > >cookies if a SID is found in the URL, and can so be forced to use a
> > >user_provided variable when it should not.
> > >
> > >The winning argument, for the new session.use_only_cookies, has been
> > >that, with the actual settings, there cannot exist a situation in which
> > >PHP would discard the ID in the URL, and go cookie_or_nothing, as the
> > >banks do.
> > >It is forceable. Even if the client has cookies enabled.
> > >
> > >You know, really secure sites use *only cookies* propagation, or you
> > >don't do your home banking. Because cookies are the closest thing that
> > >can assure that we are speaking to the same client, that noone can
> > >takeover a session.
> > >
> > >The basis for this behavior of session.use_cookie is that we may not
> > >know when coookies are enabled, not on the very first hit, when I
> > >suppose a redirect to self is made and the cookie is then checked for
> > >presence.
> > >
> > >The aim to use cookies, if available, is because cookie is an acronym of
> > >'not transferrable among clients that support cookies', that is it goes
> > >as close as possible to identify a single client.
> > >My interpretation of session.use_cookie is: if cookies are enabled, try
> > >to use them as a propagation because they cannot be transferred among
> > >clients
> > >(see the acronym above).
> > >If this is the aim, and on coming back from the redirect we found a
> > >cookie, still the presence of a user-provided SID in the url should make
> > >us susp

Re: [PHP-DEV] register_globals vs session.force_nocookie

[Giancarlo Pinerolo]

Jani Taskinen wrote:
> 
> I was wondering (I'm propably wrong, it's almost 6am here :)
> that wouldn't the real fix for this without having to add
> yet-another-ini-option have been to fix this so that
> logic with session.use_cookies and session_use_trans_sid
> worked like it was (?) meant to work.

I agree. That should be the same.
But what about use_cookie=1 and use_trans_sid=1 situation?
When should we allow to fallback from cookie to URL propagation? 
Shouldn't the GPC rule apply here too?

I know the problem with the very first hit, when we know nothing of
cookies enabled or not..
But the session offered in the url is checked and eventually created,
before the firts redirect/cookie_check. 
SO at this point, before the initial redirect, we know if  this is a
'living' or a 'newborn' session.

I wonder if, even at the application level, it would make sense to
trigger this with the canges in the propagation mode, and block any
downgrade in propagation mode. But I slept only a few hours too.

It is unusual that the same client would switch cookies on/off amid the
way, and if this happens we are probably facing a  client qui pro quo. 
Once the client has proven to be cookie-enabled, why should we accept a
lower level, if we don't expressly want it (use cookies if they are
enabled).

I know counting on the possibility to force a downgrade in the
propagation mode is a very common practice of writing code, but we
should be able to do the same with a little bit more of control. So
these directive should be overridable on a per script basis.
 
Giancarlo


> 
> ie. session.use_cookies=1 and session_use_trans_sid=0
> would not use any other session id but the one provided
> by the cookie? btw. Cookies can be forged too..
> 
> --Jani
> 
> 


> On Sat, 15 Jun 2002, Giancarlo Pinerolo wrote:
> 
> >Hi.
> >Last here, same period, I found that nasty thing in
> >?_PHPLIB[libdir]=http://
> >It was the nefarious start of the register_globals=off saga.
> >
> >Now Sascha has agreed to add a session.use_only_cookie directive,
> >because session.use_cookie wasn't doing it really all the times. In
> >fact, contrary to what advertised, session.use_cookie doesn't uses
> >cookies if a SID is found in the URL, and can so be forced to use a
> >user_provided variable when it should not.
> >
> >The winning argument, for the new session.use_only_cookies, has been
> >that, with the actual settings, there cannot exist a situation in which
> >PHP would discard the ID in the URL, and go cookie_or_nothing, as the
> >banks do.
> >It is forceable. Even if the client has cookies enabled.
> >
> >You know, really secure sites use *only cookies* propagation, or you
> >don't do your home banking. Because cookies are the closest thing that
> >can assure that we are speaking to the same client, that noone can
> >takeover a session.
> >
> >The basis for this behavior of session.use_cookie is that we may not
> >know when coookies are enabled, not on the very first hit, when I
> >suppose a redirect to self is made and the cookie is then checked for
> >presence.
> >
> >The aim to use cookies, if available, is because cookie is an acronym of
> >'not transferrable among clients that support cookies', that is it goes
> >as close as possible to identify a single client.
> >My interpretation of session.use_cookie is: if cookies are enabled, try
> >to use them as a propagation because they cannot be transferred among
> >clients
> >(see the acronym above).
> >If this is the aim, and on coming back from the redirect we found a
> >cookie, still the presence of a user-provided SID in the url should make
> >us suspicious.
> >If we want to prevent session takeovers, here we are in presence of a
> >transfer. We couldn't know that cookies were enabled the very first hit,
> >but now we know it, and there is a SID in the URL... someone is forcing
> >a transfer. Discard the sid and issue a new cookie.
> >
> >Once we know cookies are enabled we should stick to them, not because
> >they are a better way of storage, but because tey guarantee uniqness of
> >the client.
> >So why should we allow a transfer from outside?
> >
> >All this is apart from other concerns, as the possibility to create
> >session_id at will, with pleasing and easy-to-remember values, to be
> >offered around for those 'social engineering' attacks, with no hope for
> >the poor cookie-enabled victim to avoid it.
> >
> >Isn't his similar to the register_globals=on problem, where untrusted
> >user provided values can make their way inside the script? Isn't this
> >variable even  more important, to let it in?
> >
> >Giancarlo Pinerolo
> >
> >
> 
> --

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] register_globals vs session.force_nocookie

[Giancarlo Pinerolo]

Hi.
Last here, same period, I found that nasty thing in
?_PHPLIB[libdir]=http://
It was the nefarious start of the register_globals=off saga.

Now Sascha has agreed to add a session.use_only_cookie directive,
because session.use_cookie wasn't doing it really all the times. In
fact, contrary to what advertised, session.use_cookie doesn't uses
cookies if a SID is found in the URL, and can so be forced to use a
user_provided variable when it should not.

The winning argument, for the new session.use_only_cookies, has been
that, with the actual settings, there cannot exist a situation in which
PHP would discard the ID in the URL, and go cookie_or_nothing, as the
banks do. 
It is forceable. Even if the client has cookies enabled.

You know, really secure sites use *only cookies* propagation, or you
don't do your home banking. Because cookies are the closest thing that
can assure that we are speaking to the same client, that noone can
takeover a session.

The basis for this behavior of session.use_cookie is that we may not
know when coookies are enabled, not on the very first hit, when I
suppose a redirect to self is made and the cookie is then checked for
presence.

The aim to use cookies, if available, is because cookie is an acronym of
'not transferrable among clients that support cookies', that is it goes
as close as possible to identify a single client.
My interpretation of session.use_cookie is: if cookies are enabled, try
to use them as a propagation because they cannot be transferred among
clients
(see the acronym above).
If this is the aim, and on coming back from the redirect we found a
cookie, still the presence of a user-provided SID in the url should make
us suspicious. 
If we want to prevent session takeovers, here we are in presence of a
transfer. We couldn't know that cookies were enabled the very first hit,
but now we know it, and there is a SID in the URL... someone is forcing
a transfer. Discard the sid and issue a new cookie.

Once we know cookies are enabled we should stick to them, not because
they are a better way of storage, but because tey guarantee uniqness of
the client.
So why should we allow a transfer from outside?

All this is apart from other concerns, as the possibility to create
session_id at will, with pleasing and easy-to-remember values, to be
offered around for those 'social engineering' attacks, with no hope for
the poor cookie-enabled victim to avoid it.

Isn't his similar to the register_globals=on problem, where untrusted
user provided values can make their way inside the script? Isn't this
variable even  more important, to let it in?

Giancarlo Pinerolo

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 /ext/session php_session.h session.c

[Giancarlo Pinerolo]

Sascha Schumann wrote:
> 
> > I noticed this risk long time before and I think it's a kind of
> > security fix as Sascha's comment, isn't it?
> 
> That depends on your viewpoint.
> 
> From my perspective, this is not urgent.  It is not like an
> attacker can gain access to the server, it just makes it a
> bit harder for attackers to exploit ignorant people.  That
> group will always be vulnerable to social engineering,
> something which can only be addressed by education.
> Technology is not able to upgrade your brain, after all.
> 
> - Sascha

We must watch out for technology not to downgrade it.

Giancarlo

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Forwarding: I found a FIX for a but and don't know who to contact.

[Giancarlo Niccolai]

Forwarded message (original was to [EMAIL PROTECTED]): 
---
> Excuse me if I am writing to you, but this also concerns you:
> How may I contact PHP developers so to send them a bugfix? The php site
> doesn't say that, or I had not been able to find out.
>
> BTW, the bug is a very dangerous one: with ibase-php, all the numeric scaled
> fields (i.e. with decimals) are translated into php numbers without leading
> zeroes after the decimal dot. I.e.: PI= 3.1428... is correctly translated,
> but MY SALE = 19.09$ is translated into 19.6$  ! ARRG, this puts at
> risk all the e-commerce translations with PHP and Interbase...
>
> I posted a bugfix as bug report  14755. Please, tell me who could put this 
10
> lines bugfix in the code interbase.c code...

All you can do is to post that bugreport. This is the usual flow of a bugfix 
going
to be accepted. You may also write to [EMAIL PROTECTED] directly of you
would like to get things going faster. This is holiday time now, so please 
count
on this thing!

Goba [one [EMAIL PROTECTED]]
-
END OF FORWARDED MESSAGE

And so I did...

Thanks to everyone for your help.
Giancarlo

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14755: 105.05$ becomes 105.5$ !!! - I found the fix.

[giancarlo]

From: [EMAIL PROTECTED]
Operating system: ALL
PHP version:  4.1.1
PHP Bug Type: InterBase related
Bug description:  105.05$ becomes 105.5$ !!! - I found the fix.

Hello. I found a nasty bug in interbase extension, and I 
have the solution here. You have only to put it in the 
source code; I would but I don't know how to do this. I 
already posted the authors, but with no result.

104.05$ become 104.5$ !!!
When traslating scaled numeric fields (i.e. with 
decimals), the routine _php_ibase_var_pval is faulty;

here is the original code:

#ifdef SQL_INT64
   case SQL_INT64:
  val->type = IS_STRING;
  val->value.str.len = sprintf(string_data, "%Ld.%Ld",
  (ISC_INT64) (*((ISC_INT64 *)data) / 
  (int) pow(10.0, (double) -scale)),
  (ISC_INT64) abs((int) (*((ISC_INT64 *)data) % 
  (int) pow(10.0, (double) -scale;
  val->value.str.val = estrdup(string_data);
   break;
#endif

You can clearly see that this code is fine if the decimal 
part has no 0s before the first non 0 cipher. Here is
my correction:

#ifdef SQL_INT64
   case SQL_INT64:
  val->type = IS_STRING;
  /* Experimental section by Giancarlo Niccolai */
  if (scale) {
 int i, len;
 char dt[20];
 double number = (double) ((ISC_INT64)
(*((ISC_INT64 *)data)));
 for (i = 0; i < -scale; i++)
number /= 10;
 sprintf(dt, "%%0.%df", -scale);
 val->value.str.len = sprintf (string_data, dt , 
number);
  }
  else {
val->value.str.len = sprintf (string_data, "%Ld",
(ISC_INT64) (*((ISC_INT64 *)data)));
  }
  /* End of experimental section */
  val->value.str.val = estrdup(string_data);
   break;
#endif


Please, since Interbase is used for e-commerce, all the 
php-interbase applications can be at risk, if the site 
deals with cents...



-- 
Edit bug report at: http://bugs.php.net/?id=14755&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12819: variables and constants in classnames

[giancarlo]

From: [EMAIL PROTECTED]
Operating system: any
PHP version:  4.0.6
PHP Bug Type: Feature/Change Request
Bug description:  variables and constants in classnames

it would be nice to have the possibility to create classes with variable or
constants in 'classname' and 'extends'.

eg:
define $myauth="myAuth";
define ("_BASE_AUTH_CLASS", "Base_Auth");

class {$myauth} extends {_BASE_AUTH_CLASS}
  {...
etc

This way package delivery and integration would be a lot easier, as they
can presume the existance of already defined classes, and adopt them.


Giancarlo

-- 
Edit bug report at: http://bugs.php.net/?id=12819&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12383: $105.04 becomes $105.4!!!

[giancarlo]

From: [EMAIL PROTECTED]
Operating system: LINUX
PHP version:  4.0.6
PHP Bug Type: InterBase related
Bug description:  $105.04 becomes $105.4!!!

GGG!! Interbase module has this orrible bug. It 
transforms any BIG INTEGER (ISC_INT64) type with decimal 
points are stripped of it's zeroes between decimal point 
and the first non-zero decimal cipher

I.E. 150.0045 becomes 150.45.

This bug is very fast to find in the code, because the 
transformation from Interbase to PHP data is done with an 
instruction like

sprintf (buffer, "%f.%f", [find integer part], [find 
fractional part]); and no control over the zeroes in the 
fractional part. Even wrose, this calculus are done with 2 
heavy double "pow" calls, divisions and modules (with an 
horrible waste of time...

Now, if I had done an error like that in a programming 
execice, my teacher would have given "2" to me, (that is, 
F), even if I have studied Economics, not IT. How could 
this error have survived since now? It could cost a very 
high price for users, if you think that all the 
transactions in dollars, euros, punds and any currency 
with a fractional part IS WRONG!

Now, I have patced the source; find the static int 
_php_ibase_var_pval function in the interbase.c file, ad 
substitute what is inside the #ifdef SQL_INT64 with the 
following code:

#ifdef SQL_INT64
case SQL_INT64:
/* Experimental section by Giancarlo 
Niccolai */
if (scale) {
int i, len;
sprintf (string_data, "%Ld", 
(ISC_INT64) (*((ISC_INT64 *)data)));
len = strlen(string_data);
for (i = 0; i <= -scale; i ++) 
string_data[len-i+1] = 
string_data[len-i]; 
string_data[len-i+1] = '.';
val->value.str.len = len+1;
val->value.str.val = 
estrdup(string_data);
}
else {
val->value.str.len = sprintf 
(string_data, "%Ld", (ISC_INT64) (*((ISC_INT64 *)data)));
val->type = IS_STRING;
val->value.str.val = 
estrdup(string_data);
}
/* End of experimental section */
   val->type = IS_STRING;

/* OLD CODE */  
/*val->value.str.len =  
sprintf(string_data, "%Ld.%Ld",

 (ISC_INT64) (*((ISC_INT64 *)data) 
/ (int) pow(10.0, (double) -scale)),

 (ISC_INT64) abs((int) 
(*((ISC_INT64 *)data) % (int) pow(10.0, (double) 
-scale;
val->value.str.val = 
estrdup(string_data);*/
break;
#endif

The code is faster (you'll have in the wrost case of all 
about 18 iterations on a char array), cleaner and work 
always.

Now, I hope you'll put this code in the PHP dists as soon 
as possible, and give a STRONG evidence of this problem in 
your site, possibily warining all PHP-INTERBASE users, 
that, as I know, are a LOT.

P.S. I found the same error in the PERL DBD::Interbase 
module; I will soon track it down and send a remark to the 
perl community.

Thanks in advance, 
Giancarlo Niccolai.



-- 
Edit bug report at: http://bugs.php.net/?id=12383&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]