register_globals - turning on

[John]

Hello.

I am a newbie to PHP. I am over halfway through my first book that
I'm learning with and have just created login pages etc.

I just wondered, if I am running php/mysql/apache locally, should I be
okay to turn register_globals on without any security issues?

Thanks

John

[Pertti Kosunen]

John wrote:

I just wondered, if I am running php/mysql/apache locally, should I be
okay to turn register_globals on without any security issues?

It is better to learn php with globals=off from start.

[Tim Van Wassenhove]

In article <u9********************************@4ax.com>, John wrote:

Hello.

I am a newbie to PHP. I am over halfway through my first book that
I'm learning with and have just created login pages etc.

I just wondered, if I am running php/mysql/apache locally, should I be
okay to turn register_globals on without any security issues?

Are you aware of the consequences that register_globals on/off have?

As you say that you are a newbie, i think you're better of learning it
right from the start. No need to learn depreciated stuff.
--
Tim Van Wassenhove <http://home.mysth.be/~timvw>

[Pedro Graca]

Pertti Kosunen wrote:

John wrote:

I just wondered, if I am running php/mysql/apache locally, should I be
okay to turn register_globals on without any security issues?

It is better to learn php with globals=off from start.

Even better with error_reporting(E_ALL).

--
USENET would be a better place if everybody read: | to email me: use |
http://www.catb.org/~esr/faqs/smart-questions.html | my name in "To:" |
http://www.netmeister.org/news/learn2quote2.html | header, textonly |
http://www.expita.com/nomime.html | no attachments. |

[John]

On 12 Jul 2004 18:20:35 GMT, A strange species called Tim Van
Wassenhove <eu**@pi.be> wrote:

In article <u9********************************@4ax.com>, John wrote:

Hello.

I am a newbie to PHP. I am over halfway through my first book that
I'm learning with and have just created login pages etc.

I just wondered, if I am running php/mysql/apache locally, should I be
okay to turn register_globals on without any security issues?

Are you aware of the consequences that register_globals on/off have?

As you say that you are a newbie, i think you're better of learning it
right from the start. No need to learn depreciated stuff.

Where do you recommend I start reading? Any good sources? I thought
most hosts had it switched on, but I guess it is better to learn right
from the start all the potential issues.

Cheers

John

[Jeffrey Silverman]

On Mon, 12 Jul 2004 21:15:04 +0100, John wrote:

Where do you recommend I start reading? Any good sources? I thought most
hosts had it switched on, but I guess it is better to learn right from the
start all the potential issues.

Cheers

John

You can simulate "register_globals = on" with the following code at the
top of any PHP script (assuming PHP Version >= 4.1.something):

<?
foreach ($_REQUEST as $k => $v){
$$k = $v;
}
?>
But it may be better to just get in the habit of using the $_* arrays to
access variables.

later...
--
Jeffrey D. Silverman | je*****@pantsjhu.edu **
Website | http://www.newtnotes.com

(** Drop "pants" to reply by email)

[Tim Van Wassenhove]

In article <v7********************************@4ax.com>, John wrote:

On 12 Jul 2004 18:20:35 GMT, A strange species called Tim Van
Wassenhove <eu**@pi.be> wrote:

In article <u9********************************@4ax.com>, John wrote:

Hello.

I am a newbie to PHP. I am over halfway through my first book that
I'm learning with and have just created login pages etc.

I just wondered, if I am running php/mysql/apache locally, should I be
okay to turn register_globals on without any security issues?
Are you aware of the consequences that register_globals on/off have?

As you say that you are a newbie, i think you're better of learning it
right from the start. No need to learn depreciated stuff.

Where do you recommend I start reading? Any good sources?

http://www.php.net/manual
This question has been asked many times before, so i'm pretty sure you
can find what others have to say about this too.

I thought most hosts had it switched on, but I guess it is better to learn right
from the start all the potential issues.

You could do a little search in this newsgroup on "register_globals" and
discover how many times people have had problems with it.

--
Tim Van Wassenhove <http://home.mysth.be/~timvw>

[John]

Hello.

I've RTFM at:
http://de2.php.net/manual/en/security.globals.php

I'm a bit confused though and need a little clarification.

I'm running locally and register_globals is off because it isn't
enabled anymore in new versions of PHP because of potential security
issues, though I understand that the security issues are mainly
programmers not being aware of this and using code that could be
exploited.

As I understand it most hosts have register_globals switched "ON" by
default because of the history of PHP.

From what I have read I get a little confused. I need to turn "ON"
register_globals otherwise I can't finish off my login pages and use
sessions in PHP.

However, the advice in one of the posts in the manual at php.net, says
to make sure register_globals is OFF to 'avoid session problems'. It
also recommend to create a .htaccess file in the document root that
contains the following settings:

1. Set register_globals to off.
2. Load your fixed include paths.
3. Relocate your session file storage folder away from the default
'/tmp'

Firstly, I'm not too sure what exactly a .htaccess file is? Is it
just like an include file that each page references and loads the
settings from?

It suggests the following for the .htaccess file:

php_flag register_globals off
php_value session.save_path /home/user/siteroot/sess/users
php_value session.gc_maxlifetime xxx
php_value include_path .:/home/user/siteroot.com/sess
php_value auto_prepend /home/user/siteroot.com/sess/path_file.php

I'm not too sure on what all the above does, except for the first
line, so if you could break it down for me I'd be very grateful. The
paths are a tad confusing as well. I'm not too sure how that would
relate when I'm running locally, or if I'm with a host? I wouldn't
know what if anything the paths would need changing to.

John

PS. If anyone watches the series Stargate SG-1 I am very much like the
character O'Neil played by Richard Dean Anderson ex MacGyver fame. In
the series he always gets lost with the technical scientific terms and
needs things explaining more simply :)

[Gordon Burditt]

>I've RTFM at:

http://de2.php.net/manual/en/security.globals.php

I'm a bit confused though and need a little clarification.

I'm running locally and register_globals is off because it isn't
enabled anymore in new versions of PHP because of potential security
issues, though I understand that the security issues are mainly
programmers not being aware of this and using code that could be
exploited.

As I understand it most hosts have register_globals switched "ON" by
default because of the history of PHP.
I hope that isn't true, and it should be becoming less true as
time goes on.
From what I have read I get a little confused. I need to turn "ON"
register_globals otherwise I can't finish off my login pages and use
sessions in PHP.
I recommend that you write PHP code for non-obsolete versions of
PHP.

However, the advice in one of the posts in the manual at php.net, says
to make sure register_globals is OFF to 'avoid session problems'. It
also recommend to create a .htaccess file in the document root that
contains the following settings: 1. Set register_globals to off.
2. Load your fixed include paths.
3. Relocate your session file storage folder away from the default
'/tmp'

Firstly, I'm not too sure what exactly a .htaccess file is? Is it
A .htaccess file is an Apache configuration file. *IF* you are
allowed to use one, you may put it in your web directory and it
affects all subdirectories under that directory, unless overridden
by a .htaccess file in a subdirectory. One thing a .htaccess file
can do is set per-directory options for PHP when it is run as
an Apache module (using it as a module is the standard setup).
just like an include file that each page references and loads the
settings from?

It suggests the following for the .htaccess file:

php_flag register_globals off
Turns register_globals off. Duh!
php_value session.save_path /home/user/siteroot/sess/users
Sessions contain persistent data, and you have to have
some place to save this data. This specifies where.
/tmp is not a particularly secure place for it, especially
if you share the server with other people. The web server
user needs to be able to read and write files here.
php_value session.gc_maxlifetime xxx
How long to save data for sessions that go stale.
"gc" stands for "garbage collection" (of sessions).
php_value include_path .:/home/user/siteroot.com/sess
Where to look for stuff included with "include".
php_value auto_prepend /home/user/siteroot.com/sess/path_file.php
Stick this file on the beginning of every PHP page processed. (an
"automatic include"). It can, among other things, start up your
sessions.
I'm not too sure on what all the above does, except for the first
line, so if you could break it down for me I'd be very grateful. The
paths are a tad confusing as well. I'm not too sure how that would
relate when I'm running locally, or if I'm with a host? I wouldn't
know what if anything the paths would need changing to.
The paths need to EXIST and point to disk space you can control.
In the case of session data, the web server needs to be able
to read and write files there. In the case of the include directory,
the web server needs to be able to read files there, and you
probably shouldn't let anyone else write on them.

John

PS. If anyone watches the series Stargate SG-1 I am very much like the
character O'Neil played by Richard Dean Anderson ex MacGyver fame. In
the series he always gets lost with the technical scientific terms and
needs things explaining more simply :)

Can I have a sample of Naquadria?

Gordon L. Burditt

[John]

On 14 Jul 2004 05:42:57 GMT, A strange species called
go***********@burditt.org (Gordon Burditt) wrote:

I've RTFM at:
http://de2.php.net/manual/en/security.globals.php

I'm a bit confused though and need a little clarification.

I'm running locally and register_globals is off because it isn't
enabled anymore in new versions of PHP because of potential security
issues, though I understand that the security issues are mainly
programmers not being aware of this and using code that could be
exploited.

As I understand it most hosts have register_globals switched "ON" by
default because of the history of PHP.

I hope that isn't true, and it should be becoming less true as
time goes on.

From what I have read I get a little confused. I need to turn "ON"
register_globals otherwise I can't finish off my login pages and use
sessions in PHP.

I recommend that you write PHP code for non-obsolete versions of
PHP.

However, the advice in one of the posts in the manual at php.net, says
to make sure register_globals is OFF to 'avoid session problems'. It
also recommend to create a .htaccess file in the document root that
contains the following settings:

1. Set register_globals to off.
2. Load your fixed include paths.
3. Relocate your session file storage folder away from the default
'/tmp'

Firstly, I'm not too sure what exactly a .htaccess file is? Is it

A .htaccess file is an Apache configuration file. *IF* you are
allowed to use one, you may put it in your web directory and it
affects all subdirectories under that directory, unless overridden
by a .htaccess file in a subdirectory. One thing a .htaccess file
can do is set per-directory options for PHP when it is run as
an Apache module (using it as a module is the standard setup).

just like an include file that each page references and loads the
settings from?

It suggests the following for the .htaccess file:

php_flag register_globals off

Turns register_globals off. Duh!

php_value session.save_path /home/user/siteroot/sess/users

Sessions contain persistent data, and you have to have
some place to save this data. This specifies where.
/tmp is not a particularly secure place for it, especially
if you share the server with other people. The web server
user needs to be able to read and write files here.

So basically using the .htaccess is a safe way of enabling sessions to
work, without having to turn on resgister_globals.

php_value session.gc_maxlifetime xxx

How long to save data for sessions that go stale.
"gc" stands for "garbage collection" (of sessions).

php_value include_path .:/home/user/siteroot.com/sess

Where to look for stuff included with "include".

php_value auto_prepend /home/user/siteroot.com/sess/path_file.php

Stick this file on the beginning of every PHP page processed. (an
"automatic include"). It can, among other things, start up your
sessions.

Do I stick that at the start of every single page or just the ones
requiring users to be logged in to access?

I'm not too sure on what all the above does, except for the first
line, so if you could break it down for me I'd be very grateful. The
paths are a tad confusing as well. I'm not too sure how that would
relate when I'm running locally, or if I'm with a host? I wouldn't
know what if anything the paths would need changing to.

The paths need to EXIST and point to disk space you can control.
In the case of session data, the web server needs to be able
to read and write files there. In the case of the include directory,
the web server needs to be able to read files there, and you
probably shouldn't let anyone else write on them.

This include path. Is this just where you would put all the .inc
files that contain the username, password and db connection info etc?

John

PS. If anyone watches the series Stargate SG-1 I am very much like the
character O'Neil played by Richard Dean Anderson ex MacGyver fame. In
the series he always gets lost with the technical scientific terms and
needs things explaining more simply :)

Can I have a sample of Naquadria?

I don't think they've discovered any on this planet yet, though a lot
of the stuff we have is just as bad. You can probably get some red
mercury in a can of Coke if you visit one of the ex-Soviet countries.
I heard they sell them for less than the original product it
contained.

Cheers for your help

John

[Gordon Burditt]

>>>Firstly, I'm not too sure what exactly a .htaccess file is? Is it

A .htaccess file is an Apache configuration file. *IF* you are
allowed to use one, you may put it in your web directory and it
affects all subdirectories under that directory, unless overridden
by a .htaccess file in a subdirectory. One thing a .htaccess file
can do is set per-directory options for PHP when it is run as
an Apache module (using it as a module is the standard setup).

just like an include file that each page references and loads the
settings from?

It suggests the following for the .htaccess file:

php_flag register_globals off

Turns register_globals off. Duh!

php_value session.save_path /home/user/siteroot/sess/users

Sessions contain persistent data, and you have to have
some place to save this data. This specifies where.
/tmp is not a particularly secure place for it, especially
if you share the server with other people. The web server
user needs to be able to read and write files here.

So basically using the .htaccess is a safe way of enabling sessions to
work, without having to turn on resgister_globals.

No, the above .htaccess directive is a way of enabling sessions to
work without having to put an ini_set() call at the beginning of
each and every page to force the session save files to be put
into a safe place. Sessions work fine without register_globals.
Session files can be put in an insecure place WITH register_globals.
It's a separate issue.

php_value session.gc_maxlifetime xxx

How long to save data for sessions that go stale.
"gc" stands for "garbage collection" (of sessions).

php_value include_path .:/home/user/siteroot.com/sess

Where to look for stuff included with "include".

php_value auto_prepend /home/user/siteroot.com/sess/path_file.php

Stick this file on the beginning of every PHP page processed. (an
"automatic include"). It can, among other things, start up your
sessions.

Do I stick that at the start of every single page or just the ones
requiring users to be logged in to access?

No, you put that in the .htaccess file at the top of the tree
you want to have it affect. An alternative is to put
an
include('/home/user/siteroot.com/sess/path_file.php');
at the beginning of each and every php page (or perhaps, each and
every php page where it's actually needed). This is a lot of work.

I'm not too sure on what all the above does, except for the first
line, so if you could break it down for me I'd be very grateful. The
paths are a tad confusing as well. I'm not too sure how that would
relate when I'm running locally, or if I'm with a host? I wouldn't
know what if anything the paths would need changing to.

The paths need to EXIST and point to disk space you can control.
In the case of session data, the web server needs to be able
to read and write files there. In the case of the include directory,
the web server needs to be able to read files there, and you
probably shouldn't let anyone else write on them.

This include path. Is this just where you would put all the .inc
files that contain the username, password and db connection info etc?

Yes. And possibly files that contain common functions and classes
also. Anything included by include or require might go here.
Whether you put it here or in the same directory as what included it
is a matter of style, and how many things need to include it.

Generally I prefer to put database passwords & such in an include
file OUTSIDE the document tree. If PHP is working, it will be used
and not show it. If PHP is NOT working (I've managed to break it
briefly while upgrading Apache or PHP), it's outside the document
tree so Apache won't show it as text while it doesn't recognize the
..php or .inc extension. Either way, your db password won't get
leaked. This technique does NOT, however, protect you against other
users of the same server.

PS. If anyone watches the series Stargate SG-1 I am very much like the
character O'Neil played by Richard Dean Anderson ex MacGyver fame. In
the series he always gets lost with the technical scientific terms and
needs things explaining more simply :)

Can I have a sample of Naquadria?

I don't think they've discovered any on this planet yet, though a lot
of the stuff we have is just as bad. You can probably get some red
mercury in a can of Coke if you visit one of the ex-Soviet countries.
I heard they sell them for less than the original product it
contained.

Gordon L. Burditt