Re: [PHP-DEV] Security Issues - a bit of my experience

[Sterling Hughes]

On Mon, 30 Jul 2001, Ramsi Sras wrote:

Hey, idiot.  you can just send a message to
[EMAIL PROTECTED], stop spamming my mailbox, or else
you'll be subscribed to alot more mailing lists than you ever
wanted.

-Sterling

> UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
> ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
> PLEASE!!UNSUBSCRIBE ME PLEASE!!
>
> Zeev Suraski schrieb:
>
> > At 21:34 29/07/2001, Stephen van Egmond wrote:
> > >Zeev Suraski ([EMAIL PROTECTED]) wrote:
> > > > - register_globals=on leads to insecure code, which was demonstrated time
> > > > and time again in the past.
> > > > - Once it's off, we're going to provide methods of accessing variables
> > > > which are just as easy, and quite easier in case you access them from
> > > > functions.  Having form variables register as global variables is not the
> > > > 11th commandment, and it's kind of odd to see people treat it as such.
> > >
> > >It is quite the handy feature, and it will be a bummer to see it go.
> >
> > It's not going.  It's just being turned off by default and flagged as "use
> > only if you REALLY know what you're doing" feature, and don't really care
> > about portability (the only way to write portable PHP apps is to assume
> > register_globals is off, that's been true for a while now).
> >
> > > > - E_NOTICE is a runtime issue, one which you would have to check under all
> > > > possible paths in your logic.  That's why leaving security stuff to
> > > runtime
> > > > is always never a good idea.  Setting register_globals to off gives you
> > > > development-time security.
> > >
> > >I must point out that if we're referring to existing code bases,
> > >E_NOTICE and register_globals=off require as much work: all code paths
> > >have to be exercised to catch all the old-style idioms.
> >
> > I disagree.  For E_NOTICE=off, you have to go through all of the possible
> > logical paths.  For register_globals=off, you only have to know your input
> > variables, and a search&replace would do.  It's true that in some apps,
> > where you have no idea or don't remember what the input variables are, it
> > would take some time to figure out what the input vars are, but it's still
> > much easier than going through all of the possible logical paths.
> >
> > >I was trying to step back a bit and identify some of the patterns in
> > >the attacks identified in the paper.  One extremely popular pattern was
> > >spoofing variables by overwriting them: GET variables overwriting
> > >POST, usually, and I suggested that some SAPI stunt be pulled to catch
> > >that.
> > >
> > >Although this would improve things, it bears noting that:
> > >
> > >- it deprecates a valid (on Apache) idiom which, at least, Rasmus uses
> > >- this only makes it harder to spoof variables, not impossible.
> > >   But at least that's something.
> > >
> > >Whatever. The idea hasn't caught on.  I recognize it probably wasn't
> > >worthy.
> >
> > Protecting POST vars from GET has no serious security viability, even
> > though as I said a few days ago, in practice, a hell of a lot more people
> > know how to spoof GET vars than those who know how to spoof POST or cookie
> > vars.  I believe that having $_POST, $_GET, $_COOKIE and $_FORM would give
> > you the best of all worlds, as it would really lead you to use the right
> > variable for the job.
> >
> > Zeev
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Jeffrey A . Stuart]

AMEN!  I PERSONALLY DO NOT consider it a PIA to have to access the variables
via $HTTP_POST... What I USUALLY do is something like this:

$fldform_var1 = $HTTP_POST_VARS[form_var1];
etc.

This way, I'm GUARENETEED that I got the variable FROM the location that I was
expecting.  Then, I refer throughout the rest of the script to $fldform_var1.

Ok, also, another thing.  People have been saying that "We can't turn off
regsiter_globals because it would require teaching arrays and stuff before we
should be getting to them."  Bull... ALL you have to do is say "If you wish to
access the data from the form field titled my_name, you MUST do $my_name =
$HTTP_POST_VARS[my_name]."  That's it.  The student does NOT need to know at
that time that $HTTP_POST_VARS is an array.  You can get to that later.

On Sun, 29 Jul 2001 18:25:52 -0700, [EMAIL PROTECTED] (Zeev Suraski) wrote:

>What you ignored completely are three facts:
>- register_globals=on leads to insecure code, which was demonstrated time 
>and time again in the past.
>- Once it's off, we're going to provide methods of accessing variables 
>which are just as easy, and quite easier in case you access them from 
>functions.  Having form variables register as global variables is not the 
>11th commandment, and it's kind of odd to see people treat it as such.
>- E_NOTICE is a runtime issue, one which you would have to check under all 
>possible paths in your logic.  That's why leaving security stuff to runtime 
>is always never a good idea.  Setting register_globals to off gives you 
>development-time security.
>
>Zeev
>
[...first part of original message deleted...]
>>The suggestion to turn off register_globals by default is an extremely
>>bad one. It would make using PHP nothing short of a pain in the ass,
>>break vast amounts of code, and not improve a whole lot.  I _LIKE_ that
>>I can GET or POST to a page, and the variables will still come from the
>>right place.
[...rest of message deleted...]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Stephen van Egmond]

Zeev Suraski ([EMAIL PROTECTED]) wrote:
> I don't think we can change the behavior of empty() at this stage...

isempty()?


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Zeev Suraski]

At 01:22 30/07/2001, Phil Driscoll wrote:
>I agree - to my mind empty is broken in this respect and also in the respect
>that it returns true for a string containing '0'. Consequently I (and I
>assume everyone else, unless I'm missing some occasion that this behaviour is
>useful) can never use empty in my code.
>
>Zeev was recently saying that he believed empty() was not as popular as
>isset() - and I suspect this is the reason.

My guess is that empty() came into the language at a much later stage.


>I think that empty() (for scalars) really should behave thus:
>
>function empty($var)
>{
>  return !(isset($Var) && strcmp($var,''));
>}
>
>as this is what needs to be done over and over again to validate form input.
>Maybe people really do use empty, so changing the behaviour will break loads
>of code. In which case an extra parameter $Useful, could be set to true to
>give useful behaviour :)

I don't think we can change the behavior of empty() at this stage...

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Phil Driscoll]

On Sunday 29 July 2001 19:42, Stephen van Egmond wrote:
>will produce warnings if $x is not set.  If you don't want the
>warnings, you have to replace it with:
>
>   if (isset($x) && $x) {
>   }
>
>"if it's set and it's true"...? ugh.
>
> One is then tempted to look for replacement functions in the
> library, and immediately hits upon empty.
>
>   if (!$empty)
>
> But as can be seen from the table at
> http://bang.dhs.org/~svanegmond/logictest.php , empty()
> returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
> of empty() are a good replacement for the warning-generating cast to
> boolean.

I agree - to my mind empty is broken in this respect and also in the respect 
that it returns true for a string containing '0'. Consequently I (and I 
assume everyone else, unless I'm missing some occasion that this behaviour is 
useful) can never use empty in my code.

Zeev was recently saying that he believed empty() was not as popular as 
isset() - and I suspect this is the reason.

I think that empty() (for scalars) really should behave thus:

function empty($var)
{
 return !(isset($Var) && strcmp($var,''));
}

as this is what needs to be done over and over again to validate form input.
Maybe people really do use empty, so changing the behaviour will break loads 
of code. In which case an extra parameter $Useful, could be set to true to 
give useful behaviour :)

-- 
Phil Driscoll

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Ramsi Sras]

UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
PLEASE!!UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
At 21:34 29/07/2001, Stephen van Egmond wrote:
>Zeev Suraski ([EMAIL PROTECTED]) wrote:
> > - register_globals=on leads to insecure code, which was demonstrated
time
> > and time again in the past.
> > - Once it's off, we're going to provide methods of accessing variables
> > which are just as easy, and quite easier in case you access them
from
> > functions.  Having form variables register as global variables
is not the
> > 11th commandment, and it's kind of odd to see people treat it as
such.
>
>It is quite the handy feature, and it will be a bummer to see it go.
It's not going.  It's just being turned off by default and flagged
as "use
only if you REALLY know what you're doing" feature, and don't really
care
about portability (the only way to write portable PHP apps is to assume
register_globals is off, that's been true for a while now).
> > - E_NOTICE is a runtime issue, one which you would have to check
under all
> > possible paths in your logic.  That's why leaving security
stuff to
> runtime
> > is always never a good idea.  Setting register_globals to
off gives you
> > development-time security.
>
>I must point out that if we're referring to existing code bases,
>E_NOTICE and register_globals=off require as much work: all code paths
>have to be exercised to catch all the old-style idioms.
I disagree.  For E_NOTICE=off, you have to go through all of the
possible
logical paths.  For register_globals=off, you only have to know
your input
variables, and a search&replace would do.  It's true that
in some apps,
where you have no idea or don't remember what the input variables are,
it
would take some time to figure out what the input vars are, but it's
still
much easier than going through all of the possible logical paths.
>I was trying to step back a bit and identify some of the patterns in
>the attacks identified in the paper.  One extremely popular pattern
was
>spoofing variables by overwriting them: GET variables overwriting
>POST, usually, and I suggested that some SAPI stunt be pulled to catch
>that.
>
>Although this would improve things, it bears noting that:
>
>- it deprecates a valid (on Apache) idiom which, at least, Rasmus
uses
>- this only makes it harder to spoof variables, not impossible.
>   But at least that's something.
>
>Whatever. The idea hasn't caught on.  I recognize it probably
wasn't
>worthy.
Protecting POST vars from GET has no serious security viability, even
though as I said a few days ago, in practice, a hell of a lot more
people
know how to spoof GET vars than those who know how to spoof POST or
cookie
vars.  I believe that having $_POST, $_GET, $_COOKIE and $_FORM
would give
you the best of all worlds, as it would really lead you to use the
right
variable for the job.
Zeev
--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Ramsi Sras]

UNSUBSCRIBE ME PLEASE!!
Stephen van Egmond schrieb:
Zeev Suraski ([EMAIL PROTECTED]) wrote:
> - register_globals=on leads to insecure code, which was demonstrated
time
> and time again in the past.
> - Once it's off, we're going to provide methods of accessing variables
> which are just as easy, and quite easier in case you access them
from
> functions.  Having form variables register as global variables
is not the
> 11th commandment, and it's kind of odd to see people treat it as
such.
It is quite the handy feature, and it will be a bummer to see it go.
> - E_NOTICE is a runtime issue, one which you would have to check under
all
> possible paths in your logic.  That's why leaving security stuff
to runtime
> is always never a good idea.  Setting register_globals to off
gives you
> development-time security.
I must point out that if we're referring to existing code bases,
E_NOTICE and register_globals=off require as much work: all code paths
have to be exercised to catch all the old-style idioms.
I was trying to step back a bit and identify some of the patterns in
the attacks identified in the paper.  One extremely popular pattern
was
spoofing variables by overwriting them: GET variables overwriting
POST, usually, and I suggested that some SAPI stunt be pulled to catch
that.
Although this would improve things, it bears noting that:
- it deprecates a valid (on Apache) idiom which, at least, Rasmus uses
- this only makes it harder to spoof variables, not impossible.
  But at least that's something.
Whatever. The idea hasn't caught on.  I recognize it probably wasn't
worthy.
-Steve
--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Ramsi Sras]

UNSUBSCRIBE ME PLEASE!!
Stephen van Egmond schrieb:
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> Think about whether in each of these cases it would have happened
if the
> developers of the app had developed with E_NOTICE on.  In a
high number of
> these cases it probably wouldn't.  And if this number is close
to 100%,
> then it would point to the fact that there is another less destructive
> solution here.
>
> This is why I want to go through and investigate existing PHP code
and
> have a look.
I'm a user of PHP, who would describe himself as approaching "expert"
in my knowledge.
I took a suggestion from earlier in this thread, and turned off
E_NOTICE.  An excellent idea.  I found a few holes in some
of my code,
which I was glad to repair, and grateful to the language for pointing
out to me.
The suggestion to turn off register_globals by default is an extremely
bad one. It would make using PHP nothing short of a pain in the ass,
break vast amounts of code, and not improve a whole lot.  I _LIKE_
that
I can GET or POST to a page, and the variables will still come from
the
right place.
While considering the security angle, it's important to notice that
there is a tradeoff between a secure system and a functional system,
and that for some people, security just doesn't rate: either the
function (e.g. register_globals)  is too valuable, or the downside
of a
security failure is just not all that great.  A lot of people
prefer
function over security, and would find it an unwelcome arrogance if
PHP
forced them to twiddle some settings to get it back.
Finally, a small note from my PHP programming experiences:
In order to code with E_ALL, idioms like this:
    if ($x)
   will produce warnings if $x is not set.  If you don't
want the
   warnings, you have to replace it with:
    if (isset($x) &&
$x) {
    }
   "if it's set and it's true"...? ugh.
One is then tempted to look for replacement functions in the
library, and immediately hits upon empty.
    if (!$empty)
But as can be seen from the table at
http://bang.dhs.org/~svanegmond/logictest.php
, empty()
returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
of empty() are a good replacement for the warning-generating cast to
boolean.
This tends to make E_NOTIFY more trouble than it's worth... which is
why people (including the Debian package maintainer) keep it disabled.
Thus I recommend that empty() be fixed to return false for boolean
values.  Failing that, that a non-warning-generating logical
equivalent of cast-to-boolean be provided.
--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Zeev Suraski]

At 21:34 29/07/2001, Stephen van Egmond wrote:
>Zeev Suraski ([EMAIL PROTECTED]) wrote:
> > - register_globals=on leads to insecure code, which was demonstrated time
> > and time again in the past.
> > - Once it's off, we're going to provide methods of accessing variables
> > which are just as easy, and quite easier in case you access them from
> > functions.  Having form variables register as global variables is not the
> > 11th commandment, and it's kind of odd to see people treat it as such.
>
>It is quite the handy feature, and it will be a bummer to see it go.

It's not going.  It's just being turned off by default and flagged as "use 
only if you REALLY know what you're doing" feature, and don't really care 
about portability (the only way to write portable PHP apps is to assume 
register_globals is off, that's been true for a while now).

> > - E_NOTICE is a runtime issue, one which you would have to check under all
> > possible paths in your logic.  That's why leaving security stuff to 
> runtime
> > is always never a good idea.  Setting register_globals to off gives you
> > development-time security.
>
>I must point out that if we're referring to existing code bases,
>E_NOTICE and register_globals=off require as much work: all code paths
>have to be exercised to catch all the old-style idioms.

I disagree.  For E_NOTICE=off, you have to go through all of the possible 
logical paths.  For register_globals=off, you only have to know your input 
variables, and a search&replace would do.  It's true that in some apps, 
where you have no idea or don't remember what the input variables are, it 
would take some time to figure out what the input vars are, but it's still 
much easier than going through all of the possible logical paths.

>I was trying to step back a bit and identify some of the patterns in
>the attacks identified in the paper.  One extremely popular pattern was
>spoofing variables by overwriting them: GET variables overwriting
>POST, usually, and I suggested that some SAPI stunt be pulled to catch
>that.
>
>Although this would improve things, it bears noting that:
>
>- it deprecates a valid (on Apache) idiom which, at least, Rasmus uses
>- this only makes it harder to spoof variables, not impossible.
>   But at least that's something.
>
>Whatever. The idea hasn't caught on.  I recognize it probably wasn't
>worthy.

Protecting POST vars from GET has no serious security viability, even 
though as I said a few days ago, in practice, a hell of a lot more people 
know how to spoof GET vars than those who know how to spoof POST or cookie 
vars.  I believe that having $_POST, $_GET, $_COOKIE and $_FORM would give 
you the best of all worlds, as it would really lead you to use the right 
variable for the job.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Rasmus Lerdorf]

> I was trying to step back a bit and identify some of the patterns in
> the attacks identified in the paper.  One extremely popular pattern was
> spoofing variables by overwriting them: GET variables overwriting
> POST, usually, and I suggested that some SAPI stunt be pulled to catch
> that.

That's not the case.  The default variable_order is EGPCS which means that
POST variables will always overwrite GET variables of the same name.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Stephen van Egmond]

Zeev Suraski ([EMAIL PROTECTED]) wrote:
> - register_globals=on leads to insecure code, which was demonstrated time 
> and time again in the past.
> - Once it's off, we're going to provide methods of accessing variables 
> which are just as easy, and quite easier in case you access them from 
> functions.  Having form variables register as global variables is not the 
> 11th commandment, and it's kind of odd to see people treat it as such.

It is quite the handy feature, and it will be a bummer to see it go.

> - E_NOTICE is a runtime issue, one which you would have to check under all 
> possible paths in your logic.  That's why leaving security stuff to runtime 
> is always never a good idea.  Setting register_globals to off gives you 
> development-time security.

I must point out that if we're referring to existing code bases,
E_NOTICE and register_globals=off require as much work: all code paths
have to be exercised to catch all the old-style idioms.


I was trying to step back a bit and identify some of the patterns in
the attacks identified in the paper.  One extremely popular pattern was
spoofing variables by overwriting them: GET variables overwriting
POST, usually, and I suggested that some SAPI stunt be pulled to catch
that.

Although this would improve things, it bears noting that:

- it deprecates a valid (on Apache) idiom which, at least, Rasmus uses
- this only makes it harder to spoof variables, not impossible.
  But at least that's something.

Whatever. The idea hasn't caught on.  I recognize it probably wasn't
worthy.

-Steve

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Zeev Suraski]

What you ignored completely are three facts:
- register_globals=on leads to insecure code, which was demonstrated time 
and time again in the past.
- Once it's off, we're going to provide methods of accessing variables 
which are just as easy, and quite easier in case you access them from 
functions.  Having form variables register as global variables is not the 
11th commandment, and it's kind of odd to see people treat it as such.
- E_NOTICE is a runtime issue, one which you would have to check under all 
possible paths in your logic.  That's why leaving security stuff to runtime 
is always never a good idea.  Setting register_globals to off gives you 
development-time security.

Zeev

At 11:42 29/07/2001, Stephen van Egmond wrote:
>Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> > Think about whether in each of these cases it would have happened if the
> > developers of the app had developed with E_NOTICE on.  In a high number of
> > these cases it probably wouldn't.  And if this number is close to 100%,
> > then it would point to the fact that there is another less destructive
> > solution here.
> >
> > This is why I want to go through and investigate existing PHP code and
> > have a look.
>
>I'm a user of PHP, who would describe himself as approaching "expert"
>in my knowledge.
>
>I took a suggestion from earlier in this thread, and turned off
>E_NOTICE.  An excellent idea.  I found a few holes in some of my code,
>which I was glad to repair, and grateful to the language for pointing
>out to me.
>
>The suggestion to turn off register_globals by default is an extremely
>bad one. It would make using PHP nothing short of a pain in the ass,
>break vast amounts of code, and not improve a whole lot.  I _LIKE_ that
>I can GET or POST to a page, and the variables will still come from the
>right place.
>
>While considering the security angle, it's important to notice that
>there is a tradeoff between a secure system and a functional system,
>and that for some people, security just doesn't rate: either the
>function (e.g. register_globals)  is too valuable, or the downside of a
>security failure is just not all that great.  A lot of people prefer
>function over security, and would find it an unwelcome arrogance if PHP
>forced them to twiddle some settings to get it back.
>
>Finally, a small note from my PHP programming experiences:
>
>In order to code with E_ALL, idioms like this:
> if ($x)
>
>will produce warnings if $x is not set.  If you don't want the
>warnings, you have to replace it with:
>
> if (isset($x) && $x) {
> }
>
>"if it's set and it's true"...? ugh.
>
>One is then tempted to look for replacement functions in the
>library, and immediately hits upon empty.
>
> if (!$empty)
>
>But as can be seen from the table at
>http://bang.dhs.org/~svanegmond/logictest.php , empty()
>returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
>of empty() are a good replacement for the warning-generating cast to
>boolean.
>
>This tends to make E_NOTIFY more trouble than it's worth... which is
>why people (including the Debian package maintainer) keep it disabled.
>
>
>Thus I recommend that empty() be fixed to return false for boolean
>values.  Failing that, that a non-warning-generating logical
>equivalent of cast-to-boolean be provided.
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Stephen van Egmond]

Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> Think about whether in each of these cases it would have happened if the
> developers of the app had developed with E_NOTICE on.  In a high number of
> these cases it probably wouldn't.  And if this number is close to 100%,
> then it would point to the fact that there is another less destructive
> solution here.
> 
> This is why I want to go through and investigate existing PHP code and
> have a look.

I'm a user of PHP, who would describe himself as approaching "expert"
in my knowledge.

I took a suggestion from earlier in this thread, and turned off
E_NOTICE.  An excellent idea.  I found a few holes in some of my code,
which I was glad to repair, and grateful to the language for pointing
out to me.

The suggestion to turn off register_globals by default is an extremely
bad one. It would make using PHP nothing short of a pain in the ass,
break vast amounts of code, and not improve a whole lot.  I _LIKE_ that
I can GET or POST to a page, and the variables will still come from the
right place.

While considering the security angle, it's important to notice that
there is a tradeoff between a secure system and a functional system,
and that for some people, security just doesn't rate: either the
function (e.g. register_globals)  is too valuable, or the downside of a
security failure is just not all that great.  A lot of people prefer
function over security, and would find it an unwelcome arrogance if PHP
forced them to twiddle some settings to get it back.

Finally, a small note from my PHP programming experiences:

In order to code with E_ALL, idioms like this:
if ($x) 

   will produce warnings if $x is not set.  If you don't want the
   warnings, you have to replace it with:

if (isset($x) && $x) {
}

   "if it's set and it's true"...? ugh.

One is then tempted to look for replacement functions in the
library, and immediately hits upon empty.  

if (!$empty) 

But as can be seen from the table at 
http://bang.dhs.org/~svanegmond/logictest.php , empty()
returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
of empty() are a good replacement for the warning-generating cast to
boolean.

This tends to make E_NOTIFY more trouble than it's worth... which is
why people (including the Debian package maintainer) keep it disabled.


Thus I recommend that empty() be fixed to return false for boolean
values.  Failing that, that a non-warning-generating logical
equivalent of cast-to-boolean be provided.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]