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
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
[snip]
rant
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 08-Jun-2003 Philip Olson wrote:
[snip]
rant
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
On 08-Jun-2003 Philip Olson wrote:
[snip]
rant
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
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 check *all*
If it's a preference it's a bad one. Have register globals set to ON is one
way of leaving your script open to being exploitable. I would suggest that
if you really need to use that code then either modify it or write something
from scratch and use that code as a guide line.
search php.net for
[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
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
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 properly
[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, 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 do
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 this is only
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
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
[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,
-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.
Jay,
[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_ALL?
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 only true if the code
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,
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)? Answer: It
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
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 following code
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:
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
[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
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,
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 this, how does it make it more
Ya!
I read the book and learned it from Programming PHP wroted by Rasmus ,page on
285,that said :
It's important to understand that PHP itself is
neither secure nor insecure. The security of your
web applications is entirely determined by the
code you write.
for example:
//initialize your
29 matches
Mail list logo
