Won't this topic just die? :)
register_globals is not insecure, users are insecure. Yes, you
can write insecure code with it on or off, and secure code with
it on or off. By users I mean people who write code, and people
who use it (the evil users are the ones that use the website,
and pass alo
I'm a bit of a neophyte with php, and I've read through lots of prior
posts and the php.net online docs, but some of this is still not
registering in my head. TIA for your patience.
I've got a script I include at the head of each of my scripts that
checks $_POST['username'] and $_POST['password
> On 08-Jun-2003 Philip Olson wrote:
> > [snip]
> >>
> >>
> >> register_globals=off won't make good code any better --it's just
> >> a safety net for the sloppy coders.
> > [snip]
> >
> > In some sense, register_globals = off makes both bad and
> > good code better, because it means less pollut
On 08-Jun-2003 Philip Olson wrote:
> [snip]
>>
>>
>> register_globals=off won't make good code any better --it's just
>> a safety net for the sloppy coders.
> [snip]
>
> In some sense, register_globals = off makes both bad and
> good code better, because it means less pollution. So
> many un
[snip]
>
>
> register_globals=off won't make good code any better --it's just
> a safety net for the sloppy coders.
[snip]
In some sense, register_globals = off makes both bad and
good code better, because it means less pollution. So
many unused variables get defined with register_globals
on
On 04-Jun-2003 Jason Wong wrote:
> In case 1, a malicious person can bypass your password checks by passing
> admin=1 in the URL.
>
>> As Rasmus has correctly pointed out, the usage of "register_globals=off"
>> per se cannot be considered a security measure. If you don't initialize
>> and/or ch
On Wed, 2003-06-04 at 10:43, Rouvas Stathis wrote:
> Armand Turpel wrote:
> >
> > > On Wed, 4 Jun 2003, Jay Blanchard wrote:
> > > > [snip]
> > > > Have register globals set to ON is one way of leaving your script open
> > > > to being exploitable.
> > > > [/snip]
> > > >
> > > > Please explain th
This is pretty straight forward. First, you really should
know where your data comes from, only you know that:
If it comes from GET, use $_GET
If it comes from POST,use $_POST
If it comes from COOKIE, use $_COOKIE
If it comes from SERVER, use $_SERVER
If it comes from ENV,
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 4:13 PM
To: [EMAIL PROTECTED] Php. Net
Subject: RE: [PHP] Re: Using register_globals
On this topic, could anyone point me to a good tutorial on how to
convert from sloppy code that assumes register_globals is on to good,
secure code that assumes
On this topic, could anyone point me to a good tutorial on how to
convert from sloppy code that assumes register_globals is on to good,
secure code that assumes register_globals is off.
something that covers what to look for and what to change it to would be
a great help.
I've been learning by wo
You guys should consider reading this:
http://www.php.net/manual/en/security.registerglobals.php
Most likely it's been updated since anyone here
read it, it covers everything discussed in this
thread.
Regards,
Philip
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit:
>> But how you know, if you have a few tausends of php code lines, which
part
>> have some sloppy code. Nobody is perfect. In my opinion you should turn
>> register_globals to off if it's possible. It's much more secure.
>Rouvas Stathis wrote:
>I strongly disagree with that.
>Consider the followi
On Thu, 5 Jun 2003 02:10:32 +0800, Jason Wong wrote:
>In case 1, a malicious person can bypass your password checks by passing
>admin=1 in the URL.
Actually, I set up a very similar user security system by taking
advantage of the $PHP_AUTH_USER variable.
I would check to see if the variable w
On Thursday 05 June 2003 01:43, Rouvas Stathis wrote:
> I strongly disagree with that.
> Consider the following code (assuming $foo is 'external' variable):
>
> 1: if ($foo=='yes') transfer_money_to_me();
>
> 2: if ($_GET['foo']=='yes']) transfer_money_to_me();
>
> Why (2) is safer than (1)? Answe
I agree that you can write secure scripts with register_globals set to ON.
I usually think that alot of rookie PHP programmers (I just started PHP a
year ago, myself) read the list, and the way I figure is that it is good to
make readers of the list aware of the issues of register globals.
Plus,
Armand Turpel wrote:
>
> > On Wed, 4 Jun 2003, Jay Blanchard wrote:
> > > [snip]
> > > Have register globals set to ON is one way of leaving your script open
> > > to being exploitable.
> > > [/snip]
> > >
> > > Please explain this, how does it make it more exploitable? I think that
> > > this is
[snip]
> In the corporate environment with multiple developers we have to
> initialize every variable (it's a rule). We even scan code once a day
> for variables that have not been declared. It's part of our
> documentation.
Jay, is your "scan" something other than setting error reporting to
E_
> -Original Message-
> From: Jay Blanchard [mailto:[EMAIL PROTECTED]
> In the corporate environment with multiple developers we have to
> initialize every variable (it's a rule). We even scan code once a day
> for variables that have not been declared. It's part of our
> documentation.
J
[snip]
The only reason there to initialize $explodenuke would be for security
(register_globals), and there are other cases like this. I generally
initialize variables before using them, but there's always going to be a
time when someone forgets. That shouldn't present a security hazard,
whic
True, it's not incredibly annoying in all cases. It is in some cases,
however. For instance,
if(user_is_authorized){
$explodenuke = 1;
}
...
if(!empty($explodenuke)){
//Explode a nuke!
}
The only reason there to initialize $explodenuke would be for security
(register_globals), and there are ot
> On Wed, 4 Jun 2003, Jay Blanchard wrote:
> > [snip]
> > Have register globals set to ON is one way of leaving your script open
> > to being exploitable.
> > [/snip]
> >
> > Please explain this, how does it make it more exploitable? I think that
> > this is only true if the code is sloppy.
>
> Cor
On Wed, 4 Jun 2003, Jay Blanchard wrote:
> [snip]
> On Wed, 4 Jun 2003, Jay Blanchard wrote:
> > [snip]
> > Have register globals set to ON is one way of leaving your script open
>
> > to being exploitable. [/snip]
> >
> > Please explain this, how does it make it more exploitable? I think
> > that
On Wed, 4 Jun 2003, Leif K-Brooks wrote:
> It's true that register_globals being on only makes sloppy code more
> insecure. Most people aren't going to write perfect code, though. It's
> incredibly annoying to have to unset every variable that shouldn't be
> from an outside source. Even if you d
[snip]
On Wed, 4 Jun 2003, Jay Blanchard wrote:
> [snip]
> Have register globals set to ON is one way of leaving your script open
> to being exploitable. [/snip]
>
> Please explain this, how does it make it more exploitable? I think
> that this is only true if the code is sloppy.
Correct, if you
On Wed, 4 Jun 2003, Jay Blanchard wrote:
> [snip]
> Have register globals set to ON is one way of leaving your script open
> to being exploitable.
> [/snip]
>
> Please explain this, how does it make it more exploitable? I think that
> this is only true if the code is sloppy.
Correct, if you proper
It's true that register_globals being on only makes sloppy code more
insecure. Most people aren't going to write perfect code, though. It's
incredibly annoying to have to unset every variable that shouldn't be
from an outside source. Even if you do so, it's very likely that you
will forget o
[snip]
Have register globals set to ON is one way of leaving your script open
to being exploitable.
[/snip]
Please explain this, how does it make it more exploitable? I think that
this is only true if the code is sloppy.
Thanks!
Jay
--
PHP General Mailing List (http://www.php.net/)
To unsubscrib
27 matches
Mail list logo
