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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
- 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
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
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:
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
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
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
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.
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
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
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
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
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
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
* 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:
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.
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
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
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
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
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
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
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
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
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/
* 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
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.
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
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
(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
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
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
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
-
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
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 =
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
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 -
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
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
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?
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
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
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
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
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'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.
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
: [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
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
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
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
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
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
On Fri, 27 Jul 2001 23:00:54 +0200, Brian Tanner [EMAIL PROTECTED]
wrote:
*If* there will be:
$_Get[]
$_Post[]
$_Cookie[]
-- can we also have something else to the tune of:
$_External or $_User or $_Something
Important point. It's stupid if we suddenly have to hard-code for
PHP wrote:
On Wed, Jul 25, 2001, Sebastian Bergmann wrote:
Andy wrote:
If register_globals = off is highly recommended, why does the
default php.ini have register_globals=on
For backward compatibility reasons. We intend to break this,
and other things, with either PHP 4.1 or PHP
1 - 100 of 123 matches
Mail list logo
