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
On Wednesday, July 25, 2001, at 11:31 PM, Sebastian Bergmann wrote:
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
On Wednesday, July 25, 2001, at 06:32 PM, Zeev Suraski wrote:
Guys, look back at the advisory. Apps written by *GOOD* PHP
coders who *ARE* aware of security issues were prone to
register_globals=on attacks.
telnetd on almost all of *BSD is a big hole right now.
Good coders make mistakes.
At 15:07 25/07/2001 -0700, PHP wrote:
On Wed, Jul 25, 2001 at 07:31:59AM -0700, 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
Zeev Suraski [EMAIL PROTECTED] wrote in message
5.1.0.14.2.20010725181631.0690eff8@localhost">news:5.1.0.14.2.20010725181631.0690eff8@localhost...
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
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
At 21:14 25/07/2001, Rasmus Lerdorf wrote:
But you don't acknowledge here that turning on E_NOTICE by default would
effectively eliminate this coding mistake.
No, because it won't. As I said, you can cleanly implement this with
empty(), and there'd be no E_NOTICE's or anything.
The change I
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
Would it be a good idea to declare which parameters are allowed from
outside, and which are internal to the application?
If you set
if ($user_string=='input' $internal_allowed=='true') {
...
}
anybody can spoof $internal_allowed.
However, if you must set this script up like this:
accept_parameters($user_string); // or something similar
If PHP is going to break a bunch of scripts, they would probably just shut
register_globals off.
This would require people to do:
$user_string=$HTTP_POST_VARS[user_string];
This accomplishes the same thing as your example, and doesn't
backwards compatibility
At 15:07 7/25/2001, Andy wrote the following:
--
If register_globals = off is highly recommended,
why does the default php.ini have
register_globals=on
Many people do not change this.
[EMAIL PROTECTED]
On Wednesday 25 July 2001 15:31, Rasmus Lerdorf wrote:
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
For the obvious reason that this is a huge incompatibility change, which
would break pretty much every application out there.
I discussed this with Kristian Koehntopp in LinuxTag, and he believes, and
I tend to agree with him, that this issue is responsible for too many
problems in PHP, that
I write all of my code with/for E_ALL as well. Plus, I consider
not relying on register_globals = on to be a crucial requirement
WRT portability.
At 17:04 7/25/2001, Phil Driscoll wrote the following:
--
On Wednesday 25 July 2001
hi,
If register_globals = off is highly recommended,
why does the default php.ini have
register_globals=on
Many people do not change this.
this wouldnt realy help at all,
if you change this,
and you need those vars in a script, most people would do the same
like register_globals does.
the
I disagree here. I believe that PHP, the way it is today, encourages
people to write insecure code, even when they try to write secure
code. This is essentially what the article was saying, and I agree with
it. register_globals set to off won't solve the problem completely, and
definitely
I'm gonna have to go ahead and agree with Peter. As a relative Newbie to
PHP (1 year), I can tell you that when I switched from Perl to PHP, one of
the biggest Wow, this is great features was the easy variable access. It
makes it fast for a newbie to hack something together that works -- which
On Tue, Jul 24, 2001 at 08:27:21PM -0700, Zeev Suraski wrote:
Setting register_globals to off (which is highly recommended) would prevent
PHP from defining form variables as global variables. For quite a while,
since the PHP 3.0 times, PHP provided an alternative way of accessing
On Wed, Jul 25, 2001 at 07:31:59AM -0700, 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
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
Guys, look back at the advisory. Apps written by *GOOD* PHP coders who
*ARE* aware of security issues were prone to register_globals=on attacks.
As the guy said in the advisory, it's arguable whether it's the language's
responsibility to guide you to write a secure app, or whether it's the
No obscure %$!@*% variables was one of our main design goals in PHP, only $
for denoting variables. This one is here to stay :)
At 14:58 25/07/2001, PHP wrote:
On Tue, Jul 24, 2001 at 08:27:21PM -0700, Zeev Suraski wrote:
Setting register_globals to off (which is highly recommended) would
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
Hey all,
I am new to this list so if this topic has already been beaten to death let me
know.
I assume that many of you have already read this article
http://lwn.net/2001/0704/a/study-in-scarlet.php3
Setting register_globals to off (which is highly recommended) would prevent
PHP from defining form variables as global variables. For quite a while,
since the PHP 3.0 times, PHP provided an alternative way of accessing
variables - using special designated arrays - $HTTP_POST_VARS,
101 - 125 of 125 matches
Mail list logo
