Re: [PHP-DEV] Security Issues (isset stuff)

2001-07-30 Thread Phil Driscoll

On Sunday 29 July 2001 19:13, [EMAIL PROTECTED] wrote:
...stuff pointing out how you'd get no warning messages when the evil guy 
sets the variables from outside.

You missed my point, which is the good guy would get the warning messages 
when he tested the code himself without sending in the 'bad' variables. 
There's no point showing the warning messages to the bad guy!

-- 
Phil Driscoll

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras


UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
- My mind is pretty firm about implementing shortcuts
for
$HTTP_*_VARS. People are going to rebel big time if we remove
their global
variables by default, and make them use these exceptionally long
alternatives instead. Most people I talked to (virtually all
of them
except for you :) agreed with that
- E_SECURITY is a good idea, but like the other ideas raised in this
discussion, it doesn't have all that much to do with the specific issue
at
hand. We have no magical way of detecting usage of variables
which is a
potential security risk, as opposed to one which is not. Unfortunately,
both are very common.
At 05:45 28/07/2001, Hartmut Holzgraefe wrote:
>Zeev Suraski wrote:
> > Anyway, to be more constructive - Andi had an idea when we were
catching a
> > cab earlier today (yesterday). His idea (which I'm just pitching,
we
> > haven't thought this through at all yet) is that instead of having
> > register_globals on, or off, we would have it as unset, by default.
When
> > unset (i.e., on new installations) - PHP will not run, but instead
display
> > information about register_globals, its security implications,
examples,
> > and a general recommendation to turn it off if at all possible.
We can
> > easily point the user to the location of the php.ini file that
he has to
> > edit in order to modify register_globals to be either on or off.
>
>i was thinking about having an additional error_level E_SECURITY besides
>E_NOTICE and having both of them activated by default in future php.ini
>distributions
>
>although i like your idea too, i'm afraid it won't reach all users
as
>often they are not the ones who do the installation but just use it
>so chances are that the system administrator responsible for installing
>php just turns register_global off again after installation while
the
>warnings produced will never reach the developers
>
>E_SECURITY, on the other hand, would have effect at runtime, not on
>installation, and the message would reach the developers (if they
>care at all, i have seen enough code having @s in all places or
>beginning with error_reporting(0) :( )
>besides that E_SECURITY could be used in other places as well ...
>
>the only drawback on my solution right now is that E_SECURITY together
>with display_errors would breack every script generating HTTP headers,
>as globals registration is done way before the script is started
>
>so i thought of an additional mechanism that would not register GPCs
>generally as globals but on demand, producing warnings whenever the
>feature is really used instead of when it is generaly turned on
>
>like ?php echo $a[hello]; ?> produces
>
> Warning: Use of undefined constant hello - assumed
'hello' ...
>
>or ?php echo $hello; ?> leads to
>
> Warning: Undefined variable: hello
>
>we could register globals on demand while issueing
>
> Warning: Undefined variable: hello - assumed $HTTP_GET_VARS['hello']
>
>ok, this might lead to a slight performance hit with register_globals
>on,
>but i wouldn't as it is identified as bad practice anyway as long
as it
>doesn't break existing code but just slows it down
>
>
>
>
> > [...] it'd encourage (force) application
> > developers to write portable applications (which is a good thing
- apps
> > based on register_globals=on are not portable, [...]
>
>hm, maybe having E_PROTABILITY as an additional error_reporting level
>would be worth a thought ... ?
>
>
>
>PS: i definetly like the idea of having track_vars generate a FORM
array
> of some sort containint both GET and POST
vars, being able to change
> from methods without having to double-check
the form processing code
> could be worth it
>
> regarding the convenience of having _GET[]
besides HTTP_GET_VARS[]
> and such i'm not sure yet (and i hope i got
it right that both
> variants will be just references to the same
array internally ?)
>
> maybe having another ini-parameter like short_track_vars
or
> convenience_track_vars? as i said, i'm not
at all sure about it yet
>...
>
>
>
>--
>Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de
+49-711-99091-77
>
>--
>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]
--
Zeev Suraski [EMAIL PROTECTED]>
CTO  co-founder, Zend Technologies Ltd. http://www.zend.com/
--
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]



Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras


UNSUBSCRIBE ME PLEASE!!
Andi Gutmans schrieb:
Hey,
I thought of an idea yesterday which could make everyone happy. In the
default php.ini we set the register_globals to a new value "unset".
If PHP
runs with this INI value it will display a page telling you that you
need
to define the register_globals option in your php.ini and explains
the
pros/cons  security concerns involved (IMO we should recommend
register_globals=off). This way we won't break existing sites which
already
have php.ini and we have an easy way to feed new users w/ the required
information.
Of course, I still think we should think of a nicer way to access form
variables such as $_FORM[] in order to make it easier for the developer.
Andi
--
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]



Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras


UNSUBSCRIBE ME PLEASE!!
Ron Chmara schrieb:
On Saturday, July 28, 2001, at 12:52 PM, Zeev
Suraski wrote:
> At 06:01 28/07/2001, Phil Driscoll wrote:
>> I and no doubt thousands of others will turn
>> register_globals on because it gives much more readable code,
>> much less
>> typing and does not IMHO add one jot to the security of my
>> applications.
> I have no doubt that thousands would turn it back on. I can't
> do anything about it, and as I said numerous times in numerous
> metaphors, I'm quite alright with that.
I have roughly 2,000 files to fix before I can use it with my
biggest client :-)
> I also can't imagine people avoiding PHP because variables
> are accessed using $_FORM['foo'], instead of $foo. People are
> not *THAT* dumb or lazy. Discussing this issue in the OSCon,
> Rasmus claimed that right now he can teach PHP to a monkey in 3
> hours, and he wouldn't want to be limited only to smart
> Gorillas in the future. I firmly believe that if a monkey can
> figure out $foo, $_FORM['foo'] is not going to be the
> showstopper.
Well, there's two *new* learning curves for the
never-programmed-before user (monkey?).
1. Understanding arrays. The newest of the newbies are still
trying to grok strings, and concepts like "get" or "post".
2. They have almost no examples, whatsoever, to use, for
learning how to work with variables in this manner.
Both of these issues, combined, increase the "monkey" factor.
Most online and printed tutorials available do not use
HTTP_*_VARS (or any future TBI vars shorthand). The example
code, all over php.net and zend.com, does not use it. Even if we
encourage them to consider it "the right thing" to do, they
don't really know how to go about doing it. I went to
google.com, and typed in "PHP tutorials",and started looking
around...
http://hotwired.lycos.com/webmonkey/99/21/index2a.html
-
Explains HTTP_POST_VARS, but doesn't use it.
http://www.devshed.com/Server_Side/PHP/
- Many tutorials,
looked at a few, none used it.
http://www.linuxguruz.org/z.php
- Many tutorials, looked at a
few, none used it.
http://www.phpdeveloper.org/
- Many tutorials, looked at a few,
none used it.
I think, perhaps, that this is one of the reasons that so much
of the PHP codebase isn't usable with register_globals = off.
The learning curve is steep, because it's basically
undocumented, in terms of tutorials, examples, downloadable
snippets/functions, etc. So we have a chicken/egg problem, where
the new monkey has to make a big jump, and use a relatively
hidden method of acccessing variables, because almost every
tutorial on PHP is "wrong". Even the smart gorillas, (the ones
writing the tutorials), aren't using it, probably because they
never learned how/why to use it.. If we can fix #2, #1 may not
require as much effort. As it currently stands, if would be akin
to releasing a version of PHP where we suddenly required them
(by default, disable if needed) to change every variable they
used from $foo to %[foo].
So, beyond my normal ramble:
If we were to do this, we might want to start by putting
examples in place, if only to show users _how_ to do it. Even if
we don't, we still need to start populating examples, if only to
show users how they _can_ work with register globals= off.
-Ronabop
--2D426F70|759328624|00101101011001100111
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those
of myself,
my employers, or any of the other little voices in my head.
--
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]



Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras


UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
At 16:28 28/07/2001, Ron Chmara wrote:
>On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote:
>>At 06:01 28/07/2001, Phil Driscoll wrote:
>>> I and no doubt thousands of others will turn
>>>register_globals on because it gives much more readable code, much
less
>>>typing and does not IMHO add one jot to the security of my applications.
>>I have no doubt that thousands would turn it back on. I can't
do
>>anything about it, and as I said numerous times in numerous metaphors,
>>I'm quite alright with that.
>
>I have roughly 2,000 files to fix before I can use it with my biggest
>client :-)
I understand that. This change, if implemented on existing code,
requires
changes to the vast majority of existing scripts. My guess is
that chances
are that at least several of these 2,000 files include issues that
will be
resolved once you move to register_globals=off compatibility.
Some of them
might be potentially exploited, even though perhaps none of them is.
>> I also can't imagine people avoiding PHP because variables
are
>> accessed using $_FORM['foo'], instead of $foo. People are
not *THAT*
>> dumb or lazy. Discussing this issue in the OSCon, Rasmus claimed
that
>> right now he can teach PHP to a monkey in 3 hours, and he wouldn't
want
>> to be limited only to smart Gorillas in the future. I firmly
believe
>> that if a monkey can figure out $foo, $_FORM['foo'] is not going
to be
>> the showstopper.
>
>Well, there's two *new* learning curves for the never-programmed-before
>user (monkey?).
>1. Understanding arrays. The newest of the newbies are still trying
to
>grok strings, and concepts like "get" or "post".
Understanding variables is not intuitive to many people either.
Telling
people "use $foo" or "use $_FORM['foo']" is equally complex in my opinion,
since you can copy it, as is, without having to actually understand
what
variables, or arrays, are.
>2. They have almost no examples, whatsoever, to use, for learning how
to
>work with variables in this manner.
This is why I said it should be gradual. Implement the new
$_GET/$_POST/$_FORM etc. in 4.0.7, and make the default change in 4.1.0,
which would come a month or two later. We can probably get the
authors of
some of the high profile PHP apps to fix them to be register_globals=off
compliant.
>Both of these issues, combined, increase the "monkey" factor. Most
online
>and printed tutorials available do not use HTTP_*_VARS (or any future
TBI
>vars shorthand). The example code, all over php.net and zend.com,
does not
>use it. Even if we encourage them to consider it "the right thing"
to do,
>they don't really know how to go about doing it. I went to google.com,
and
>typed in "PHP tutorials",and started looking around...
>http://hotwired.lycos.com/webmonkey/99/21/index2a.html
- Explains
>HTTP_POST_VARS, but doesn't use it.
>http://www.devshed.com/Server_Side/PHP/
- Many tutorials, looked at a
>few, none used it.
>http://www.linuxguruz.org/z.php
- Many tutorials, looked at a few, none
>used it.
>http://www.phpdeveloper.org/
- Many tutorials, looked at a few, none used it.
>
>I think, perhaps, that this is one of the reasons that so much of
the PHP
>codebase isn't usable with register_globals = off. The learning curve
is
>steep, because it's basically undocumented, in terms of tutorials,
>examples, downloadable snippets/functions, etc. So we have a chicken/egg
>problem, where the new monkey has to make a big jump, and use a relatively
>hidden method of acccessing variables, because almost every tutorial
on
>PHP is "wrong". Even the smart gorillas, (the ones writing the tutorials),
>aren't using it, probably because they never learned how/why to use
it..
>If we can fix #2, #1 may not require as much effort. As it currently
>stands, if would be akin to releasing a version of PHP where we suddenly
>required them (by default, disable if needed) to change every variable
>they used from $foo to %[foo].
>
>So, beyond my normal ramble:
>If we were to do this, we might want to start by putting examples
in
>place, if only to show users _how_ to do it. Even if we don't, we
still
>need to start populating examples, if only to show users
I don't disagree with you here. I think it's important we set
a goal to
get into a situation where register_globals is set to off by default.
It
doesn't have to be tomorrow - after all, we did live with it for many
years. The situation is a bit more pressing now that its exploitability
is
public knowledge, but we can still wait, and do this gradually while
trying
to educate the userbase about this issue.
Zeev
--
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]



Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras


UNSUBSCRIBE ME PLEASE!!
Phil Driscoll schrieb:
On Saturday 28 July 2001 20:52, Zeev Suraski wrote:
a rebuf to each of my arguments :)
Rather than prolong the agony, my point is that in all the cases where
a
malicious user has the chance to inject a dodgy variable, the code
must
normally have a logic path which allows the code to pass through an
undefined
usage of that variable. In testing the code with E_NOTICE on, a warning
message will be displayed. The warning message could be beefed up to
scare
the user a bit more, but for me it is this that hits the nail on the
head.
I can assure you that the monkeys will screw things up whowever you
change
the code :)
That said, It's easy to live with the proposal, especially with the
import_globals() functions.
Cheers
--
Phil Driscoll
--
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]



Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras


UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
At 01:04 29/07/2001, Phil Driscoll wrote:
>On Saturday 28 July 2001 20:52, Zeev Suraski wrote:
>
>a rebuf to each of my arguments :)
>
>Rather than prolong the agony, my point is that in all the cases where
a
>malicious user has the chance to inject a dodgy variable, the code
must
>normally have a logic path which allows the code to pass through an
undefined
>usage of that variable. In testing the code with E_NOTICE on, a warning
>message will be displayed. The warning message could be beefed up
to scare
>the user a bit more, but for me it is this that hits the nail on the
head.
*sigh* :) As I said numerous times, PHP gives you standard clean
ways to
test your variables without generating E_NOTICE's, namely, isset()
(very
popular) and empty() (less popular, but available all the same).
There's a
good, fairly darned good chance that exploitable code will generate
no
warnings whatsoever, and that code that was written with cleanliness
in
mind will actually be more difficult to debug than sucky
E_NOTICE-generating code would.
>I can assure you that the monkeys will screw things up whowever you
change
>the code :)
>
>That said, It's easy to live with the proposal, especially with the
>import_globals() functions.
I think the import_globals() is a good idea, provided we do it the right
way, and publish it for what it is. I don't think it's going
to make a
remarkable difference in neither those who would have to migrate (if
they
want to take the benefit from register_globals=off, they'd still have
to go
over all of their code) or the newbies (I still believe it's not easier
to
use $foo than it is to use $_FORM['foo'], definitely if you have to
learn
about functions (import_globals()) and the notion of the global scope,
the
'global' statement and/or $GLOBALS to properly use the $foo version
:) I
think it'd take a more educated monkey, actually ;)
Zeev
--
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]



Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras


UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
At 10:27 29/07/2001, Phil Driscoll wrote:
>On Sunday 29 July 2001 17:35, Zeev Suraski wrote:
> > *sigh* :) As I said numerous times, PHP gives you standard
clean ways to
> > test your variables without generating E_NOTICE's, namely, isset()
(very
> > popular) and empty() (less popular, but available all the same).
There's a
> > good, fairly darned good chance that exploitable code will generate
no
> > warnings whatsoever, and that code that was written with cleanliness
in
> > mind will actually be more difficult to debug than sucky
> > E_NOTICE-generating code would.
>
>We'll have to agree to differ - Over the last year I must have downloaded
>about 50 PHP scripts from the popular places with a view to using
them. ALL
>of them - yes every last one - generated warning messages under E_WARNING.
Under E_WARNING or E_NOTICE?
Make no mistake, I agree that quite a few and perhaps even probably
the
majority of the scripts are not E_NOTICE compliant. I just don't
agree
that the overlap between the group of scripts which are in fact E_NOTICE
safe and the group of scripts which are exploitable by this issue is
non
existent, or even small.
Zeev
--
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]



Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras


UNSUBSCRIBE ME PLEASE!!
Phil Driscoll schrieb:
On Sunday 29 July 2001 17:35, Zeev Suraski wrote:
> *sigh* :) As I said numerous times, PHP gives you standard
clean ways to
> test your variables without generating E_NOTICE's, namely, isset()
(very
> popular) and empty() (less popular, but available all the same).
There's a
> good, fairly darned good chance that exploitable code will generate
no
> warnings whatsoever, and that code that was written with cleanliness
in
> mind will actually be more difficult to debug than sucky
> E_NOTICE-generating code would.
We'll have to agree to differ - Over the last year I must have downloaded
about 50 PHP scripts from the popular places with a view to using them.
ALL
of them - yes every last one - generated warning messages under E_WARNING.
People who code sloppily, code sloppily, the warning messages will
get out.
Even people who code well but don't test under E_WARNING will find
that
E_WARNING is their friend. I don't think that the typical uses of isset
and
empty actually serve to hide the warning messages that would appear
in
vulnerable code.
Anyway, I'll shut up now and leave you in peace :)
--
Phil Driscoll
--
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]



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

2001-07-30 Thread 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 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]



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

2001-07-30 Thread 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 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]



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

2001-07-30 Thread 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 searchreplace 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 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]



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

2001-07-30 Thread 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 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]




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

2001-07-30 Thread 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 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]




Re: [PHP-DEV] Security Issues

2001-07-30 Thread teo

Hi Zeev!
On Sun, 29 Jul 2001, Zeev Suraski wrote:

 Generally I agree, except I don't think we should go as far as changing the 
 theme of PHP.  Putting form variables into a different space would be the 
 simplest and equally secure way to do the trick.
 
yes, but a Request class can be enriched with lots of nifty utility functions.
I'm not saying that it must be done in the language (though a Request class
would be nice :), it can be done in PHP too (which I did).

OTOH let me say I noticed two main tendencies here:
on one hand Rasmus wants the language same easy and appealing it always
been, so new users can jump in easily and have a fast start

on the other you, Kristian and others, who want the language focus more on 
supporting large applications, far more complex programs than a mysql query
displaying a table with results and such (i.e. 10 liners or such)

We have a team of VB programmers here, and I can say big projects in
Visual Basic suck raw eggs; can lead to suicidal tendencies of the programmers :) 
and that's why every time PHP start going in that direction I start looking
arround scared (maybe Python will save me? Java? neah, I'll stay a bit longer
with good ol' pal)
 

The `security issue' thread just uncovered this divergence in the view of
the language; I guess there should be a balance there, and most of the support
for large apps go in PEAR as well designed components (so far I love Stig :)

So, call me ignorant but besides the plans for the new zend2 I haven't seen
a paper to try to clearely state where is PHP going. Like Larry Wall wrote for
Perl6 (or something). Perl is already icky :) I know.
 
thanks for your time,
ciao

-- teodor

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-30 Thread Cynic

At 19:01 7/27/2001, Rasmus Lerdorf wrote the following:
-- 
 That's also not true.  Is using $foo all that better than $_GET[foo]?

For a neophyte user - most definitely.

Rasmus, I disagree. As someone who's first programming language 
was PHP, I remember the confusion when looking at code with 
variables coming from nowhere. Denoting the origin of a variable
is simply a huge plus.

 But it isn't.  It's by fixing an inherent design flaw in PHP.  The proposed
 target situation is *NOT* any more difficult to the users than the
 situation is today.

Of course it is.  $foo is conceptually simpler than $_GET[foo].  I don't
see how you can say it isn't.

$foo is conceptually a few keystrokes. That's all simplicity
I can see.




[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-30 Thread Anil Madhavapeddy

Cynic wrote:
 
 Of course it is.  $foo is conceptually simpler than $_GET[foo].
 I don't see how you can say it isn't.
 
 $foo is conceptually a few keystrokes. That's all simplicity
 I can see.
 

I think that's the whole point ...

1) $foo
2) $_GET[foo]

One looks like PHP, the other looks like Perl :-)

Anil




-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-30 Thread Cynic

At 12:06 7/30/2001, Anil Madhavapeddy wrote the following:
-- 
Cynic wrote:
 
 Of course it is.  $foo is conceptually simpler than $_GET[foo].
 I don't see how you can say it isn't.
 
 $foo is conceptually a few keystrokes. That's all simplicity
 I can see.
 

I think that's the whole point ...

1) $foo
2) $_GET[foo]

One looks like PHP, the other looks like Perl :-)

Anil
--end of quote-- 

I admit I don't know much of Perl, but my decision not to learn it 
was largely based on my perception that much things in Perl happen 
automagically (or just the language is too terse), making it hard
to understand. 

I'm probably a strange type of guy for a PHP coder, but I like 
$HTTP_*_VARS arrays, and all the servers I use have 
register_globals = off, and error_reporting = E_ALL (with these 
switched to on and E_ALL ~ E_NOTICE in Directory ... sections 
where third-party code resides... I think I have yet to come across 
a class or application that's written properly (from MPOV).



[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
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]




Re: [PHP-DEV] Security Issues (isset stuff)

2001-07-30 Thread teo

Hi Phil!
On Mon, 30 Jul 2001, Phil Driscoll wrote:

 On Sunday 29 July 2001 19:13, [EMAIL PROTECTED] wrote:
 ...stuff pointing out how you'd get no warning messages when the evil guy 
 sets the variables from outside.
 
 You missed my point, which is the good guy would get the warning messages 
 when he tested the code himself without sending in the 'bad' variables. 
 There's no point showing the warning messages to the bad guy!
 
Yes Phil, but does your codes rely on warnings messages alone?
I test every and each variable I'm about to use in the program that 
contains data from the user.
My point was that doing that way, you save isset() tests and go ahead and
test them. To be more explicit, in the case of register_globals off you won't
have to fear that if you forgot to properly initialize a variable that can be
set in request by the user. 

The only concerns are:
- if the user sends less variables than you expect
- if the content of those variable is illegal for their meaning.

In the 1st case most of the programmers (in globals on) test it with isset()  
The second one is so seldomly seen that can be said it's a legend.

In web programming there are more complicated security issues that we can
imagine, and not addressing the small ones means we're a bit ignorant on the
consequences.

For instance look for : The Dangers of Allowing Users to Post Images and
Cross-Site Request Forgeries (derived from the first) threads on Bugtraq.
It was quite an interesting security issue I've never thought of, and now
gives me hard times :)

-- teodor

-- 
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]




Re: [PHP-DEV] Security Issues (isset stuff)

2001-07-30 Thread Phil Driscoll

On Monday 30 July 2001 11:13, [EMAIL PROTECTED] wrote:
 Hi Phil!
 Yes Phil, but does your codes rely on warnings messages alone?
No - my code relies on exceedingly thorough and paranoid validation of input, 
carefully constructed program flow, painstaking testing at all stages and no 
doubt thousands of other things my brain does unconsciously due to over 20 
years of programming experience.

I cannot imagine a single error I would make which register_globals=off would 
cure, that setting error reporting to E_ALL would not highlight during 
testing.

Some people agree with me, others disgree. As long as you have conrol of your 
php.ini file, it isn't a problem :) - although it will (indeed already does!) 
tend to discourage me, and probably others, from releasing any of my code for 
public consumption.

Cheers
-- 
Phil Driscoll

-- 
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]




Re: [PHP-DEV] Security Issues (isset stuff)

2001-07-30 Thread Phil Driscoll

On Monday 30 July 2001 11:52, Phil Driscoll wrote:

 Some people agree with me, others disgree. As long as you have conrol of
 your php.ini file, it isn't a problem :) - although it will (indeed already
 does!) tend to discourage me, and probably others, from releasing any of my
 code for public consumption.

But I should have added that a good implementation of import_globals will 
remove that discouragement!

Cheers
-- 
Phil Driscoll

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-30 Thread Cynic

At 13:44 7/28/2001, Zeev Suraski wrote the following:
-- 
At 05:08 27/07/2001, [EMAIL PROTECTED] wrote:
Addressed to: Rasmus Lerdorf [EMAIL PROTECTED]
  [EMAIL PROTECTED]

 Or you can simply stop these people from using PHP which is another
 effect turning off register_globals will have.

Sorry, but that doesn't hold water.

 Java does not have this problem because Java is so complex that this
 same set of users can not program in Java. Fixing this problem by
 making PHP more complex and eliminating these problem users is a bad
 idea as far as I am concerned.


YES!!

NO!! :)  Saying people would stop using PHP (or won't get started) because of this 
change is a gross exaggeration.  IMHO, the one and only issue at hand here is 
downwards compatibility, and not usability or ease of use, not even a bit.

register_globals had no effect on my decision to learn PHP, or continue 
using it.

[...]

There are a hell of a lot more cases where using uninitialized variables is entirely 
secure, than cases where it's not.  As a 'purist' coming from C background, I'd 
always initialize variables.  PHP users would not.

I had zero C knowledge when I started learning PHP, and I always initialize 
variables in PHP.

BTW, I'm just being argumentative here.  I personally think that having E_NOTICE on 
is a very good idea, and that apps should be E_NOTICE-clean.  A great deal of PHP 
programmers will not agree with me, though, so I haven't made up my mind on whether I 
support changing this default or not.

I agree with you.



[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
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]




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

2001-07-30 Thread 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 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]




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

2001-07-30 Thread 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 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]




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

2001-07-30 Thread 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 searchreplace 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 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 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]




Re: [PHP-DEV] Security Issues

2001-07-29 Thread Zeev Suraski

At 16:28 28/07/2001, Ron Chmara wrote:
On Saturday, July 28, 2001, at 12:52  PM, Zeev Suraski wrote:
At 06:01 28/07/2001, Phil Driscoll wrote:
  I and no doubt thousands of others will turn
register_globals on because it gives much more readable code, much less
typing and does not IMHO add one jot to the security of my applications.
I have no doubt that thousands would turn it back on.  I can't do 
anything about it, and as I said numerous times in numerous metaphors, 
I'm quite alright with that.

I have roughly 2,000 files to fix before I can use it with my biggest 
client :-)

I understand that.  This change, if implemented on existing code, requires 
changes to the vast majority of existing scripts.  My guess is that chances 
are that at least several of these 2,000 files include issues that will be 
resolved once you move to register_globals=off compatibility.  Some of them 
might be potentially exploited, even though perhaps none of them is.

   I also can't imagine people avoiding PHP because variables are 
 accessed using $_FORM['foo'], instead of $foo.  People are not *THAT* 
 dumb or lazy.  Discussing this issue in the OSCon, Rasmus claimed that 
 right now he can teach PHP to a monkey in 3 hours, and he wouldn't want 
 to be limited only to smart Gorillas in the future.  I firmly believe 
 that if a monkey can figure out $foo, $_FORM['foo'] is not going to be 
 the showstopper.

Well, there's two *new* learning curves for the never-programmed-before 
user (monkey?).
1. Understanding arrays. The newest of the newbies are still trying to 
grok strings, and concepts like get or post.

Understanding variables is not intuitive to many people either.  Telling 
people use $foo or use $_FORM['foo'] is equally complex in my opinion, 
since you can copy it, as is, without having to actually understand what 
variables, or arrays, are.

2. They have almost no examples, whatsoever, to use, for learning how to 
work with variables in this manner.

This is why I said it should be gradual.  Implement the new 
$_GET/$_POST/$_FORM etc. in 4.0.7, and make the default change in 4.1.0, 
which would come a month or two later.  We can probably get the authors of 
some of the high profile PHP apps to fix them to be register_globals=off 
compliant.

Both of these issues, combined, increase the monkey factor. Most online 
and printed tutorials available do not use HTTP_*_VARS (or any future TBI 
vars shorthand). The example code, all over php.net and zend.com, does not 
use it. Even if we encourage them to consider it the right thing to do, 
they don't really know how to go about doing it. I went to google.com, and 
typed in PHP tutorials,and started looking around...
http://hotwired.lycos.com/webmonkey/99/21/index2a.html - Explains 
HTTP_POST_VARS, but doesn't use it.
http://www.devshed.com/Server_Side/PHP/ - Many tutorials, looked at a 
few, none used it.
http://www.linuxguruz.org/z.php - Many tutorials, looked at a few, none 
used it.
http://www.phpdeveloper.org/ - Many tutorials, looked at a few, none used it.

I think, perhaps, that this is one of the reasons that so much of the PHP 
codebase isn't usable with register_globals = off. The learning curve is 
steep, because it's basically undocumented, in terms of tutorials, 
examples, downloadable snippets/functions, etc. So we have a chicken/egg 
problem, where the new monkey has to make a big jump, and use a relatively 
hidden method of acccessing variables, because almost every tutorial on 
PHP is wrong. Even the smart gorillas, (the ones writing the tutorials), 
aren't using it, probably because they never learned how/why to use it.. 
If we can fix #2, #1 may not require as much effort. As it currently 
stands, if would be akin to releasing a version of PHP where we suddenly 
required them (by default, disable if needed) to change every variable 
they used from $foo to %[foo].

So, beyond my normal ramble:
If we were to do this, we might want to start by putting examples in 
place, if only to show users _how_ to do it. Even if we don't, we still 
need to start populating examples, if only to show users

I don't disagree with you here.  I think it's important we set a goal to 
get into a situation where register_globals is set to off by default.  It 
doesn't have to be tomorrow - after all, we did live with it for many 
years.  The situation is a bit more pressing now that its exploitability is 
public knowledge, but we can still wait, and do this gradually while trying 
to educate the userbase about this issue.

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-29 Thread Phil Driscoll

On Saturday 28 July 2001 20:52, Zeev Suraski wrote:

a rebuf to each of my arguments :)

Rather than prolong the agony, my point is that in all the cases where a 
malicious user has the chance to inject a dodgy variable, the code must 
normally have a logic path which allows the code to pass through an undefined 
usage of that variable. In testing the code with E_NOTICE on, a warning 
message will be displayed. The warning message could be beefed up to scare 
the user a bit more, but for me it is this that hits the nail on the head.

I can assure you that the monkeys will screw things up whowever you change 
the code :)

That said, It's easy to live with the proposal, especially with the 
import_globals() functions.

Cheers
-- 
Phil Driscoll

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-29 Thread Zeev Suraski

At 01:04 29/07/2001, Phil Driscoll wrote:
On Saturday 28 July 2001 20:52, Zeev Suraski wrote:

a rebuf to each of my arguments :)

Rather than prolong the agony, my point is that in all the cases where a
malicious user has the chance to inject a dodgy variable, the code must
normally have a logic path which allows the code to pass through an undefined
usage of that variable. In testing the code with E_NOTICE on, a warning
message will be displayed. The warning message could be beefed up to scare
the user a bit more, but for me it is this that hits the nail on the head.

*sigh* :)  As I said numerous times, PHP gives you standard clean ways to 
test your variables without generating E_NOTICE's, namely, isset() (very 
popular) and empty() (less popular, but available all the same).  There's a 
good, fairly darned good chance that exploitable code will generate no 
warnings whatsoever, and that code that was written with cleanliness in 
mind will actually be more difficult to debug than sucky 
E_NOTICE-generating code would.

I can assure you that the monkeys will screw things up whowever you change
the code :)

That said, It's easy to live with the proposal, especially with the
import_globals() functions.

I think the import_globals() is a good idea, provided we do it the right 
way, and publish it for what it is.  I don't think it's going to make a 
remarkable difference in neither those who would have to migrate (if they 
want to take the benefit from register_globals=off, they'd still have to go 
over all of their code) or the newbies (I still believe it's not easier to 
use $foo than it is to use $_FORM['foo'], definitely if you have to learn 
about functions (import_globals()) and the notion of the global scope, the 
'global' statement and/or $GLOBALS to properly use the $foo version :)  I 
think it'd take a more educated monkey, actually ;)

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-29 Thread Phil Driscoll

On Sunday 29 July 2001 17:35, Zeev Suraski wrote:
 *sigh* :)  As I said numerous times, PHP gives you standard clean ways to
 test your variables without generating E_NOTICE's, namely, isset() (very
 popular) and empty() (less popular, but available all the same).  There's a
 good, fairly darned good chance that exploitable code will generate no
 warnings whatsoever, and that code that was written with cleanliness in
 mind will actually be more difficult to debug than sucky
 E_NOTICE-generating code would.

We'll have to agree to differ - Over the last year I must have downloaded 
about 50 PHP scripts from the popular places with a view to using them. ALL 
of them - yes every last one - generated warning messages under E_WARNING. 
People who code sloppily, code sloppily, the warning messages will get out. 
Even people who code well but don't test under E_WARNING will find that 
E_WARNING is their friend. I don't think that the typical uses of isset and 
empty actually serve to hide the warning messages that would appear in 
vulnerable code.

Anyway, I'll shut up now and leave you in peace :)

-- 
Phil Driscoll

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-29 Thread Zeev Suraski

At 10:27 29/07/2001, Phil Driscoll wrote:
On Sunday 29 July 2001 17:35, Zeev Suraski wrote:
  *sigh* :)  As I said numerous times, PHP gives you standard clean ways to
  test your variables without generating E_NOTICE's, namely, isset() (very
  popular) and empty() (less popular, but available all the same).  There's a
  good, fairly darned good chance that exploitable code will generate no
  warnings whatsoever, and that code that was written with cleanliness in
  mind will actually be more difficult to debug than sucky
  E_NOTICE-generating code would.

We'll have to agree to differ - Over the last year I must have downloaded
about 50 PHP scripts from the popular places with a view to using them. ALL
of them - yes every last one - generated warning messages under E_WARNING.

Under E_WARNING or E_NOTICE?

Make no mistake, I agree that quite a few and perhaps even probably the 
majority of the scripts are not E_NOTICE compliant.  I just don't agree 
that the overlap between the group of scripts which are in fact E_NOTICE 
safe and the group of scripts which are exploitable by this issue is non 
existent, or even small.

Zeev


-- 
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]




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

2001-07-29 Thread 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 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]




Re: [PHP-DEV] Security Issues (isset stuff)

2001-07-29 Thread teo

Hi Phil!
On Sat, 28 Jul 2001, Phil Driscoll wrote:

  That's not going to find half, or a quarter, or whatever of the problems,
  since PHP has tools to cleanly handle undefined variables - namely isset()
  and empty().  They, or at least isset(), are quite popular.
 
 I always use something like:
 
 if(!isset($Thing) /*and possibly some range checking*/))
  $Thing=sensible default;
 
 In no way is
 
 if(!isset(_GET['Thing']) /*and possibly some range checking*/))
 {
  $Thing=sensible default;

well, lemme tell you my favourite:
$defRequest = array ('thing1' = '', 'thing2'='' /* ... */);
$myRequest = array_merge ($defRequest, $HTTP_GET_VARS); /* or POST*/;

This way you'll be able to simply say:
if ($myRequest[var] != default) {
// do something
}

and be sure you have something there.

 any more secure (nor would it be if I wrote sensible default back to _GET.
 
 Anyway, to check my sanity i have reread the security advisory which I first 
 read on the day it was published, and I am even more conviced now that 
 register globals=off has the tiniest of effects for gpc variables wheras 
 E_NOTICE has a massive effect.
 
 Here are the examples from the advisory:
 
 --
  ?php
   if ($pass === hello) //= corrected to ===
$auth = 1;
   ...
   if ($auth == 1)
echo some important information;
  ?
 
 replace $pass with _GET['pass']  and the code is 
 equally insecure. Turn E_NOTICE on and the novice programmer will get a 
nope,
in the first case I can say http://your.site/your_page.php?pass=whateverauth=1

 warning message for the unset $pass.
 --
  ?php
   if (!($fd = fopen($filename, r))
echo(Could not open file: $filenameBR\n);
  ?
 
 replace $filename with _GET['filename'] and this lunatic piece of code 
 remains a lunatic piece of code. If $filename is not meant to be coming from 
 the outside world then with E_NOTICE on there would be a warning message for 
 the unset filename.
The issue here was as always 'untrusted user data' used as trusted (I can say
?fielname='../../../etc/passwd' etc.)
And *maybe* seeing :
$fd = fopen ($_GET['filename'],'r');

something will click in the mind of the programmer ('geez, wait, this is
 *straight* form the request[is sais GET], what if...)

 --
  ?php
   include($libdir . /languages.php);
  ?
 Ok, with register_globals=off then $libdir could not be directly overwritten 
 from outside (unless there was some code which made that happen) however 
 E_NOTICE would generate a warning for an unset $libdir
Again, it will be set, and no notice will pop up, but it will be set by the
evil guy.

The advisory was not like one from eEye as clear and professional, but had a
very well defined point. And sadly, it was right.

-- teodor

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-29 Thread teo

Hi Zeev!
On Thu, 26 Jul 2001, Zeev Suraski wrote:

 At 02:18 26/07/2001, Ron Chmara wrote:
If most of the PHP apps out there are or were vulnerable to 
  register_globals=on attacks, we can't (shouldn't) blame the whole world, 
  but fix the language instead.
 
 I'd suggest fixing the code religion instead, but changing faiths is hard. 
 :-) If they aren't checking their vars before processing, no language 
 would fix it, would it?
 
 Most would, actually.  Pretty much any language which requires you to 
 declare variables, or, that doesn't allow external sources to declare 
 variables, does not have this problem.  PHP is quite unique in that sense, 
 which is why I agree that the language is at fault.  Of course, declaring 
 and not initializing your variable is still a programming error, but it's 
 much less severe and much less prone to exploits than this problem.
 
May I jump in? :)

As I see it, the security issue is Untrusted data coming from the user,
which collects under the request term.

What is overwritten? Server vars or user vars, and that's because there's no
hard separation between them in the register globals on case (all in the
same pot).

So why wouldn't PHP propose a Reques-Response paradigm like ASP,JSP or Zope,
before we have namespaces and such?

If I say $Request-getAttribute('geez') I am damn sure it comes from the user
and I consider the value inherently suspicious (i.e. don't just stuck it in
a mysql_query() string w/o testing.)

This can be done at PHP level or language level (where other security tests
can be addressed.)

The best teaching the pear/php devs can give to the user in the security issue
is to promote best programming practices, and IMO this is one of them;
otherwise they'll have to gulp bitter advisories about this and that popular
PHP application having an ungly bug (see phpMyAdmin, IMP, Phorum, etc.)


my 2c

-- teodor

-- 
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]




Re: [PHP-DEV] Security Issues (backward fix)

2001-07-29 Thread teo

Hi Ron!
On Sat, 28 Jul 2001, Ron Chmara wrote:

 On Saturday, July 28, 2001, at 12:52  PM, Zeev Suraski wrote:
  At 06:01 28/07/2001, Phil Driscoll wrote:
   I and no doubt thousands of others will turn
  register_globals on because it gives much more readable code, 
  much less
  typing and does not IMHO add one jot to the security of my 
  applications.
  I have no doubt that thousands would turn it back on.  I can't 
  do anything about it, and as I said numerous times in numerous 
  metaphors, I'm quite alright with that.
 
 I have roughly 2,000 files to fix before I can use it with my 
 biggest client :-)
Directory /old/apps
php_value auto_prepend_file globals_fix.php
/Directory

[globals_fix.php]

extract($HTTP_GET_VARS);
extract($HTTP_POST_VARS);
extract($HTTP_COOKIE_VARS);
etc.
now they all work with register_globals off
erm? :)

-- teodor

-- 
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]




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

2001-07-29 Thread 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 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]

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


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-29 Thread Zeev Suraski

Generally I agree, except I don't think we should go as far as changing the 
theme of PHP.  Putting form variables into a different space would be the 
simplest and equally secure way to do the trick.

At 08:32 26/07/2001, [EMAIL PROTECTED] wrote:
Hi Zeev!
On Thu, 26 Jul 2001, Zeev Suraski wrote:

  At 02:18 26/07/2001, Ron Chmara wrote:
 If most of the PHP apps out there are or were vulnerable to
   register_globals=on attacks, we can't (shouldn't) blame the whole 
 world,
   but fix the language instead.
  
  I'd suggest fixing the code religion instead, but changing faiths is 
 hard.
  :-) If they aren't checking their vars before processing, no language
  would fix it, would it?
 
  Most would, actually.  Pretty much any language which requires you to
  declare variables, or, that doesn't allow external sources to declare
  variables, does not have this problem.  PHP is quite unique in that sense,
  which is why I agree that the language is at fault.  Of course, declaring
  and not initializing your variable is still a programming error, but it's
  much less severe and much less prone to exploits than this problem.
 
May I jump in? :)

As I see it, the security issue is Untrusted data coming from the user,
which collects under the request term.

What is overwritten? Server vars or user vars, and that's because there's no
hard separation between them in the register globals on case (all in the
same pot).

So why wouldn't PHP propose a Reques-Response paradigm like ASP,JSP or Zope,
before we have namespaces and such?

If I say $Request-getAttribute('geez') I am damn sure it comes from the user
and I consider the value inherently suspicious (i.e. don't just stuck it in
a mysql_query() string w/o testing.)

This can be done at PHP level or language level (where other security tests
can be addressed.)

The best teaching the pear/php devs can give to the user in the security issue
is to promote best programming practices, and IMO this is one of them;
otherwise they'll have to gulp bitter advisories about this and that popular
PHP application having an ungly bug (see phpMyAdmin, IMP, Phorum, etc.)


my 2c

-- teodor

--
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]

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


-- 
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]




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

2001-07-29 Thread 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 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]




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

2001-07-29 Thread 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 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]




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

2001-07-29 Thread 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 searchreplace 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 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]




Re: [PHP-DEV] Security Issues

2001-07-28 Thread Zeev Suraski

I wrote a thorough response while being disconnected, but it's kind of 
pointless to send it considering the face to face discussion we had 
today.  The only thing I'd like say here is that in my opinion, the fact 
form variables are defined as globals (as opposed to being defined just as 
automatically inside $_GET/$_POST or $_FORM) is hardly what makes PHP what 
it is.  Auto form variable registration is very important and is one of the 
cornerstones of PHP, but it'd be equally good if it had a different 
syntax.  Other cornerstones that make PHP what it is are the clean and non 
obscure syntax (I bet Thies doesn't use PHP for his shell scripts because 
of auto form variable registration...), the easy to use database APIs which 
come within the binary, and the fact it contains a full set of Web tools 
built into it.  I think that portraying PHP as some weak version of Perl 
with auto global form variables is not even an understatement, but just 
plain wrong...

Anyway, to be more constructive - Andi had an idea when we were catching a 
cab earlier today (yesterday).  His idea (which I'm just pitching, we 
haven't thought this through at all yet) is that instead of having 
register_globals on, or off, we would have it as unset, by default.  When 
unset (i.e., on new installations) - PHP will not run, but instead display 
information about register_globals, its security implications, examples, 
and a general recommendation to turn it off if at all possible.  We can 
easily point the user to the location of the php.ini file that he has to 
edit in order to modify register_globals to be either on or off.

Again, I'm just pitching this idea, I'm not entirely sure if it's good or 
not.  Personally, I still lean towards having register_globals off by 
default for new installations.  This will have a very small effect on 
existing apps (for better and worse), it'd encourage (force) application 
developers to write portable applications (which is a good thing - apps 
based on register_globals=on are not portable, since many security-aware 
people turn it off), and obviously, solve the security issues we've been 
discussing.
If we release it as 4.1.0, it's going to generate enough noise to make 
people aware of this issue, which is also a good thing.

Zeev


At 10:30 27/07/2001, Rasmus Lerdorf wrote:
  This is an important step, that as I said, I wanted to make for years.  I
  just argue that as protective as you are over register_globals=on, the real
  flaw is there, and this is the place it should be fixed.  Fixing the fact
  that E_NOTICE is on may also be viable, but in practice:
  - A huge number of cases where E_NOTICE's will be generated isn't related
  to security in any way, and people will be kind of pissed by it, and
  probably turn it back off

That's an issue that can be addressed.  We perhaps need better granularity
on the E_NOTICE.

  If we distribute a php.ini-recommended, we can, and probably should enable
  E_NOTICE's by default.  It's not the solution to the problem raised in the
  advisory.

The very first and primary example in the advisory would most definitely
have been caught by an E_NOTICE, so I don't see how this doesn't address
the advisory.

For reference the first example in the advisory is:

  ?php
   if ($pass = hello)
$auth = 1;
   ...
   if ($auth == 1)
echo some important information;
  ?

First, the guy who wrote the advisory didn't check his code, because the
above could never actually be a problem since he confuses == and = and
actually always sets $auth=1, but ignoring that and fixing his code, if
you turn on E_NOTICE this script generates:

Warning: Undefined variable: pass in foo.php on line 2

Warning: Undefined variable: auth in foo.php on line 5

And the second example is:

  ?php
   if (!($fd = fopen($filename, r))
echo(Could not open file: $filenameBR\n);
  ?

Again, an obvious bracket mismatch so this example also doesn't run, but
running this with E_NOTICE gives:

Warning: Undefined variable: filename in foo.php on line 2
Warning: Undefined variable: filename in foo.php on line 3

Same goes for example 3 which is:

  ?php
   include($libdir . /languages.php);
  ?

Then he talks about the file upload issues which is a separate problem and
one we have addressed.  And then he talks about .inc files and suggests
that people who just use .php for include files are vulnerable because
their scripts could be run out of context.  This is a different issue as
well.

But that's not the point. The point is that people who don't care about
security or coding style (beginners or professionals, doesn't really
matter) are less likely to write insecure code, because there's one
mistake less that they can make. As long as they stick to the defaults,
anyway.
  
  And one language less that these people are able to use.
 
  That's an empty statement, Rasmus...  The auto-registered form variables
  are not any less usable if we change the access method to 

RE: [PHP-DEV] Security Issues

2001-07-28 Thread Zeev Suraski

At 12:36 27/07/2001, Brian Tanner wrote:
Differently - sometimes
Dangerously - Never

I think that this means that this is quite serious, and mind-bogglingly 
common security flaw.  When your app behaves differently, there's a one out 
of two, or one out of five, or one out of ten chance that this can be 
exploited for bad purposes.  Most security exploits originate in an 
application which behaves in a way that the author did not anticipate.  In 
your case, you're either lucky, talented, or both.  My view is that if your 
apps can behave differently, chances are that there's a huge number of 
other apps which can also be manipulated to behave differently, and quite a 
few of them can be manipulated into doing 'dangerous' things.

Zeev


-- 
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]




RE: [PHP-DEV] Security Issues

2001-07-28 Thread Zeev Suraski

Yes, a $_FORM variable container is also on my TODO list for the new 
track_vars implementation...

At 14:00 27/07/2001, Brian Tanner wrote:
Brian Foddy actually brings up a really important issue, which would go
along way to making (at least me) much happier with the proposed change.

*If* there will be:

$_Get[]
$_Post[]
$_Cookie[]

-- can we also have something else to the tune of:

$_External or $_User or $_Something

That gets populated based on the ordering set for GPC right now in the .ini
file?  I think it would go really far towards helping a newbie (and to
helping people fix their existing code), if there was one place that they
could look, to find the old value that they are now missing.

People can still go to _Get, _Post, and _Cookie if they require that level
of granularity, but I think most will be happy with a general container for
what Register_Globals *would* have done.

-Brian T

-Original Message-

If I can just interject once, I was a bit skeptical of this thread at
first
but I'm starting to come around to Zeev's point of view.  Security aside
(which I know it shouldn't be) I found in my own coding I always started
naming post or get variables like
$form_user_name or $post_user_name so I could easily tell just by
looking at individual sections of the code that this variable was web
input, vs my own internal variable.  But even still, it can be confusing
to newbes trying to understand just how did this variable get its
value?.
Having the $_GET[
post_user_name] is much more straight forward.

But is there a $_POST call also?  Making a important distinction between
data posted or getted input?  If so, that may be a small inconvienence.

Good debate tho, and well timed for other issues I'm dealing with.

Brian


--
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]

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


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-28 Thread Heikki Korpela

On Sat, 28 Jul 2001, Zeev Suraski wrote:

 Anyway, to be more constructive - Andi had an idea when we were catching a
 cab earlier today (yesterday).  His idea (which I'm just pitching, we
 haven't thought this through at all yet) is that instead of having
 register_globals on, or off, we would have it as unset, by default.  When
 unset (i.e., on new installations) - PHP will not run, but instead display
 information about register_globals, its security implications, examples,
 and a general recommendation to turn it off if at all possible.

I think one issue here is that people are so used to using certain
kind of language syntax that they're simply overestimating the effort
of typing $_{GET,POST}['foo'] when needed. With some time to
get used to it, I think most of the people will see why this is a good
idea. Your idea sounds like something that might help with this.

One thing that would further this cause would be to explain how to
start converting your existing codebase to be more secure in
small chunks.

I have no experience with other web servers than Apache, but with
Apache I use for my own homepages a .htaccess similar to the one
below. I have similar settings for many virtual hosts and directories
in the server configuration files.

# Security
php_flag  register_globals Off

# Error tracking / displaying / logging
php_value error_reporting 2047
php_flag  display_errors Off
php_flag  log_errors On
php_value error_log 'REPLACE_ME'
php_flag  track_errors On

 Zeev

-- 
--
  Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-28 Thread Zeev Suraski

At 05:08 27/07/2001, [EMAIL PROTECTED] wrote:
Addressed to: Rasmus Lerdorf [EMAIL PROTECTED]
   [EMAIL PROTECTED]

  Or you can simply stop these people from using PHP which is another
  effect turning off register_globals will have.
 
  Java does not have this problem because Java is so complex that this
  same set of users can not program in Java. Fixing this problem by
  making PHP more complex and eliminating these problem users is a bad
  idea as far as I am concerned.


YES!!

NO!! :)  Saying people would stop using PHP (or won't get started) because 
of this change is a gross exaggeration.  IMHO, the one and only issue at 
hand here is downwards compatibility, and not usability or ease of use, not 
even a bit.

As I see it the whole issue revolves around the fact that some people
get used to the fact that undefined variables have a value, and rely on
it.  These are the people who get hit when a hacker slips in his own
value in on such variables.  If the programmer had just initialized
the variable at the top of the program, there would not be a problem.

I think the best thing you could do about this issue is:


1.  ALWAYS report the use of an uninitialized variable, no matter what
level of error checking is in effect.  At the very least send a message
to the error_log for every undefined variable. If the error level allows
it also complain to the browser and send an email to ServerAdmin. That
won't break any existing scripts, but depending on the text of the
email, it could give system administrators incentive to correct problem
scripts. [1]  The 'send email' default should be on in the distribution.

That's not going to find half, or a quarter, or whatever of the problems, 
since PHP has tools to cleanly handle undefined variables - namely isset() 
and empty().  They, or at least isset(), are quite popular.


2.  Make it a FATAL error.  Too bad that would break so many scripts...
Maybe it could be a major effect of the E_SECURE bit.  On the other
hand, if you are serious about stamping out the uninitialized variable
problem, this will do it.

I'd argue that that's actually going to make an equally messy effect on the 
PHP developer community, with a much lower gain, and also, a considerable loss.

There's *nothing* wrong with the following code:

function foo()
{
 for ($i=0; $i10; $i++) {
 $str .= $i;
 }
 return $str;
}

It's safe, it's quick, and it uses an uninitialized variable.  There are a 
hell of a lot more cases where using uninitialized variables is entirely 
secure, than cases where it's not.  As a 'purist' coming from C background, 
I'd always initialize variables.  PHP users would not.

BTW, I'm just being argumentative here.  I personally think that having 
E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean.  A 
great deal of PHP programmers will not agree with me, though, so I haven't 
made up my mind on whether I support changing this default or not.

Another main difference between having E_NOTICE turned on and having 
register_globals=off is that with register_globals being off, your app will 
not work, fair and square, unless you modify it to read its arguments from 
the right track vars arrays.  As for just setting E_NOTICE - it won't help 
unless people actually check all the possible control paths of their 
logic.  Of course, they should do it in the testing phase.  And yes, I'm 
willing to bet that a great deal of them does not.

Register Globals is very convienent for people who write code with
PHP.  Turning it off would be a great loss.  The problem is not that
values passed to the server appear as variables, it is that some
programmers don't make sure they initialize every variable before they
use it.

There are two problems:
1.  Programmers are humans, and humans are creatures that tend to make 
mistakes, including stupid ones, and worse, repeat them over and over again
2.  PHP, with register_globals=on, mixes information coming from the user 
with information coming from code written by the developer, to a degree 
where it's impossible to differentiate between the two.  Given problem #1, 
this often leads to security problems.

In a perfect world, you'd be able to address #1 and then #2 would have been 
a non issue.  But we're walking the Earth, and not wonderland, so I think 
we should concentrate on solving #2 :)

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-28 Thread Hartmut Holzgraefe

Zeev Suraski wrote:
 Anyway, to be more constructive - Andi had an idea when we were catching a
 cab earlier today (yesterday).  His idea (which I'm just pitching, we
 haven't thought this through at all yet) is that instead of having
 register_globals on, or off, we would have it as unset, by default.  When
 unset (i.e., on new installations) - PHP will not run, but instead display
 information about register_globals, its security implications, examples,
 and a general recommendation to turn it off if at all possible.  We can
 easily point the user to the location of the php.ini file that he has to
 edit in order to modify register_globals to be either on or off.

i was thinking about having an additional error_level E_SECURITY besides
E_NOTICE and having both of them activated by default in future php.ini
distributions

although i like your idea too, i'm afraid it won't reach all users as
often they are not the ones who do the installation but just use it
so chances are that the system administrator responsible for installing
php just turns register_global off again after installation while the
warnings produced will never reach the developers

E_SECURITY, on the other hand, would have effect at runtime, not on 
installation, and the message would reach the developers (if they
care at all, i have seen enough code having @s in all places or 
beginning with error_reporting(0) :( )
besides that E_SECURITY could be used in other places as well ...

the only drawback on my solution right now is that E_SECURITY together
with display_errors would breack every script generating HTTP headers,
as globals registration is done way before the script is started

so i thought of an additional mechanism that would not register GPCs
generally as globals but on demand, producing warnings whenever the
feature is really used instead of when it is generaly turned on

like ?php echo $a[hello]; ? produces

  Warning:  Use of undefined constant hello - assumed 'hello' ...

or ?php echo $hello; ? leads to

  Warning:  Undefined variable: hello
  
we could register globals on demand while issueing

  Warning:  Undefined variable: hello - assumed $HTTP_GET_VARS['hello']

ok, this might lead to a slight performance hit with register_globals
on,
but i wouldn't as it is identified as bad practice anyway as long as it
doesn't break existing code but just slows it down



 
 [...] it'd encourage (force) application
 developers to write portable applications (which is a good thing - apps
 based on register_globals=on are not portable, [...]

hm, maybe having E_PROTABILITY as an additional error_reporting level
would be worth a thought ... ?



PS: i definetly like the idea of having track_vars generate a FORM array 
of some sort containint both GET and POST vars, being able to change
from methods without having to double-check the form processing code
could  be worth it

regarding the convenience of having _GET[] besides HTTP_GET_VARS[]
and such i'm not sure yet (and i hope i got it right that both 
variants will be just references to the same array internally ?)

maybe having another ini-parameter like short_track_vars or
convenience_track_vars? as i said, i'm not at all sure about it yet
...
 


-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-28 Thread Phil Driscoll

Apologies in advance to Zeev for arguing on this one, but be assured I firmly 
believe that your solution would be to the detriment of PHP and a better 
solution is possible :)

On Saturday 28 July 2001 12:44, Zeev Suraski wrote:

 NO!! :)  Saying people would stop using PHP (or won't get started) because
 of this change is a gross exaggeration.  IMHO, the one and only issue at
 hand here is downwards compatibility, and not usability or ease of use, not
 even a bit.

Sorry Zeev - the answer is YES. I and no doubt thousands of others will turn 
register_globals on because it gives much more readable code, much less 
typing and does not IMHO add one jot to the security of my applications.

 That's not going to find half, or a quarter, or whatever of the problems,
 since PHP has tools to cleanly handle undefined variables - namely isset()
 and empty().  They, or at least isset(), are quite popular.

I always use something like:

if(!isset($Thing) /*and possibly some range checking*/))
 $Thing=sensible default;

In no way is

if(!isset(_GET['Thing']) /*and possibly some range checking*/))
{
 $Thing=sensible default;
}
else
{
 $Thing=(_GET['Thing']);
}

any more secure (nor would it be if I wrote sensible default back to _GET.

Anyway, to check my sanity i have reread the security advisory which I first 
read on the day it was published, and I am even more conviced now that 
register globals=off has the tiniest of effects for gpc variables wheras 
E_NOTICE has a massive effect.

Here are the examples from the advisory:

--
 ?php
  if ($pass === hello) //= corrected to ===
   $auth = 1;
  ...
  if ($auth == 1)
   echo some important information;
 ?

replace $pass with _GET['pass']  and the code is 
equally insecure. Turn E_NOTICE on and the novice programmer will get a 
warning message for the unset $pass.
--
 ?php
  if (!($fd = fopen($filename, r))
   echo(Could not open file: $filenameBR\n);
 ?

replace $filename with _GET['filename'] and this lunatic piece of code 
remains a lunatic piece of code. If $filename is not meant to be coming from 
the outside world then with E_NOTICE on there would be a warning message for 
the unset filename.
--
 ?php
  include($libdir . /languages.php);
 ?
Ok, with register_globals=off then $libdir could not be directly overwritten 
from outside (unless there was some code which made that happen) however 
E_NOTICE would generate a warning for an unset $libdir
--
File upload.
If you don't use the new functions you are potentially stuffed with register 
globals on or off.
As an aside - we could have a php.ini directive which could 'break' code 
which did not use the new functions - if we save an uploaded file with one 
name, but set the $userfile_name to something else, and only rename the 
original to $userfile_name after a call to is_uploaded_file or 
move_uploaded_file.
--
 ?php
  if (file_exists($theme)) // Checks the file exists on the local system (no
remote files)
   include($theme);
 ?

This seems to be the same as the fopen($filename... example above.
--
In libdir/loadlanguage.php:
 ?php
  ...

  include($langDir/$userLang);
 ?

include files called out of context. The solution is to configure your web 
server, or put the include files outside the webroot so that they cannot be 
run out of context.

In this example, typically $langdir should have been set inside the 
application or a configuration file, but $userLang will typically have come 
from the user either with this request, or previously and stored in a 
database in the users profile.

So under the register_globals = off scheme, we would often end up with 
something along the lines of:

?php
  ...

  include($langDir/_GET['userLang']);
 ?

where $langDir is unset. We can all see how secure that is :)
--
Session files.

I am happy to concede that there should be a php.imi directive which stops 
variables which can more or less be trusted, such as env and session from 
entering the global namespace, so that if you want to read them you have to 
look in the correct place.
--

In conclusion I would urge those who want to set register_globals=off to 
reconsider. A better solution is required. The better solution involves some, 
all, or more of:
E_WARNING
more granularity to the register_globals directive
the file upload changes I mentioned as an aside


Cheers 
-- 
Phil Driscoll

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-28 Thread Heikki Korpela

On Sat, 28 Jul 2001, Zeev Suraski wrote:

 BTW, I'm just being argumentative here.  I personally think that having
 E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean.  A
 great deal of PHP programmers will not agree with me, though, so I haven't
 made up my mind on whether I support changing this default or not.

Consider it this way:

If an user decides to use my library that is E_NOTICE clean and
doesn't have E_NOTICE, what happens?

If I decide to use a library that isn't E_NOTICE clean and I have
E_NOTICE, what happens?

The main issue here from my point of view is interoperation and
distribution of software.

 2.  PHP, with register_globals=on, mixes information coming from the user
 with information coming from code written by the developer, to a degree
 where it's impossible to differentiate between the two.  Given problem #1,
 this often leads to security problems.

As long as we have a small quantity of small programs and libraries
with minor distribution, the maintainance effort of obfuscated code
is not vast, and thus flexibility may be default, and perhaps the
primary aim.

As software written in PHP grows in popularity and the codebase itself
grows in size, maintainance becomes harder. Thus I think that a clear
message from the developers - whether it's E_NOTICE or register_globals
or an open letter called Code Together - that states we are
concerned that it's becoming increasingly hard to incorporate large
codebases together without compromising stability and security is
in my opinion in place.

But that's of course only me.

 Zeev

-- 
--
  Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-28 Thread Zeev Suraski

- My mind is pretty firm about implementing shortcuts for 
$HTTP_*_VARS.  People are going to rebel big time if we remove their global 
variables by default, and make them use these exceptionally long 
alternatives instead.  Most people I talked to (virtually all of them 
except for you :) agreed with that
- E_SECURITY is a good idea, but like the other ideas raised in this 
discussion, it doesn't have all that much to do with the specific issue at 
hand.  We have no magical way of detecting usage of variables which is a 
potential security risk, as opposed to one which is not.  Unfortunately, 
both are very common.

At 05:45 28/07/2001, Hartmut Holzgraefe wrote:
Zeev Suraski wrote:
  Anyway, to be more constructive - Andi had an idea when we were catching a
  cab earlier today (yesterday).  His idea (which I'm just pitching, we
  haven't thought this through at all yet) is that instead of having
  register_globals on, or off, we would have it as unset, by default.  When
  unset (i.e., on new installations) - PHP will not run, but instead display
  information about register_globals, its security implications, examples,
  and a general recommendation to turn it off if at all possible.  We can
  easily point the user to the location of the php.ini file that he has to
  edit in order to modify register_globals to be either on or off.

i was thinking about having an additional error_level E_SECURITY besides
E_NOTICE and having both of them activated by default in future php.ini
distributions

although i like your idea too, i'm afraid it won't reach all users as
often they are not the ones who do the installation but just use it
so chances are that the system administrator responsible for installing
php just turns register_global off again after installation while the
warnings produced will never reach the developers

E_SECURITY, on the other hand, would have effect at runtime, not on
installation, and the message would reach the developers (if they
care at all, i have seen enough code having @s in all places or
beginning with error_reporting(0) :( )
besides that E_SECURITY could be used in other places as well ...

the only drawback on my solution right now is that E_SECURITY together
with display_errors would breack every script generating HTTP headers,
as globals registration is done way before the script is started

so i thought of an additional mechanism that would not register GPCs
generally as globals but on demand, producing warnings whenever the
feature is really used instead of when it is generaly turned on

like ?php echo $a[hello]; ? produces

   Warning:  Use of undefined constant hello - assumed 'hello' ...

or ?php echo $hello; ? leads to

   Warning:  Undefined variable: hello

we could register globals on demand while issueing

   Warning:  Undefined variable: hello - assumed $HTTP_GET_VARS['hello']

ok, this might lead to a slight performance hit with register_globals
on,
but i wouldn't as it is identified as bad practice anyway as long as it
doesn't break existing code but just slows it down




  [...] it'd encourage (force) application
  developers to write portable applications (which is a good thing - apps
  based on register_globals=on are not portable, [...]

hm, maybe having E_PROTABILITY as an additional error_reporting level
would be worth a thought ... ?



PS: i definetly like the idea of having track_vars generate a FORM array
 of some sort containint both GET and POST vars, being able to change
 from methods without having to double-check the form processing code
 could  be worth it

 regarding the convenience of having _GET[] besides HTTP_GET_VARS[]
 and such i'm not sure yet (and i hope i got it right that both
 variants will be just references to the same array internally ?)

 maybe having another ini-parameter like short_track_vars or
 convenience_track_vars? as i said, i'm not at all sure about it yet
...



--
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

--
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]

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


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-28 Thread Andi Gutmans

Hey,

I thought of an idea yesterday which could make everyone happy. In the 
default php.ini we set the register_globals to a new value unset. If PHP 
runs with this INI value it will display a page telling you that you need 
to define the register_globals option in your php.ini and explains the 
pros/cons  security concerns involved (IMO we should recommend 
register_globals=off). This way we won't break existing sites which already 
have php.ini and we have an easy way to feed new users w/ the required 
information.
Of course, I still think we should think of a nicer way to access form 
variables such as $_FORM[] in order to make it easier for the developer.

Andi


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-28 Thread Stig S. Bakken

Björn Schotte wrote:
 
 * Rasmus Lerdorf wrote:
  significantly more secure PHP scripts out there.  It will simply cause
  scripts to break in non-obvious ways and the knee-jerk fix will be to
  swear at those annoying PHP folks and then turn register_globals on, or
  they will do something like:
 
foreach($HTTP_POST_VARS as $key=$val) $$key = $val;
foreach($HTTP_GET_VARS as $key=$val) $$key = $val;
foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val;
 
 I fully agree here with Rasmus and I also think this will
 be the workaround for most people -- if one _does_ care
 about security, he even knows what and how to do nowadays.
 I don't think turning register_globals to off will evangelize
 people to develop more secure scripts/applications.

We could at least educate people about extract(). :-P

 - Stig

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-28 Thread Ron Chmara

On Saturday, July 28, 2001, at 12:52  PM, Zeev Suraski wrote:
 At 06:01 28/07/2001, Phil Driscoll wrote:
  I and no doubt thousands of others will turn
 register_globals on because it gives much more readable code, 
 much less
 typing and does not IMHO add one jot to the security of my 
 applications.
 I have no doubt that thousands would turn it back on.  I can't 
 do anything about it, and as I said numerous times in numerous 
 metaphors, I'm quite alright with that.

I have roughly 2,000 files to fix before I can use it with my 
biggest client :-)

   I also can't imagine people avoiding PHP because variables 
 are accessed using $_FORM['foo'], instead of $foo.  People are 
 not *THAT* dumb or lazy.  Discussing this issue in the OSCon, 
 Rasmus claimed that right now he can teach PHP to a monkey in 3 
 hours, and he wouldn't want to be limited only to smart 
 Gorillas in the future.  I firmly believe that if a monkey can 
 figure out $foo, $_FORM['foo'] is not going to be the 
 showstopper.

Well, there's two *new* learning curves for the 
never-programmed-before user (monkey?).
1. Understanding arrays. The newest of the newbies are still 
trying to grok strings, and concepts like get or post.
2. They have almost no examples, whatsoever, to use, for 
learning how to work with variables in this manner.

Both of these issues, combined, increase the monkey factor. 
Most online and printed tutorials available do not use 
HTTP_*_VARS (or any future TBI vars shorthand). The example 
code, all over php.net and zend.com, does not use it. Even if we 
encourage them to consider it the right thing to do, they 
don't really know how to go about doing it. I went to 
google.com, and typed in PHP tutorials,and started looking 
around...
http://hotwired.lycos.com/webmonkey/99/21/index2a.html - 
Explains HTTP_POST_VARS, but doesn't use it.
http://www.devshed.com/Server_Side/PHP/ - Many tutorials, 
looked at a few, none used it.
http://www.linuxguruz.org/z.php - Many tutorials, looked at a 
few, none used it.
http://www.phpdeveloper.org/ - Many tutorials, looked at a few, 
none used it.

I think, perhaps, that this is one of the reasons that so much 
of the PHP codebase isn't usable with register_globals = off. 
The learning curve is steep, because it's basically 
undocumented, in terms of tutorials, examples, downloadable 
snippets/functions, etc. So we have a chicken/egg problem, where 
the new monkey has to make a big jump, and use a relatively 
hidden method of acccessing variables, because almost every 
tutorial on PHP is wrong. Even the smart gorillas, (the ones 
writing the tutorials), aren't using it, probably because they 
never learned how/why to use it.. If we can fix #2, #1 may not 
require as much effort. As it currently stands, if would be akin 
to releasing a version of PHP where we suddenly required them 
(by default, disable if needed) to change every variable they 
used from $foo to %[foo].

So, beyond my normal ramble:
If we were to do this, we might want to start by putting 
examples in place, if only to show users _how_ to do it. Even if 
we don't, we still need to start populating examples, if only to 
show users how they _can_ work with register globals= off.

-Ronabop

--2D426F70|759328624|00101101011001100111
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those 
of myself,
my employers, or any of the other little voices in my head.

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 08:48 26/07/2001, Rasmus Lerdorf wrote:
  Just replace your if ($ok) with if (!empty($ok)), and you have a perfect
  exploitable code that produces no warnings.

But in this case someone has gone to the trouble to figure out what
empty() does.  And generally they use empty() on things that come from the
user anyway.  I don't think I have ever seen people use empty() to check
to see if they themselves have set an internal variable to something.

I have...  And quite a lot use isset(), which is much more common and 
popular than empty().  My guess is that we're dealing with a fairly big 
number of users/scripts here, which are exploitable even though they're 
'clean' scripts with no warnings.  I'm all in favour of turning E_NOTICE's 
on (I was since day one and so was Andi, but  back then, most people 
supported the 'loose' behavior of PHP/FI 2 as a default, and leave 
E_NOTICEs as an option you have to explicitly turn on).

  Right, but I gave a more specific example - HTTPS, which doesn't always
  exist, and its very existence implies something.  Not all variables are
  exploitable, perhaps even most aren't, but many are.

Don't people use $SERVER_PORT for this?  Would seem to make more sense.
But sure, there may be a few variables like this.

Yes, it was just an example.  I know at least one script in zend.com which 
uses HTTPS that I came across a while ago, so such cases definitely exist.

  They're trivial to come up with;  Pretty much any good code (E_NOTICE free)
  that doesn't take into account the fact that variables can pop out of
  nowhere into your global namespace is exploitable.

I still think that turning on E_NOTICE by default is a good first step
that we can take right away without waiting for a 4.1 and adding more
emphasis to the documentation about these issues.  With the E_NOTICE
people at least get a warning and a line number and most apps will still
work, they will just look very ugly forcing people to go and address the
warnings.  Turning off register_globals will simply break the applications
with absolutely no hint as to why the application was broken and the end
result will be that people simply turn register_globals back on to get
things to work.

I actually think that turning E_NOTICE on is going to have a huge effect on 
a mind boggling number of scripts, probably on the same order of magnitude 
as setting register_globals to off (probably less, but not that much 
less).  I think that unless we explain explicitly and vocally why we're 
making these changes  (register_globals and/or error level), people will 
just reconfigure php.ini to the old settings - I don't think they'll start 
running after new E_NOTICE's they suddenly get after upgrading, unless 
they'd know they have a good reason to.

I think that new PHP installations should come with register_globals set to 
off.  Instead of php.ini-dist and php.ini-optimized, we should probably 
have php.ini-recommended, which would be the default installed file 
(assuming there's no php.ini to begin with), and php.ini-compat, which 
would be what php.ini-dist is today.  No doubt, this would cause many 
(perhaps even most) PHP applications out there not to install out of the 
box, but I think that setting register_globals off is a pretty pressing 
matter, and without some pain (i.e., forcing app authors to update their 
apps to work with the track_vars arrays) we won't get anywhere.

The way I think we should go about this is:

(a) Improve the accessibility of the track vars array by shortening their 
names to $_GET[], $_POST[], etc.  and possibly making them implicitly 
available inside functions.  This can be done relatively quickly.
(b) Get the word out that as of PHP 4.0.8, register_globals will be off, so 
that app authors will have a chance to fix their apps.
(c) Release 4.0.7 with the new improved track vars, but with 
register_globals still set to on
(d) Release 4.0.8 with register_globals set to off

We can (and probably should) make the E_NOTICE change at the same time.

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Cynic

At 08:32 7/27/2001, Zeev Suraski wrote the following:
-- 

Zeev,

while I'll applaud to the changes you propose, I suggest this
happens in 4.1. I know, this is really a cosmetic change only,
and doesn't justify the bump from the perspective of the PHP
developers, but is a major one from the perspective of a PHP
user.

Defaulting error_reporting to E_ALL, and turning register_globals
off means 99% percent of current applications won't work, and
given the current behavior of zend_error(), where PHP basically 
reports bogus line numbers (http://www.php.net/bugs.php?id=1225)
this is really hard to get around. With 4.1, it'll be clear that
a massive change is coming. I'd vote for 4.7 (current state of 
things) - 4.1 (register_globals off, error_reporting E_ALL).

Other than that, hip hip hurray!!!

The way I think we should go about this is:

(a) Improve the accessibility of the track vars array by shortening their names to 
$_GET[], $_POST[], etc.  and possibly making them implicitly available inside 
functions.  This can be done relatively quickly.
(b) Get the word out that as of PHP 4.0.8, register_globals will be off, so that app 
authors will have a chance to fix their apps.
(c) Release 4.0.7 with the new improved track vars, but with register_globals still 
set to on
(d) Release 4.0.8 with register_globals set to off

We can (and probably should) make the E_NOTICE change at the same time.

Zeev


-- 
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]
--end of quote-- 


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

Well, we actually could just bump the version number to 4.1.0 for these 
changes alone.  I don't think we should wait for *any* of the other changes 
that people had in mind for a major or semi major version, but bumping the 
number to 4.1.0 instead of staying at 4.0.8 is probably a good idea.

Zeev

At 23:56 26/07/2001, Cynic wrote:
At 08:32 7/27/2001, Zeev Suraski wrote the following:
--

Zeev,

while I'll applaud to the changes you propose, I suggest this
happens in 4.1. I know, this is really a cosmetic change only,
and doesn't justify the bump from the perspective of the PHP
developers, but is a major one from the perspective of a PHP
user.

Defaulting error_reporting to E_ALL, and turning register_globals
off means 99% percent of current applications won't work, and
given the current behavior of zend_error(), where PHP basically
reports bogus line numbers (http://www.php.net/bugs.php?id=1225)
this is really hard to get around. With 4.1, it'll be clear that
a massive change is coming. I'd vote for 4.7 (current state of
things) - 4.1 (register_globals off, error_reporting E_ALL).

Other than that, hip hip hurray!!!

 The way I think we should go about this is:
 
 (a) Improve the accessibility of the track vars array by shortening 
 their names to $_GET[], $_POST[], etc.  and possibly making them 
 implicitly available inside functions.  This can be done relatively quickly.
 (b) Get the word out that as of PHP 4.0.8, register_globals will be off, 
 so that app authors will have a chance to fix their apps.
 (c) Release 4.0.7 with the new improved track vars, but with 
 register_globals still set to on
 (d) Release 4.0.8 with register_globals set to off
 
 We can (and probably should) make the E_NOTICE change at the same time.
 
 Zeev
 
 
 --
 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]
--end of quote--


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
 - Book of Installation chapt 3 sec 7

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


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Heikki Korpela

On Thu, 26 Jul 2001, Zeev Suraski wrote:

 But in this case someone has gone to the trouble to figure out what
 empty() does.  And generally they use empty() on things that come from the
 user anyway.  I don't think I have ever seen people use empty() to check
 to see if they themselves have set an internal variable to something.
 I have...  And quite a lot use isset(), which is much more common and
 popular than empty().

I use both isset() and empty() in hundreds of lines of code that check
my own internally defined structures, such as predefined arrays that define
behaviour of the code.

 I actually think that turning E_NOTICE on is going to have a huge effect on
 a mind boggling number of scripts, probably on the same order of magnitude
 as setting register_globals to off (probably less, but not that much
 less).

One major problem I'm currently having is that I like to reuse
other people's PHP code if any is available, and I have to hack up
a horrible number of directory- and virtual host-specific error_reporting
values because the code otherwise generates megabytes of log over a very
short while.

This makes it extremely hard to maintain a codebase that uses both
our own and others' code where our code is strictly developed against
E_NOTICE and others' will have to either be reviewed thoroughly or
constrained in a shell where different rules apply.

I've been told that E_NOTICE generates warnings that you would have
to bypass by making things more complicately and that this would
hurt one of the greatest advantages of the language: flexibility.
This does, of course, hold some truth, but I think that time and
experience has shown that this specific flexibility (E_NOTICE and
register_globals) causes too much damage and has too many security
implications to be left as is. Unexperienced programmers should be
given defaults that guide them in a right direction with good
programming practices, and leave the advanced flexibility options to
more experienced programmers.

 No doubt, this would cause many
 (perhaps even most) PHP applications out there not to install out of the
 box, but I think that setting register_globals off is a pretty pressing
 matter, and without some pain (i.e., forcing app authors to update their
 apps to work with the track_vars arrays) we won't get anywhere.

Maintaining backward compatibility at all costs has made Perl what it
is today. I've been happy that PHP has this far not taken this matter
to such limits.

 Zeev

-- 
--
  Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/


-- 
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]




RE: [PHP-DEV] Security Issues

2001-07-27 Thread Marc Boeren


 accept_parameters($user_string); // or something similar
 register_globals off.
 $user_string=$HTTP_POST_VARS[user_string];
 
 This accomplishes the same thing as your example, and doesn't 
 introduce any new syntax... I don't really see the advantage of the 
 accept_parameters idea.

Well, the programmer doesn't need to know if it was introduced by POST or
GET or whatever, and will be made to think about what parameters he/she is
accepting... thereby making him aware of the security issues.
Plus, it looks better :-)
(yeah I know, subjective...)

Cheerio, Marc.

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf

 At 08:48 26/07/2001, Rasmus Lerdorf wrote:
   Just replace your if ($ok) with if (!empty($ok)), and you have a perfect
   exploitable code that produces no warnings.
 
 But in this case someone has gone to the trouble to figure out what
 empty() does.  And generally they use empty() on things that come from the
 user anyway.  I don't think I have ever seen people use empty() to check
 to see if they themselves have set an internal variable to something.

 I have...  And quite a lot use isset(), which is much more common and
 popular than empty().  My guess is that we're dealing with a fairly big
 number of users/scripts here, which are exploitable even though they're
 'clean' scripts with no warnings.  I'm all in favour of turning E_NOTICE's
 on (I was since day one and so was Andi, but  back then, most people
 supported the 'loose' behavior of PHP/FI 2 as a default, and leave
 E_NOTICEs as an option you have to explicitly turn on).

I think you missed my point.  People use empty() and isset() on a variable
to check to see if that variable was set by the user.  As such that
variable is unclean and whether it came in via register_globals or not is
quite irrelevant.  If it is unclean it is unclean.  It doesn't matter at
all which mechanism (GET/POST/COOKIE) populated the data from a security
perspective.

 I actually think that turning E_NOTICE on is going to have a huge effect on
 a mind boggling number of scripts, probably on the same order of magnitude
 as setting register_globals to off (probably less, but not that much
 less).  I think that unless we explain explicitly and vocally why we're
 making these changes  (register_globals and/or error level), people will
 just reconfigure php.ini to the old settings - I don't think they'll start
 running after new E_NOTICE's they suddenly get after upgrading, unless
 they'd know they have a good reason to.

Baby-steps are needed for changes like this.  We can get away with the
E_NOTICE change I think.  The register_globals change is much too drastic
and it changes the basic nature of the language.  There are plenty of
people using PHP today who have no clue what an array is.

-Rasmus


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Cynic

At 10:35 7/27/2001, Rasmus Lerdorf wrote the following:
-- 
 I actually think that turning E_NOTICE on is going to have a huge effect on
 a mind boggling number of scripts, probably on the same order of magnitude
 as setting register_globals to off (probably less, but not that much
 less).  I think that unless we explain explicitly and vocally why we're
 making these changes  (register_globals and/or error level), people will
 just reconfigure php.ini to the old settings - I don't think they'll start
 running after new E_NOTICE's they suddenly get after upgrading, unless
 they'd know they have a good reason to.

Baby-steps are needed for changes like this.  We can get away with the
E_NOTICE change I think.  The register_globals change is much too drastic
and it changes the basic nature of the language.  There are plenty of
people using PHP today who have no clue what an array is.

This may be a stupid idea, but... 

When the code is ready for 4.0.7, release it as 4.0.7 with the 
first step of the changes, whatever it is, AND as 4.1.0 with all 
the changes you want.
4.0.8 would turn the screw some more (also released as 4.1.1, no 
changes to php.ini required in that branch).
Finally, when the configurations get in sync, release the code as 
4.1.x only.




[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 01:35 27/07/2001, Rasmus Lerdorf wrote:
I think you missed my point.  People use empty() and isset() on a variable
to check to see if that variable was set by the user.  As such that
variable is unclean and whether it came in via register_globals or not is
quite irrelevant.  If it is unclean it is unclean.  It doesn't matter at
all which mechanism (GET/POST/COOKIE) populated the data from a security
perspective.

I got your point, but I disagree on it.  I think that lots of users use 
isset() for implementing the same logic you demonstrated in your example, 
only in a clean, E_NOTICE-free way.  I know I used to do that, Heikki says 
he does, and my assumption is that it's a very common practice.

  I actually think that turning E_NOTICE on is going to have a huge effect on
  a mind boggling number of scripts, probably on the same order of magnitude
  as setting register_globals to off (probably less, but not that much
  less).  I think that unless we explain explicitly and vocally why we're
  making these changes  (register_globals and/or error level), people will
  just reconfigure php.ini to the old settings - I don't think they'll start
  running after new E_NOTICE's they suddenly get after upgrading, unless
  they'd know they have a good reason to.

Baby-steps are needed for changes like this.  We can get away with the
E_NOTICE change I think.  The register_globals change is much too drastic
and it changes the basic nature of the language.  There are plenty of
people using PHP today who have no clue what an array is.

I respectfully disagree :)  I think this issue is critical, and the way we 
handle it would show a lot on how serious we (less important) and PHP (more 
important) are considered.  In this case, making decision according to the 
least common denominator doesn't make since IMHO, and we should derive our 
decision from a security/reliability perspective, and not the 
newbie-friendliness perspective.

Zeev

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf

 At 01:35 27/07/2001, Rasmus Lerdorf wrote:
 I think you missed my point.  People use empty() and isset() on a variable
 to check to see if that variable was set by the user.  As such that
 variable is unclean and whether it came in via register_globals or not is
 quite irrelevant.  If it is unclean it is unclean.  It doesn't matter at
 all which mechanism (GET/POST/COOKIE) populated the data from a security
 perspective.

 I got your point, but I disagree on it.  I think that lots of users use
 isset() for implementing the same logic you demonstrated in your example,
 only in a clean, E_NOTICE-free way.  I know I used to do that, Heikki says
 he does, and my assumption is that it's a very common practice.

I think that assumption is wrong.  And also your previous assumption that
the E_ALL error_reporting level change would break just as many scripts as
the register_globals change.

The way to figure this out would be to actually go and check instead of
making such broad assumptions.  Take the first 25 projects listed at
php.net/projects.php, install them and run them with E_ALL and then with
register_globals=off and see how they do.  It's almost 3am, and I am
rather tired, but I grabbed the first one listed and installed it.  Then
clicked through it and did various things.  So here is my entry for it if
someone wants to actually take on this task of auditing the first 25 (or
more) projects:

Adaptive Website Framework
  URL: http://www.liquidbytes.net/index.php?id=143subject=/awf/

  Worked perfectly without even a single warning when run under with
  E_ALL, but failed to work at all with register_globals = Off.  A look through the
  code revealed decent checking and isset() consistently used on
  user-supplied data.

 Baby-steps are needed for changes like this.  We can get away with the
 E_NOTICE change I think.  The register_globals change is much too drastic
 and it changes the basic nature of the language.  There are plenty of
 people using PHP today who have no clue what an array is.

 I respectfully disagree :)  I think this issue is critical, and the way we
 handle it would show a lot on how serious we (less important) and PHP (more
 important) are considered.  In this case, making decision according to the
 least common denominator doesn't make since IMHO, and we should derive our
 decision from a security/reliability perspective, and not the
 newbie-friendliness perspective.

Sure the issue is critical.  I have never said otherwise.  Security is
critical.  My disagreement is in how to help users write more secure
scripts.  I do not agree that turning off register_globals will result in
significantly more secure PHP scripts out there.  It will simply cause
scripts to break in non-obvious ways and the knee-jerk fix will be to
swear at those annoying PHP folks and then turn register_globals on, or
they will do something like:

  foreach($HTTP_POST_VARS as $key=$val) $$key = $val;
  foreach($HTTP_GET_VARS as $key=$val) $$key = $val;
  foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val;

And yes, I have run across code like this.

Assuming E_ALL, register_globals only fixes the case where users forget to
initialize a variable and at the same time they use isset() or empty() to
check to see if they have set that variable.  I contend that the instances
of this are actually very rare and do not warrant the massive breakage a
change to the default register_globals change will cause.

And we haven't even explored alternative approaches to perhaps help users
catch this particular situation.  I could see a some sort of audit mode
or lint that produced a little report of external variables (anything
checked/used with or without isset/empty before they are assigned),
internal variables, constants and perhaps unused variables.

Or as has been brought up a few times, something similar to Perl's taint
mode.  Tough to do in our architecture, sure, but simply changing things
without exploring alternatives or researching the real state of the
problem doesn't make any sense to me.

-Rasmus


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Björn Schotte

* Rasmus Lerdorf wrote:
 significantly more secure PHP scripts out there.  It will simply cause
 scripts to break in non-obvious ways and the knee-jerk fix will be to
 swear at those annoying PHP folks and then turn register_globals on, or
 they will do something like:
 
   foreach($HTTP_POST_VARS as $key=$val) $$key = $val;
   foreach($HTTP_GET_VARS as $key=$val) $$key = $val;
   foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val;

I fully agree here with Rasmus and I also think this will
be the workaround for most people -- if one _does_ care
about security, he even knows what and how to do nowadays.
I don't think turning register_globals to off will evangelize
people to develop more secure scripts/applications.

-- 
PHP Schulungen und| International PHP Conference
Schulungsmaterial:| 05. - 07.11.2001
http://thinkphp.de/   |  Astron Hotel, Frankfurt
http://rent-a-phpwizard.de/schulungen.php |  http://www.php-kongress.de/

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Peter Petermann


 I fully agree here with Rasmus and I also think this will
 be the workaround for most people -- if one _does_ care
 about security, he even knows what and how to do nowadays.
 I don't think turning register_globals to off will evangelize
 people to develop more secure scripts/applications.
thats it.

what we could do to make people to write more secure script is:
- telling them to do so,
- telling them what is insecure
- telling them why something is insecure
- writing a special type of documentation, about  how to write secure scripts

maybe we could do something like a php-security-central, where everyone who wants
to learn about security could read this kind of documenation, a special mailinglist
where issues about security of php-applications is discussed, etc.

you cant fight security holes without knowing what the hole is, and you
cant make others writing secure apps without teaching them about how this works,
we shouldnt change php, we should give more information about this problems,
so everyone is able to learn how to avoid them.

- Peter 
-- 
*ZIMT - where PHP meets needs*
Homepage: www.cyberfly.net - [EMAIL PROTECTED]
PHP Usergroups: www.phpug.de - [EMAIL PROTECTED]
Just for Fun: www.fist-center.de - [EMAIL PROTECTED]

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 03:09 27/07/2001, Rasmus Lerdorf wrote:
  At 01:35 27/07/2001, Rasmus Lerdorf wrote:
  I think you missed my point.  People use empty() and isset() on a variable
  to check to see if that variable was set by the user.  As such that
  variable is unclean and whether it came in via register_globals or not is
  quite irrelevant.  If it is unclean it is unclean.  It doesn't matter at
  all which mechanism (GET/POST/COOKIE) populated the data from a security
  perspective.
 
  I got your point, but I disagree on it.  I think that lots of users use
  isset() for implementing the same logic you demonstrated in your example,
  only in a clean, E_NOTICE-free way.  I know I used to do that, Heikki says
  he does, and my assumption is that it's a very common practice.

I think that assumption is wrong.  And also your previous assumption that
the E_ALL error_reporting level change would break just as many scripts as
the register_globals change.

I didn't say just as many, but same order of magnitude.  Most of the 
scripts I came across in the past 4 years would not run properly with 
E_NOTICE's turned on.  Even if it's just 20% of the scripts, it's still the 
same order of magnitude.  No doubt, the number would be less, since turning 
register_globals off would break virtually all apps out there today, but 
it'd be a major blow still.  I argue that the security benefit from it is 
much smaller than doing the real thing, which is turning register_globals off.

The way to figure this out would be to actually go and check instead of
making such broad assumptions.  Take the first 25 projects listed at
php.net/projects.php, install them and run them with E_ALL and then with
register_globals=off and see how they do.  It's almost 3am, and I am
rather tired, but I grabbed the first one listed and installed it.  Then
clicked through it and did various things.  So here is my entry for it if
someone wants to actually take on this task of auditing the first 25 (or
more) projects:

I think that's a good idea, but given the fact that the advisory mentioned 
exploits for some very common apps means that either
- These apps are not E_NOTICE 'safe', otherwise, these issues would have 
been resolved
or
- These issues would not have been solved by turning E_NOTICE's on

Sure the issue is critical.  I have never said otherwise.  Security is
critical.  My disagreement is in how to help users write more secure
scripts.  I do not agree that turning off register_globals will result in
significantly more secure PHP scripts out there.

I think that's the source of our disagreement - I think it's going to push 
the base security level of PHP applications a few notches all by itself.


   It will simply cause
scripts to break in non-obvious ways and the knee-jerk fix will be to
swear at those annoying PHP folks and then turn register_globals on, or
they will do something like:

   foreach($HTTP_POST_VARS as $key=$val) $$key = $val;
   foreach($HTTP_GET_VARS as $key=$val) $$key = $val;
   foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val;

And yes, I have run across code like this.

If somebody wants to shoot himself in the head, he's quite welcome to do 
it.  But when you hand a gun over to somebody, you don't point it at his 
head, but safely hand it to his hands.  What he does afterwards is his own 
business (assuming he doesn't come after you :)

Assuming E_ALL, register_globals only fixes the case where users forget to
initialize a variable and at the same time they use isset() or empty() to
check to see if they have set that variable.  I contend that the instances
of this are actually very rare and do not warrant the massive breakage a
change to the default register_globals change will cause.

See my argument above.  The most common PHP apps were exploitable, by 
exploits which by definition would have either not been resolved by turning 
on E_NOTICE's, or they're E_NOTICE-unsafe.  In addition, having seen quite 
a bit of PHP code that does use this kind of methods (which are basically 
the correct development methods in PHP when you have E_NOTICE's set to on, 
which good coders do), I think that it's crucial that we give an answer to 
this audience as well.  Again, even if it's just 20% of the cases, or even 
2% of the cases, if it leads to security issues, that's an ENORMOUS amount.

And we haven't even explored alternative approaches to perhaps help users
catch this particular situation.  I could see a some sort of audit mode
or lint that produced a little report of external variables (anything
checked/used with or without isset/empty before they are assigned),
internal variables, constants and perhaps unused variables.

I don't think that's related.  register_globals encourages insecure coding, 
and should be phased out as quickly as possible, regardless of whatever 
other security analysis methods we may have or add in the future.

Or as has been brought up a few times, something similar to Perl's taint
mode.  Tough to do in 

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

Guys,

Please read the advisory.  You simply can't say that register_globals=off 
wouldn't have resulted in more secure apps, because there are *3* examples 
(or more, I don't remember) there of applications that would have not been 
exploitable had register_globals=on was in effect!
Unless we make the very unlikely assumption that these are the only apps 
that were vulnerable (and from what I understand in the advisory, pretty 
much any app they checked was vulnerable at one point or another), saying 
that setting register_globals to off is going to improve security is pretty 
much a fact, and not an opinion.

Zeev

At 03:15 27/07/2001, Björn Schotte wrote:
* Rasmus Lerdorf wrote:
  significantly more secure PHP scripts out there.  It will simply cause
  scripts to break in non-obvious ways and the knee-jerk fix will be to
  swear at those annoying PHP folks and then turn register_globals on, or
  they will do something like:
 
foreach($HTTP_POST_VARS as $key=$val) $$key = $val;
foreach($HTTP_GET_VARS as $key=$val) $$key = $val;
foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val;

I fully agree here with Rasmus and I also think this will
be the workaround for most people -- if one _does_ care
about security, he even knows what and how to do nowadays.
I don't think turning register_globals to off will evangelize
people to develop more secure scripts/applications.

--
PHP Schulungen und| International PHP Conference
Schulungsmaterial:| 05. - 07.11.2001
http://thinkphp.de/   |  Astron Hotel, Frankfurt
http://rent-a-phpwizard.de/schulungen.php |  http://www.php-kongress.de/

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


--
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 20:22 02/01/1999, Peter Petermann wrote:

  I fully agree here with Rasmus and I also think this will
  be the workaround for most people -- if one _does_ care
  about security, he even knows what and how to do nowadays.
  I don't think turning register_globals to off will evangelize
  people to develop more secure scripts/applications.
thats it.

what we could do to make people to write more secure script is:
- telling them to do so,
- telling them what is insecure
- telling them why something is insecure
- writing a special type of documentation, about  how to write secure scripts

These methods are flawed by definition, since they assume that you'd be 
able to communicate to all, or even just most users.  Are they good things 
to do?  Definitely.  Are they enough?  Not really, because as the advisory 
claims, if the language encourages you to write insecure code (assuming you 
don't read 'general' documentation, which is very common), the language is 
at fault.  Will the applications of such people always be secure now that 
register_globals is off?  Of course not, but it's definitely going to knock 
down a huge amount of exploits in their apps, and there are good chances 
that these would be the only exploits in it.

maybe we could do something like a php-security-central, where everyone 
who wants
to learn about security could read this kind of documenation, a special 
mailinglist
where issues about security of php-applications is discussed, etc.

you cant fight security holes without knowing what the hole is, and you
cant make others writing secure apps without teaching them about how this 
works,
we shouldnt change php, we should give more information about this problems,
so everyone is able to learn how to avoid them.

The way I see it, register_globals=on is pretty much like a swiss cheese 
factory as far as it comes to security holes.  No php-security-central is 
going to help here, and closing this factory down *is* going to help a 
lot.  This doesn't come to say it'd eliminate all security holes out there, 
obviously, just a great deal of them.

Again, I want to say that there are some good ideas being raised in this 
discussion, but given the fact (or my view, rather) that 
register_globals=on is *SUCH* a bad thing, none of them has too much to do 
with it.  They're good and should be discussed regardless of this issue, 
which should be resolved specifically, and in my opinion, by changing the 
default.

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 03:36 27/07/2001, Zeev Suraski wrote:
Guys,

Please read the advisory.  You simply can't say that register_globals=off 
wouldn't have resulted in more secure apps, because there are *3* examples 
(or more, I don't remember) there of applications that would have not been 
exploitable had register_globals=on was in effect!

... had register_globals=on not be in effect

3:45am, signing off for today :)

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Alexander Wagner

Peter Petermann wrote:
  I fully agree here with Rasmus and I also think this will
  be the workaround for most people -- if one _does_ care
  about security, he even knows what and how to do nowadays.
  I don't think turning register_globals to off will evangelize
  people to develop more secure scripts/applications.

 thats it.

I see your point, but I disagree.
Register_globals is a lanugage-feature which can result in 
security-gaps when people don't initialize their variables.
It's a common mistake, a pitfall, especially for beginners, that could 
be resolved by turning register_globals off.
There's a lot of beginners using PHP, and this wouldn't only make their 
applications a little more secure (just a little, but better than 
nothing), it will also teach them manners. Using $HTTP_*_VARS ist 
cleaner, IMO.

 what we could do to make people to write more secure script is:
 - telling them to do so,
 - telling them what is insecure
 - telling them why something is insecure
 - writing a special type of documentation, about  how to write secure
 scripts

Please, can you say beginner? Once people read that kind of stuff, 
they are not beginners any more. They aren't the problem.

You can't force people to write secure applications, but you can make 
it easier.

regards
Wagner

-- 
Madness takes its toll. Please have exact change.

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Peter Petermann

 register_globals is off?  Of course not, but it's definitely going to knock 
 down a huge amount of exploits in their apps, and there are good chances 
 that these would be the only exploits in it.
as rasmus wrote,
this would only result in users using foreach to do that.
 
 you cant fight security holes without knowing what the hole is, and you
 cant make others writing secure apps without teaching them about how this 
 works,
 we shouldnt change php, we should give more information about this problems,
 so everyone is able to learn how to avoid them.
 The way I see it, register_globals=on is pretty much like a swiss cheese 
 factory as far as it comes to security holes.  No php-security-central is 
 going to help here, and closing this factory down *is* going to help a 
 lot.  This doesn't come to say it'd eliminate all security holes out there, 
 obviously, just a great deal of them.
 discussion, but given the fact (or my view, rather) that 
 register_globals=on is *SUCH* a bad thing, none of them has too much to do 
 with it.  They're good and should be discussed regardless of this issue, 
 which should be resolved specifically, and in my opinion, by changing the 
 default.

as long there are peoples driving car, without knowing howto drive,
they are dangerous for all of us.
but do you think driving car should no longer be allowed?
you cant make mercedes, porsche etc. responsible for people killed
by people who cant drive but did.
i think we are talking about something like this right now,
the language is not responsible for users, who dont know about security
and, 
PHP is written in C, so maybe C should be changed to make it impossible to
create in php something like register_globals=on... 
this is what you say, if you blame the language for that
php is just a language, if people are not able to use it the right way
it is nothing wrong with the language, it is about the people


-- 
*ZIMT - where PHP meets needs*
Homepage: www.cyberfly.net - [EMAIL PROTECTED]
PHP Usergroups: www.phpug.de - [EMAIL PROTECTED]
Just for Fun: www.fist-center.de - [EMAIL PROTECTED]

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Peter Petermann

  what we could do to make people to write more secure script is:
  - telling them to do so,
  - telling them what is insecure
  - telling them why something is insecure
  - writing a special type of documentation, about  how to write secure
  scripts
 Please, can you say beginner? Once people read that kind of stuff, 
 they are not beginners any more. They aren't the problem.
ive seen a lot of professionells who dont care about security,
and i have seen beginner who do.

 
 You can't force people to write secure applications, but you can make 
 it easier.
i dont think it is easier to write more secure applications
with turning a feature of.

- Peter

-- 
*ZIMT - where PHP meets needs*
Homepage: www.cyberfly.net - [EMAIL PROTECTED]
PHP Usergroups: www.phpug.de - [EMAIL PROTECTED]
Just for Fun: www.fist-center.de - [EMAIL PROTECTED]

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 20:53 02/01/1999, Peter Petermann wrote:
  register_globals is off?  Of course not, but it's definitely going to 
 knock
  down a huge amount of exploits in their apps, and there are good chances
  that these would be the only exploits in it.
as rasmus wrote,
this would only result in users using foreach to do that.

Two things:

(a) How about just setting register_globals to on?  We're not talking about 
taking this option away, for now, just turn it off by default.
(b) As I said, if someone wants to use a gun to shoot himself in the head, 
he's welcome to do so.  The least we could do is hand him the gun safely 
pointed in the other direction, and not point it to his brain.

as long there are peoples driving car, without knowing howto drive,
they are dangerous for all of us.
but do you think driving car should no longer be allowed?
you cant make mercedes, porsche etc. responsible for people killed
by people who cant drive but did.

You argue that having a car with no brakes and just a better airbag is 
acceptable?  Peter, we're *NOT* talking about absolute things in here.  Of 
course, using your example, the only way to protect users, is by preventing 
them from writing scripts.  That's not the issue here.  The issue here is 
similar to giving them a car without brakes, and expecting them to handle 
it.  Can you blame the driver for the accident with a brakeless car?  It'd 
be quite dumb...  Shipping PHP with register_globals set to on is 
equivalent to shipping cars without brakes.  You hope that the user would 
be bright enough to install brakes, or use all sorts of advanced preventive 
measures like airbags, but the right thing to

i think we are talking about something like this right now,
the language is not responsible for users, who dont know about security
and,
PHP is written in C, so maybe C should be changed to make it impossible to
create in php something like register_globals=on...
this is what you say, if you blame the language for that
php is just a language, if people are not able to use it the right way
it is nothing wrong with the language, it is about the people

I strongly suspect you haven't read the advisory, because it deals exactly 
with these issues.  In a perfect world, we'd just have something like 
security=on that'd handle all of the possible security issues.  Since non 
of us is holding his breath for such a world, we should try to provide a 
system that at least isn't prone to common, repeated and innocent looking 
security bugs.  PHP with register_globals=on is.

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 20:58 02/01/1999, Peter Petermann wrote:
i dont think it is easier to write more secure applications
with turning a feature of.

Read the advisory before your next post or I'll have Kristian smack you the 
next time he sees you! :)

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Björn Schotte

* Zeev Suraski wrote:
 equivalent to shipping cars without brakes.  You hope that the user would 
 be bright enough to install brakes,

Hoping that is not enough. If you really change the
behaviour to ship PHP with register_globals to off,
then I suggest you should also ship some README_Security
or something similar where Kris writes a nice tutorial
about writing secure PHP applications. (This README_Security
should also be inserted into the Manual and all places where
it makes sense) Also, before doing make install a
less README_Security should be done by the makefile.

-- 
PHP Schulungen und| International PHP Conference
Schulungsmaterial:| 05. - 07.11.2001
http://thinkphp.de/   |  Astron Hotel, Frankfurt
http://rent-a-phpwizard.de/schulungen.php |  http://www.php-kongress.de/

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Alexander Wagner

Peter Petermann wrote:
 i dont think it is easier to write more secure applications
 with turning a feature of.

In this particular case, it would. There are several reported cases of 
security-holes caused by this feature. Without it, there would be fewer 
insecure PHP-applications out there.

Thats a fact. Thats the past. Now let's talk about the future.

Turning register_globals off won't fix old code. If code relies on 
register_globals, people will fix it with foreach (Rasmus' example), 
or by turning register_globals on.

But that's not the point. The point is that people who don't care about 
security or coding style (beginners or professionals, doesn't really 
matter) are less likely to write insecure code, because there's one 
mistake less that they can make. As long as they stick to the defaults, 
anyway.

regards
Wagner

-- 
Madness takes its toll. Please have exact change.

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Phil Driscoll

I must be much more stupid than I give myself credit for.

Changing to register globals=off surely does very little in terms of security 
for the easily fakeable GPC variables. I can see that for environment 
variables the picture is slightly different - you do need to be sure that 
this *really* is an  SSL connection etc.

I propose the following - which will break *NO* scripts.

Examine the environment variable issues such as those which pertain to SSL 
and then, just as recently happened with the file upload vulnerability, 
implement some functions which do 'full strength' checking for the user
e.g. is_secure_connection()

Then to address the uninitialised variables issue, modify the error reporting 
system so that the default setting (E_SECURE) emails warnings and errors to 
the administrator rather than displaying them in the output.

Maybe some other refinement of the technique involving a sensible mixture of 
display_error, error_reporting, and a new email_errors directive might be 
better.

With this solution, we break no scripts and we encourage more secure 
programming.

So now, tear it to pieces :)

Cheers
-- 
Phil Driscoll


-- 
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]




RE: [PHP-DEV] Security Issues

2001-07-27 Thread Marc Boeren


 Changing to register globals=off surely does very little in 
 terms of security for the easily fakeable GPC variables. 

Maybe not for these variables, but other variables used in your script
cannot be faked by passing them as HTTP_POST_VARS.

e.g., with register_globals=off 

if ($HTTP_POST_VARS['user_string'] == 'check_for_security') {
// do something, but be aware of security issues
}

if ($internal_variable == 'whatever') {
// do something, knowing that a user could never have set this
}

The second check is where a lot of scripts are exploitable, I think, if
register_globals=on, because programmers do not expect user-input in this
variable.

Cheerio, Marc.

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Phil Driscoll

On Friday 27 July 2001 12:51, Marc Boeren wrote:
 if ($internal_variable == 'whatever') {
 // do something, knowing that a user could never have set this
 }

 The second check is where a lot of scripts are exploitable, I think, if
 register_globals=on, because programmers do not expect user-input in this
 variable.

...but will be caught perfectly by E_ALL
-- 
Phil Driscoll

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Peter Petermann

 (b) As I said, if someone wants to use a gun to shoot himself in the head, 
 he's welcome to do so.  The least we could do is hand him the gun safely 
 pointed in the other direction, and not point it to his brain.
we are not talking about people who want to have security holes, we are 
talking about people who do not know they have..
this is like giving a loaded weapon to someone, dont telling him that
he could kill with it.

 it.  Can you blame the driver for the accident with a brakeless car?  It'd 
 be quite dumb...  Shipping PHP with register_globals set to on is 
 equivalent to shipping cars without brakes.  You hope that the user would 
 be bright enough to install brakes, or use all sorts of advanced preventive 
 measures like airbags, but the right thing to
well, i think you misunderstood me.
we are not talking of a brakeless car, and we are not talking
about a language who is not able to be used secure.
we are talking about something that has the abilities to be secure,
we just need to teach the people how,
the same as people need to learn how to drive, 
without they can start the engine, and dont know how to brake,
but the brakes are there!

 i think we are talking about something like this right now,
 the language is not responsible for users, who dont know about security
 and,PHP is written in C, so maybe C should be changed to make it impossible to
 create in php something like register_globals=on...
 this is what you say, if you blame the language for that
 php is just a language, if people are not able to use it the right way
 it is nothing wrong with the language, it is about the people

 I strongly suspect you haven't read the advisory, because it deals exactly 
 with these issues.  In a perfect world, we'd just have something like 
 security=on that'd handle all of the possible security issues.  Since non 
 of us is holding his breath for such a world, we should try to provide a 
 system that at least isn't prone to common, repeated and innocent looking 
 security bugs.  PHP with register_globals=on is.
i have read the advisory, but i cant agree that register_globals=on is the problem
the user, who cant deal with that is the problem

php is a language,
if people dont secure there applications,
they are wrong, not php is.

if i give machines to you, allowing you to build cars
secure ones, and insecure ones (those without brakes ;) 
and you build a insecure one, thats not my fault.
but if i want to help you, i wouldnt turn of one of the
switches you use, and hope you dont use another one for the same,
i would teach you how to build the secure cars,
how to do crashtests etc.

- Peter

-- 
*ZIMT - where PHP meets needs*
Homepage: www.cyberfly.net - [EMAIL PROTECTED]
PHP Usergroups: www.phpug.de - [EMAIL PROTECTED]
Just for Fun: www.fist-center.de - [EMAIL PROTECTED]

-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Heikki Korpela

On Fri, 27 Jul 2001, Zeev Suraski wrote:

 (a) How about just setting register_globals to on?  We're not talking about
 taking this option away, for now, just turn it off by default.
 (b) As I said, if someone wants to use a gun to shoot himself in the head,
 he's welcome to do so.  The least we could do is hand him the gun safely
 pointed in the other direction, and not point it to his brain.

We know that tricks and complications don't make anything more
secure - quite the contrary, they make the applications more
bug-prone.

We also know that good programming practices and routines help avoid
bugs. Alone, they won't help, but a person who is adviced or even
enforced to apply those practices will usually wonder: huh, why
shouldn't I use tempnam or gets? Hmm, maybe I'll read the manual
page Indirectly, this also leads to changes in attitude as
the programmer starts to realize that the threats he or she is
being warned of are real and not mere paranoia of people encrypting
their swap.

The question here is whether or not register_globals is a trick
or a way to advise people of better practices.

Would anyone like to show me the design that gets innecessarily
('innecessary' meaning 'if the application wasn't well designed
in the first place, it's obvious it should be changed') complicated
when you enforce E_NOTICE and register_globals?

//

Everyone's emphasizing documentation on security concerns. What would
be the first things I'd like to see (or do) tre he possible security
implications for function calls or language structures in the reference
manual, next to their corresponding references. See, for example,
the bugs section of one implementation of the manual page for
mktemp(3):

http://www.openbsd.org/cgi-bin/man.cgi?query=mktempsektion=3

Yes, sure it would be nice if there was a guide to secure programming
in PHP. Oh, but wait... I think there are some; but people don't
necessarily read them. They think that security issues don't concern
them.

-- 
--
  Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf

 Peter Petermann wrote:
   I fully agree here with Rasmus and I also think this will
   be the workaround for most people -- if one _does_ care
   about security, he even knows what and how to do nowadays.
   I don't think turning register_globals to off will evangelize
   people to develop more secure scripts/applications.
 
  thats it.

 I see your point, but I disagree.
 Register_globals is a lanugage-feature which can result in
 security-gaps when people don't initialize their variables.
 It's a common mistake, a pitfall, especially for beginners, that could
 be resolved by turning register_globals off.

And is resolved by turning on E_NOTICE.

 Please, can you say beginner? Once people read that kind of stuff,
 they are not beginners any more. They aren't the problem.

 You can't force people to write secure applications, but you can make
 it easier.

Or you can simply stop these people from using PHP which is another effect
turning off register_globals will have.

Java does not have this problem because Java is so complex that this same
set of users can not program in Java.  Fixing this problem by making PHP
more complex and eliminating these problem users is a bad idea as far as
I am concerned.

-Rasmus


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf

 Peter Petermann wrote:
  i dont think it is easier to write more secure applications
  with turning a feature of.

 In this particular case, it would. There are several reported cases of
 security-holes caused by this feature. Without it, there would be fewer
 insecure PHP-applications out there.

 Thats a fact. Thats the past. Now let's talk about the future.

Please, everyone keeps stating this and immediately jumping to turning
register_globals off as being the one and only solution simply because it
is the most obvious solution.

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.

 But that's not the point. The point is that people who don't care about
 security or coding style (beginners or professionals, doesn't really
 matter) are less likely to write insecure code, because there's one
 mistake less that they can make. As long as they stick to the defaults,
 anyway.

And one language less that these people are able to use.

-Rasmus


-- 
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]




RE: [PHP-DEV] Security Issues

2001-07-27 Thread Brian Tanner

Is all of this springing from that security advisory that was published a
short while ago?

I remember reading that, and feeling that many of the issues were overblown
(if I'm thinking of the same one).

Also, wasn't that advisory just written by some guy?  Its not like W3C is
writing a web security standards document and made an example out of PHP or
something, its just the security suggestions/opinions of some guy.

Seems like a whole lot of trouble (breaking thousands of scripts) -- just to
appease some document by some guy.

Also, about this whole car with no brakes or gun aimed at the head
business.  I like the car analogy... and the register_globals=off.

See.. turning register_globals off is like adding a huge brake, and then
hiding the accelerator.  For beginner drivers, or existing drivers that are
not up on current events, it will be very hard to get going.

I'd say that leaving register_globals on is *exactly* like a regular car.
Its dangerous, hell yeah.  However, as long as you learn how to use it in an
enclosed environment, and practice the safety techniques -- you are not too
much of a danger to others when you get onto the highway.

Same concept applies... if you take a beginner and put them on an enterprise
server writing code that manipulates a DNS file or does updates and deletes
to a crucial database, you are asking for trouble.

Thats why people write simple, inconsequential application as they are
*learning*, and after that have some experience, they should write things
where they can actually hurt someone.

Anyway, thats my .02.  I'm done talking about this issue... its a difference
of opinion, which is generally very hard to resolve -- and no amount of
logical dicussion can change the mind of either group.

-Brian T

-Original Message-
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: July 25, 2001 6:29 PM
To: Rasmus Lerdorf
Cc: Andy; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Security Issues


At 07:31 25/07/2001, Rasmus Lerdorf wrote:
Because not everyone agrees that this is actually highly recommended.
Most third-party PHP code you may want to run will not work very well with
register_globals off.  And turning register_globals off isn't actually as
helpful from a security perspective as many people seem to think.

The basic thing it would help would be in cases like this:

?
  if($user=='rasmus') {
$ok = true;
  }

  if($ok) {
... secure code ...
  }
?

Here if someone injected ?ok=1 in the URL then the secure code part would
be run regardless of the $user setting.  Obviously the fix here is to make
sure that $ok is initialized to false at the top of the script.  But since
many people forget to do that, turning off register_globals fixes the
problem.

I tend to agree with the advisory, in the sense that register_globals=on
encourages insecure code, and it would in fact help to disable it by
default.  It's true that some (many) people don't understand that they
shouldn't 'trust' any data coming from POST or cookies anymore than they
should trust GET (well, in practice - slightly more, as it takes slightly
more advanced users to work around POST or cookies, than it does to add GET
variables to the URL).  However, *lots* of pieces of code, probably even
most of them, are vulnerable to logic bugs because of register_globals set
to on, bugs that would have otherwise not exist.  Bugs which occur due to
misunderstanding the 'reliability' of the form data sources are (much) more
rare, and usually, if not always, involve basic misunderstanding of the Web
environment.  Security issues that are a result of register_globals=on
often occur even when the user is knowledgeable, and tries to avoid
security bugs.  The WTF factor there is pretty high.

The change I would rather see in php.ini would be to have the default
error_level be set to E_ALL because then the above script would generate a
warning complaining about the fact that $ok was not initialized.  Since
PHP can determine when variables are not initialized the case for
turning register_globals off in this example is rather weak.

PHP does not require or even encourage initialization of variables -
setting $ok to 1, and then checking it with empty() is considered 'clean'
code, but it'd be equally insecure.


Many people also seem to think that it is somehow more secure if you know
exactly where data is coming from.  So that if you use
$HTTP_POST_VARS['var'] then somehow $var is not spoofable because if you
put ?var=foo in the URL it won't affect anything.  But injecting variables
into POST or Cookie data is trivial so I don't see this argument holding
much water either.

As I said, it's easy, but it is considerably less easy than it is to add
GET variables.  Let alone the fact that we're also dealing with SERVER and
ENV vars, which cannot be injected at all.  How about people who check
server variables, such as HTTPS, using isset()?  register_globals

Re: [PHP-DEV] Security Issues

2001-07-27 Thread John Donagher

On Fri, 27 Jul 2001, Zeev Suraski wrote:

 
It will simply cause
 scripts to break in non-obvious ways and the knee-jerk fix will be to
 swear at those annoying PHP folks and then turn register_globals on, or
 they will do something like:
 
foreach($HTTP_POST_VARS as $key=$val) $$key = $val;
foreach($HTTP_GET_VARS as $key=$val) $$key = $val;
foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val;
 
 And yes, I have run across code like this.
 
 If somebody wants to shoot himself in the head, he's quite welcome to do 
 it.  But when you hand a gun over to somebody, you don't point it at his 
 head, but safely hand it to his hands.  What he does afterwards is his own 
 business (assuming he doesn't come after you :)
 

I think Rasmus is right. We've been shooting the guy in the head for the last
few years while register_globals was/is on. People incorporating other PHP
libraries like Horde/PHPLIB (just examples) and what have you, will immediately
break, even after they fix their own code, the third party libraries will still
be broken. This means that the library maintainers will be under significant
pressure to release a patch; fixing the code to use a safer method of accessing
user data. My guess is the above patch is what will make it in, not because the
guy doesn't understand it's bad, but he was already shot in the head by the
default php.ini setting and so he's not really _losing_ anything now.

--

John Donagher
Application Engineer
Intacct Corp. - Powerful Accounting on the Web
408-395-0989
720 University Ave.
Los Gatos CA 95032
www.intacct.com

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Jason Greene

I have been watching this thread for too long and I can no longer resist commenting.

If a programmer does not initialize SECURE variables properly, he is going to make far 
worse
security decisions in his software. Next thing we are going to hear is that php does 
not auto TAINT check
parsed variables. I personally disagree with making register_globals=off a default. I 
really don't  think it will
make that big of a difference, and come on everyone, this is one of the coolest 
features of php.



-Jason

- Original Message - 
From: Rasmus Lerdorf [EMAIL PROTECTED]
To: Alexander Wagner [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, July 27, 2001 9:37 AM
Subject: Re: [PHP-DEV] Security Issues


  Peter Petermann wrote:
I fully agree here with Rasmus and I also think this will
be the workaround for most people -- if one _does_ care
about security, he even knows what and how to do nowadays.
I don't think turning register_globals to off will evangelize
people to develop more secure scripts/applications.
  
   thats it.
 
  I see your point, but I disagree.
  Register_globals is a lanugage-feature which can result in
  security-gaps when people don't initialize their variables.
  It's a common mistake, a pitfall, especially for beginners, that could
  be resolved by turning register_globals off.
 
 And is resolved by turning on E_NOTICE.
 
  Please, can you say beginner? Once people read that kind of stuff,
  they are not beginners any more. They aren't the problem.
 
  You can't force people to write secure applications, but you can make
  it easier.
 
 Or you can simply stop these people from using PHP which is another effect
 turning off register_globals will have.
 
 Java does not have this problem because Java is so complex that this same
 set of users can not program in Java.  Fixing this problem by making PHP
 more complex and eliminating these problem users is a bad idea as far as
 I am concerned.
 
 -Rasmus
 
 
 -- 
 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 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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 04:33 27/07/2001, Phil Driscoll wrote:
I must be much more stupid than I give myself credit for.

Changing to register globals=off surely does very little in terms of security
for the easily fakeable GPC variables. I can see that for environment
variables the picture is slightly different - you do need to be sure that
this *really* is an  SSL connection etc.

Have you read the advisory?  That's simply not true.
There are two main types of security problems related to this:
(a) Ones that originate in the fact that people don't know they mustn't 
trust any input coming from the user, be it GET, POST or cookies, that 
they're all insecure
(b) Ones that don't, and there are many of them

For those of type (a), register_globals being off or on doesn't change 
much.  For (b), it does, big time.

I propose the following - which will break *NO* scripts.

Examine the environment variable issues such as those which pertain to SSL
and then, just as recently happened with the file upload vulnerability,
implement some functions which do 'full strength' checking for the user
e.g. is_secure_connection()

That's the unthorough and prone-to-errors approach.  It's like trying to 
fill each and every hole in a piece of Swiss cheese.

Then to address the uninitialised variables issue, modify the error reporting
system so that the default setting (E_SECURE) emails warnings and errors to
the administrator rather than displaying them in the output.

Maybe some other refinement of the technique involving a sensible mixture of
display_error, error_reporting, and a new email_errors directive might be
better.

With this solution, we break no scripts and we encourage more secure
programming.

So now, tear it to pieces :)

It won't really address the issues that were raised in the advisory, will 
be prone to errors (i.e., it's pretty much impossible for us to think of 
everything), and I'd argue that it'd be less convenient on the long run, as 
people know and expect to rely on environment/server variables.

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 04:48 27/07/2001, Peter Petermann wrote:
well, i think you misunderstood me.
we are not talking of a brakeless car, and we are not talking
about a language who is not able to be used secure.
we are talking about something that has the abilities to be secure,
we just need to teach the people how,
the same as people need to learn how to drive,
without they can start the engine, and dont know how to brake,
but the brakes are there!

We are talking about a brakeless car here.  It's not impossible to drive a 
brakeless car.  If you're aware of it, you can probably drive around 
reasonably, if you pay close attention all the time, and drive slow 
enough.  You may be proficient enough to use the parking-brakes instead 
too.  But it's much less secure by definition.  register_globals=off means 
significantly increased probability for security trouble.  It's as simple 
as that.

i have read the advisory, but i cant agree that register_globals=on is 
the problem
the user, who cant deal with that is the problem

php is a language,
if people dont secure there applications,
they are wrong, not php is.

That's where I, Kristian, the advisory and others disagree.  If a random 
PHP app you'd pick, even one written by a good coder that is written in a 
modular and clean way, is likely to have bugs related to this feature, than 
it means the feature is at fault.  In a perfect world, people would be able 
to work alongside that feature to write secure apps, as it is possible, but 
it's *DIFFICULT*, and it's non intuitive.  Thus, in the average case, it 
would lead to security bugs.  Thus, it's flawed and should be changed.

if i give machines to you, allowing you to build cars
secure ones, and insecure ones (those without brakes ;)
and you build a insecure one, thats not my fault.

That's not the case here.  Peter, we're not talking about liability 
concerns.  It's not as if we're afraid one of those users would sue us 
because we provided him with an insecure language.  It's about the 
perception of PHP.  If you think that PHP is going to retain a reputation 
of a good language, when every 2nd PHP application out there ends up having 
security problems, and when advisories repeatedly find flaws which they, as 
well as a large number of PHP developers believe to be related to PHP's 
behavior, you're wrong.  This hurts PHP big time.

but if i want to help you, i wouldnt turn of one of the
switches you use, and hope you dont use another one for the same,
i would teach you how to build the secure cars,
how to do crashtests etc.

That's exactly like providing one with a brakeless car, and investing a 
huge amount of resources on teaching him how to drive slower and using the 
parking brakes to achieve equivalent safety.  It works, but it's wrong.

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 07:37 27/07/2001, Rasmus Lerdorf wrote:
  I see your point, but I disagree.
  Register_globals is a lanugage-feature which can result in
  security-gaps when people don't initialize their variables.
  It's a common mistake, a pitfall, especially for beginners, that could
  be resolved by turning register_globals off.

And is resolved by turning on E_NOTICE.

That's simply not true.  It can solve it only in a subset of the cases, 
maybe a fairly large subset, but definitely not anywhere close to 
100%.  From my experience it'd be perhaps half of the cases, and it would 
especially be useless with those apps which were written by good coders, 
that use isset(), and that were written to be E_NOTICE free.


  Please, can you say beginner? Once people read that kind of stuff,
  they are not beginners any more. They aren't the problem.
 
  You can't force people to write secure applications, but you can make
  it easier.

Or you can simply stop these people from using PHP which is another effect
turning off register_globals will have.

That's also not true.  Is using $foo all that better than $_GET[foo]?  I 
don't think so.  As a matter of fact, the 2nd alternative is probably going 
to be preferred by a fair amount of users, as it's much clearer what you're 
dealing with.

Java does not have this problem because Java is so complex that this same
set of users can not program in Java.  Fixing this problem by making PHP
more complex and eliminating these problem users is a bad idea as far as
I am concerned.

But it isn't.  It's by fixing an inherent design flaw in PHP.  The proposed 
target situation is *NOT* any more difficult to the users than the 
situation is today.  Yes, there's going to be some great deals of pain for 
those who migrate, but new comers will find it equally easy (at the least), 
and old users will be made aware, quite clearly, that this feature is 
unsafe.  They can always turn it back on if they wish to take the 
chances.  Right now, we're taking the chances for them.

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 07:44 27/07/2001, Rasmus Lerdorf wrote:
  Peter Petermann wrote:
   i dont think it is easier to write more secure applications
   with turning a feature of.
 
  In this particular case, it would. There are several reported cases of
  security-holes caused by this feature. Without it, there would be fewer
  insecure PHP-applications out there.
 
  Thats a fact. Thats the past. Now let's talk about the future.

Please, everyone keeps stating this and immediately jumping to turning
register_globals off as being the one and only solution simply because it
is the most obvious solution.

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 an important step, that as I said, I wanted to make for years.  I 
just argue that as protective as you are over register_globals=on, the real 
flaw is there, and this is the place it should be fixed.  Fixing the fact 
that E_NOTICE is on may also be viable, but in practice:
- A huge number of cases where E_NOTICE's will be generated isn't related 
to security in any way, and people will be kind of pissed by it, and 
probably turn it back off
- On the contrary, if we disable register_globals, than we get rid out of 
all of the security issues related, without forcing people to have E_NOTICE 
on.  For instance, Perl::CGI has E_NOTICE's off by default (Perl), but it's 
not prone to these attacks because it behaves like register_globals=off.

If we distribute a php.ini-recommended, we can, and probably should enable 
E_NOTICE's by default.  It's not the solution to the problem raised in the 
advisory.

  But that's not the point. The point is that people who don't care about
  security or coding style (beginners or professionals, doesn't really
  matter) are less likely to write insecure code, because there's one
  mistake less that they can make. As long as they stick to the defaults,
  anyway.

And one language less that these people are able to use.

That's an empty statement, Rasmus...  The auto-registered form variables 
are not any less usable if we change the access method to them 
slightly.  I'd argue it actually makes the code much more readable and 
newbie-friendly, actually.

Zeev


-- 
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]




RE: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 10:19 27/07/2001, Brian Tanner wrote:
Is all of this springing from that security advisory that was published a
short while ago?

I remember reading that, and feeling that many of the issues were overblown
(if I'm thinking of the same one).

Also, wasn't that advisory just written by some guy?  Its not like W3C is
writing a web security standards document and made an example out of PHP or
something, its just the security suggestions/opinions of some guy.

Seems like a whole lot of trouble (breaking thousands of scripts) -- just to
appease some document by some guy.

I don't know if that's just one guy or a group of people, but that one guy 
found exploitable bugs in pretty much any big PHP app he 
researched.  Instead of ignoring his findings and saying he's just one guy, 
it's best to read the advisory and understand that he's really right about 
his assessment, that register_globals is the mother of a huge number of 
security flaws in PHP applications.

Also, about this whole car with no brakes or gun aimed at the head
business.  I like the car analogy... and the register_globals=off.

See.. turning register_globals off is like adding a huge brake, and then
hiding the accelerator.  For beginner drivers, or existing drivers that are
not up on current events, it will be very hard to get going.

That's simply not true, and it should be clear that it's not 
true.  Teaching people to use $_GET[foo] is not more difficult than 
teaching them to use $foo.  It's also more explicit and clear to read.  If 
we were in front of a blank design board right now, it wouldn't have even 
be a question.  The new method is equally clear, and has some advantages 
(the only disadvantage being a few more keystrokes, but that's not a big 
deal).  The only reason we're having this debate is due to downwards 
compatibility.

I'd say that leaving register_globals on is *exactly* like a regular car.
Its dangerous, hell yeah.  However, as long as you learn how to use it in an
enclosed environment, and practice the safety techniques -- you are not too
much of a danger to others when you get onto the highway.

Same concept applies... if you take a beginner and put them on an enterprise
server writing code that manipulates a DNS file or does updates and deletes
to a crucial database, you are asking for trouble.

Thats why people write simple, inconsequential application as they are
*learning*, and after that have some experience, they should write things
where they can actually hurt someone.

Anyway, thats my .02.  I'm done talking about this issue... its a difference
of opinion, which is generally very hard to resolve -- and no amount of
logical dicussion can change the mind of either group.

Take a look at your apps, take a close look, and see if they're vulnerable 
to such attacks.   Your apps may not be doing any 'dangerous' stuff, but 
try to see if a remote user, knowing the source code of the script, could 
cause your apps to behave differently with the right input.  From my 
experience, many, if not most of the scripts fall into this category.  If 
it's 0.1% of the population making mistakes, it's one thing.  If it's 20% 
or 50%, it means that the language is at flaw.  Even if you disagree that 
the language is at flaw and 'people should be taught how to drive more 
safely', there's no doubt that decreasing the chances of them making an 
accident very considerably is a good thing.  As I told Peter, we're not 
talking about liability here, or who's to blame.  We're trying to figure 
out the best way to convey PHP to people, and make them create good PHP 
applications.  Right now, PHP encourages them to write bad apps, which is a 
bad thing, and gives PHP bad reputation.

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

I'm definitely in favour of that, and some of the other suggestions that 
were raised.  We won't be able to make all steps at once, but whomever can 
contribute is obviously quite welcome to do so.

Zeev

At 04:15 27/07/2001, Björn Schotte wrote:
* Zeev Suraski wrote:
  equivalent to shipping cars without brakes.  You hope that the user would
  be bright enough to install brakes,

Hoping that is not enough. If you really change the
behaviour to ship PHP with register_globals to off,
then I suggest you should also ship some README_Security
or something similar where Kris writes a nice tutorial
about writing secure PHP applications. (This README_Security
should also be inserted into the Manual and all places where
it makes sense) Also, before doing make install a
less README_Security should be done by the makefile.

--
PHP Schulungen und| International PHP Conference
Schulungsmaterial:| 05. - 07.11.2001
http://thinkphp.de/  |  Astron Hotel, Frankfurt
http://rent-a-phpwizard.de/schulungen.php |  http://www.php-kongress.de/

--
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]

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


--
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 10:01 27/07/2001, Rasmus Lerdorf wrote:
  That's also not true.  Is using $foo all that better than $_GET[foo]?

For a neophyte user - most definitely.

  But it isn't.  It's by fixing an inherent design flaw in PHP.  The proposed
  target situation is *NOT* any more difficult to the users than the
  situation is today.

Of course it is.  $foo is conceptually simpler than $_GET[foo].  I don't
see how you can say it isn't.

Because it's a matter of taste, and different people see things different 
ways.  Personally I find $_GET[foo] much clearer than $foo.  It tells me, 
beyond a reasonable doubt, where this thing is coming from.  The one and 
only drawback I see for this method is that it's a few more keystrokes, but 
that's by far less important than what it gives you.  As a matter of fact, 
if I make $_GET and its friends be implicitly global, it'd actually safe 
you keystrokes in many situations, and is definitely easier than teaching 
users about the notion of the global scope, the global statement or $GLOBALS.

I *really* don't see how you can go on claiming that register_globals is 
not at fault, when we have so many examples, both practical past exploits 
and theoretical problems, directly related to it.  That, on the other hand, 
is not a matter of taste.

Zeev


-- 
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]




RE: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 04:51 27/07/2001, Marc Boeren wrote:

  Changing to register globals=off surely does very little in
  terms of security for the easily fakeable GPC variables.

Maybe not for these variables, but other variables used in your script
cannot be faked by passing them as HTTP_POST_VARS.

e.g., with register_globals=off

if ($HTTP_POST_VARS['user_string'] == 'check_for_security') {
 // do something, but be aware of security issues
 }

if ($internal_variable == 'whatever') {
 // do something, knowing that a user could never have set this
 }

The second check is where a lot of scripts are exploitable, I think, if
register_globals=on, because programmers do not expect user-input in this
variable.

*exactly*.


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Phil Driscoll

On Friday 27 July 2001 17:35, Zeev Suraski wrote:

 Have you read the advisory?  That's simply not true.

Yes, and I beleive it is true in most cases.

 There are two main types of security problems related to this:
 (a) Ones that originate in the fact that people don't know they mustn't
 trust any input coming from the user, be it GET, POST or cookies, that
 they're all insecure

So, you admit that register_globals=off for GPC variables gains us nothing, 
but will break shed loads of code?

 (b) Ones that don't, and there are many of them

 For those of type (a), register_globals being off or on doesn't change
 much.  For (b), it does, big time.

Then if you don't like my suggestion, how about a half way house - 
register-globals=GPC registers the insecure variables in the global namespace 
since we can't trust them wherever they appear in the namespace, whilst env 
variables and possibly session variables have to be read out of arrays.
I know that this would break none of my scripts, but I can't speak for other 
scripts out there.

I do feel, however, that you are really missing the point on E_NOTICE which 
IMHO has a much greater effect on the security of PHP than accessing GPC 
variables in a different way. I'd personally be even harsher than E_NOTICE is 
- if a production site generates a notice message for an uninitialised 
variable, then that's a fatal error in my book!

Cheers
-- 
Phil Driscoll


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 08:58 27/07/2001, Jason Greene wrote:
I have been watching this thread for too long and I can no longer resist 
commenting.

If a programmer does not initialize SECURE variables properly, he is going 
to make far worse
security decisions in his software. Next thing we are going to hear is 
that php does not auto TAINT check
parsed variables. I personally disagree with making register_globals=off a 
default. I really don't  think it will
make that big of a difference, and come on everyone, this is one of the 
coolest features of php.

Fact is that for many scripts (I'd argue most), this issue alone is going 
to be the one and only security issue he'd bump to.  It's all too 
common.  It's true that given other security 'decisions' he may have to 
make, he may make wrong decisions.  What's argued here is that 
register_globals=off gives a clean, harmless looking way of shooting 
yourself in the foot.

I also don't subscribe to the idea that it's one of the coolest features of 
PHP because it's a global variable.  Auto registration of form variables is 
equally cool if it's made in a secure way, instead of the security pitfall 
we have right now.

Zeev


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf

 That's also not true.  Is using $foo all that better than $_GET[foo]?

For a neophyte user - most definitely.

 But it isn't.  It's by fixing an inherent design flaw in PHP.  The proposed
 target situation is *NOT* any more difficult to the users than the
 situation is today.

Of course it is.  $foo is conceptually simpler than $_GET[foo].  I don't
see how you can say it isn't.

-Rasmus


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski

At 10:26 27/07/2001, Phil Driscoll wrote:
On Friday 27 July 2001 17:35, Zeev Suraski wrote:

  Have you read the advisory?  That's simply not true.

Yes, and I beleive it is true in most cases.

  There are two main types of security problems related to this:
  (a) Ones that originate in the fact that people don't know they mustn't
  trust any input coming from the user, be it GET, POST or cookies, that
  they're all insecure

So, you admit that register_globals=off for GPC variables gains us nothing,
but will break shed loads of code?

Of course not.  The advisory includes several references to cases that 
demonstrate the exact opposite, and it makes perfect sense that many other 
such cases exist.

  (b) Ones that don't, and there are many of them
 
  For those of type (a), register_globals being off or on doesn't change
  much.  For (b), it does, big time.

Then if you don't like my suggestion, how about a half way house -
register-globals=GPC registers the insecure variables in the global namespace
since we can't trust them wherever they appear in the namespace, whilst env
variables and possibly session variables have to be read out of arrays.
I know that this would break none of my scripts, but I can't speak for other
scripts out there.

I do feel, however, that you are really missing the point on E_NOTICE which
IMHO has a much greater effect on the security of PHP than accessing GPC
variables in a different way. I'd personally be even harsher than E_NOTICE is
- if a production site generates a notice message for an uninitialised
variable, then that's a fatal error in my book!

I think you missed the main point of the advisory.  People use global 
variables.  If people from the outside can pollute the global namespace 
using ANY method, it causes a common security pitfall.

I don't want to argue about the E_NOTICE stuff because of lack of time, and 
because IMHO, it's really very loosely related to the issue at hand.
Zeev


-- 
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]




RE: [PHP-DEV] Security Issues

2001-07-27 Thread Brian Tanner

Thanks for the cool response Zeev.. I was a little agitated when I wrote
that letter, glad you didn't take it the wrong way.

Again, my position is very simple.  I agree that what you are suggesting
would greatly reduce the exploits of the language.  Just concerned about the
cost, and if the benefit/cost ratio is in the right ballpark.  I think it
might be too much of a cost, for not enough benefit.

I personally feel that these issues up to the programmer, (hence the
difference of opinion).  This change will break many of my scripts, some of
which can take variables from Get, Post, or Cookies.  I'm not looking
forward to writing the logic to *fix* all of these, when my scripts are
secure as it stands now.

You asked if I examined my scripts, could they be caused to behave
differently if someone knew the source?

Differently - sometimes
Dangerously - Never

And my apps are not exactly hit counters either.  I'm actually working on a
very large project that I'm going to tell you all about one day soon, when
its done ;)

-Brian T

-Original Message-
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: July 27, 2001 10:06 AM
To: Brian Tanner
Cc: [EMAIL PROTECTED]
Subject: RE: [PHP-DEV] Security Issues


At 10:19 27/07/2001, Brian Tanner wrote:
Is all of this springing from that security advisory that was published a
short while ago?

I remember reading that, and feeling that many of the issues were overblown
(if I'm thinking of the same one).

Also, wasn't that advisory just written by some guy?  Its not like W3C is
writing a web security standards document and made an example out of PHP or
something, its just the security suggestions/opinions of some guy.

Seems like a whole lot of trouble (breaking thousands of scripts) -- just
to
appease some document by some guy.

I don't know if that's just one guy or a group of people, but that one guy
found exploitable bugs in pretty much any big PHP app he
researched.  Instead of ignoring his findings and saying he's just one guy,
it's best to read the advisory and understand that he's really right about
his assessment, that register_globals is the mother of a huge number of
security flaws in PHP applications.

Also, about this whole car with no brakes or gun aimed at the head
business.  I like the car analogy... and the register_globals=off.

See.. turning register_globals off is like adding a huge brake, and then
hiding the accelerator.  For beginner drivers, or existing drivers that are
not up on current events, it will be very hard to get going.

That's simply not true, and it should be clear that it's not
true.  Teaching people to use $_GET[foo] is not more difficult than
teaching them to use $foo.  It's also more explicit and clear to read.  If
we were in front of a blank design board right now, it wouldn't have even
be a question.  The new method is equally clear, and has some advantages
(the only disadvantage being a few more keystrokes, but that's not a big
deal).  The only reason we're having this debate is due to downwards
compatibility.

I'd say that leaving register_globals on is *exactly* like a regular car.
Its dangerous, hell yeah.  However, as long as you learn how to use it in
an
enclosed environment, and practice the safety techniques -- you are not too
much of a danger to others when you get onto the highway.

Same concept applies... if you take a beginner and put them on an
enterprise
server writing code that manipulates a DNS file or does updates and deletes
to a crucial database, you are asking for trouble.

Thats why people write simple, inconsequential application as they are
*learning*, and after that have some experience, they should write things
where they can actually hurt someone.

Anyway, thats my .02.  I'm done talking about this issue... its a
difference
of opinion, which is generally very hard to resolve -- and no amount of
logical dicussion can change the mind of either group.

Take a look at your apps, take a close look, and see if they're vulnerable
to such attacks.   Your apps may not be doing any 'dangerous' stuff, but
try to see if a remote user, knowing the source code of the script, could
cause your apps to behave differently with the right input.  From my
experience, many, if not most of the scripts fall into this category.  If
it's 0.1% of the population making mistakes, it's one thing.  If it's 20%
or 50%, it means that the language is at flaw.  Even if you disagree that
the language is at flaw and 'people should be taught how to drive more
safely', there's no doubt that decreasing the chances of them making an
accident very considerably is a good thing.  As I told Peter, we're not
talking about liability here, or who's to blame.  We're trying to figure
out the best way to convey PHP to people, and make them create good PHP
applications.  Right now, PHP encourages them to write bad apps, which is a
bad thing, and gives PHP bad reputation.

Zeev



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

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf

 This is an important step, that as I said, I wanted to make for years.  I
 just argue that as protective as you are over register_globals=on, the real
 flaw is there, and this is the place it should be fixed.  Fixing the fact
 that E_NOTICE is on may also be viable, but in practice:
 - A huge number of cases where E_NOTICE's will be generated isn't related
 to security in any way, and people will be kind of pissed by it, and
 probably turn it back off

That's an issue that can be addressed.  We perhaps need better granularity
on the E_NOTICE.

 If we distribute a php.ini-recommended, we can, and probably should enable
 E_NOTICE's by default.  It's not the solution to the problem raised in the
 advisory.

The very first and primary example in the advisory would most definitely
have been caught by an E_NOTICE, so I don't see how this doesn't address
the advisory.

For reference the first example in the advisory is:

 ?php
  if ($pass = hello)
   $auth = 1;
  ...
  if ($auth == 1)
   echo some important information;
 ?

First, the guy who wrote the advisory didn't check his code, because the
above could never actually be a problem since he confuses == and = and
actually always sets $auth=1, but ignoring that and fixing his code, if
you turn on E_NOTICE this script generates:

Warning: Undefined variable: pass in foo.php on line 2

Warning: Undefined variable: auth in foo.php on line 5

And the second example is:

 ?php
  if (!($fd = fopen($filename, r))
   echo(Could not open file: $filenameBR\n);
 ?

Again, an obvious bracket mismatch so this example also doesn't run, but
running this with E_NOTICE gives:

Warning: Undefined variable: filename in foo.php on line 2
Warning: Undefined variable: filename in foo.php on line 3

Same goes for example 3 which is:

 ?php
  include($libdir . /languages.php);
 ?

Then he talks about the file upload issues which is a separate problem and
one we have addressed.  And then he talks about .inc files and suggests
that people who just use .php for include files are vulnerable because
their scripts could be run out of context.  This is a different issue as
well.

   But that's not the point. The point is that people who don't care about
   security or coding style (beginners or professionals, doesn't really
   matter) are less likely to write insecure code, because there's one
   mistake less that they can make. As long as they stick to the defaults,
   anyway.
 
 And one language less that these people are able to use.

 That's an empty statement, Rasmus...  The auto-registered form variables
 are not any less usable if we change the access method to them
 slightly.  I'd argue it actually makes the code much more readable and
 newbie-friendly, actually.

Why are new users latching onto PHP instead of Perl:CGI?  PHP is not an
inherently better scripting language.  In fact it is probably
significantly weaker.  People use PHP because they find it easy to
understand and easy to learn and because it is targeted to the Web
problem.

We have a responsibility to help people write more secure scripts, but we
also cannot keep adding complexity to the point where we lose what makes
PHP what it is.  And we need to explore all the options we have here
instead of jumping to conclusions.

-Rasmus


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread

In article [EMAIL PROTECTED], 
Rasmus Lerdorf wrote:

 But that's not the point. The point is that people who don't care about
 security or coding style (beginners or professionals, doesn't really
 matter) are less likely to write insecure code, because there's one
 mistake less that they can make. As long as they stick to the defaults,
 anyway.

And one language less that these people are able to use.

I do not think that the current php users would drop the language. Maybe it
would prevent certain users to start working with it.

I'm sure that some good faqs on security issues would prevent a lot of harm.
Not only with issues on uninitialized vars (which I tend to forget too) but
problems like default passwords in a new installed application, using 
extentions for libs that could are handled as plain text, etc...

I think that settings like 'allow_url_fopen' is causing much more issues
then people can imagine. A short visit to Google will bring you to a lot
of sites that are exploitable.

Regards,

Hans
-- 
 http://phpreview.nl.linux.org


-- 
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]




Re: [PHP-DEV] Security Issues

2001-07-27 Thread Brian Foddy

Zeev Suraski wrote:
 Because it's a matter of taste, and different people see things different
 ways.  Personally I find $_GET[foo] much clearer than $foo.  It tells me,
 beyond a reasonable doubt, where this thing is coming from.  The one and
 only drawback I see for this method is that it's a few more keystrokes, but
 that's by far less important than what it gives you.  As a matter of fact,
 if I make $_GET and its friends be implicitly global, it'd actually safe
 you keystrokes in many situations, and is definitely easier than teaching
 users about the notion of the global scope, the global statement or $GLOBALS.
 

If I can just interject once, I was a bit skeptical of this thread at
first
but I'm starting to come around to Zeev's point of view.  Security aside
(which I know it shouldn't be) I found in my own coding I always started
naming post or get variables like
$form_user_name or $post_user_name so I could easily tell just by 
looking at individual sections of the code that this variable was web 
input, vs my own internal variable.  But even still, it can be confusing
to newbes trying to understand just how did this variable get its
value?.
Having the $_GET[
post_user_name] is much more straight forward.

But is there a $_POST call also?  Making a important distinction between
data posted or getted input?  If so, that may be a small inconvienence.

Good debate tho, and well timed for other issues I'm dealing with.

Brian

-- 
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]




RE: [PHP-DEV] Security Issues

2001-07-27 Thread Brian Tanner

Brian Foddy actually brings up a really important issue, which would go
along way to making (at least me) much happier with the proposed change.

*If* there will be:

$_Get[]
$_Post[]
$_Cookie[]

-- can we also have something else to the tune of:

$_External or $_User or $_Something

That gets populated based on the ordering set for GPC right now in the .ini
file?  I think it would go really far towards helping a newbie (and to
helping people fix their existing code), if there was one place that they
could look, to find the old value that they are now missing.

People can still go to _Get, _Post, and _Cookie if they require that level
of granularity, but I think most will be happy with a general container for
what Register_Globals *would* have done.

-Brian T

-Original Message-

If I can just interject once, I was a bit skeptical of this thread at
first
but I'm starting to come around to Zeev's point of view.  Security aside
(which I know it shouldn't be) I found in my own coding I always started
naming post or get variables like
$form_user_name or $post_user_name so I could easily tell just by
looking at individual sections of the code that this variable was web
input, vs my own internal variable.  But even still, it can be confusing
to newbes trying to understand just how did this variable get its
value?.
Having the $_GET[
post_user_name] is much more straight forward.

But is there a $_POST call also?  Making a important distinction between
data posted or getted input?  If so, that may be a small inconvienence.

Good debate tho, and well timed for other issues I'm dealing with.

Brian


-- 
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]




  1   2   >