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_global s on without any security issues?

Thanks

John

[Pertti Kosunen]

Re: register_global s - turning on

John wrote:[color=blue]
> I just wondered, if I am running php/mysql/apache locally, should I be
> okay to turn register_global s on without any security issues?[/color]

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

[Tim Van Wassenhove]

Re: register_global s - turning on

In article <u9i5f0tjl6hj2i mg3m6ue17qk3m56 6lc41@4ax.com>, John wrote:[color=blue]
> 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_global s on without any security issues?[/color]

Are you aware of the consequences that register_global s 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]

Re: register_global s - turning on

Pertti Kosunen wrote:[color=blue]
> John wrote:[color=green]
>> I just wondered, if I am running php/mysql/apache locally, should I be
>> okay to turn register_global s on without any security issues?[/color]
>
> It is better to learn php with globals=off from start.[/color]

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]

Re: register_global s - turning on

On 12 Jul 2004 18:20:35 GMT, A strange species called Tim Van
Wassenhove <euki@pi.be> wrote:
[color=blue]
>In article <u9i5f0tjl6hj2i mg3m6ue17qk3m56 6lc41@4ax.com>, John wrote:[color=green]
>> 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_global s on without any security issues?[/color]
>
>Are you aware of the consequences that register_global s 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.[/color]

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]

Re: register_global s - turning on

On Mon, 12 Jul 2004 21:15:04 +0100, John wrote:
[color=blue]
> 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[/color]

You can simulate "register_globa ls = 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 | jeffrey@pantsjh u.edu **
Website | http://www.newtnotes.com

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

[Tim Van Wassenhove]

Re: register_global s - turning on

In article <v7s5f0dsa450vf usqgf7pk7sj235k culv1@4ax.com>, John wrote:[color=blue]
> On 12 Jul 2004 18:20:35 GMT, A strange species called Tim Van
> Wassenhove <euki@pi.be> wrote:
>[color=green]
>>In article <u9i5f0tjl6hj2i mg3m6ue17qk3m56 6lc41@4ax.com>, John wrote:[color=darkred]
>>> 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_global s on without any security issues?[/color]
>>
>>Are you aware of the consequences that register_global s 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.[/color]
>
> Where do you recommend I start reading? Any good sources?[/color]

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[color=blue]
> most hosts had it switched on, but I guess it is better to learn right
> from the start all the potential issues.[/color]

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

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

[John]

Re: register_global s - turning on

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_global s 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_global s 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_global s 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_global s 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_global s 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_global s off
php_value session.save_pa th /home/user/siteroot/sess/users
php_value session.gc_maxl ifetime 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]

Re: register_global s - turning on

>I've RTFM at:[color=blue]
>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_global s 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_global s switched "ON" by
>default because of the history of PHP.[/color]

I hope that isn't true, and it should be becoming less true as
time goes on.
[color=blue]
>From what I have read I get a little confused. I need to turn "ON"
>register_globa ls otherwise I can't finish off my login pages and use
>sessions in PHP.[/color]

I recommend that you write PHP code for non-obsolete versions of
PHP.
[color=blue]
>
>However, the advice in one of the posts in the manual at php.net, says
>to make sure register_global s is OFF to 'avoid session problems'. It
>also recommend to create a .htaccess file in the document root that
>contains the following settings:[/color]
[color=blue]
>1. Set register_global s 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[/color]

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).
[color=blue]
>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_global s off[/color]

Turns register_global s off. Duh!
[color=blue]
>php_value session.save_pa th /home/user/siteroot/sess/users[/color]

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.
[color=blue]
>php_value session.gc_maxl ifetime xxx[/color]

How long to save data for sessions that go stale.
"gc" stands for "garbage collection" (of sessions).
[color=blue]
>php_value include_path .:/home/user/siteroot.com/sess[/color]

Where to look for stuff included with "include".
[color=blue]
>php_value auto_prepend /home/user/siteroot.com/sess/path_file.php[/color]

Stick this file on the beginning of every PHP page processed. (an
"automatic include"). It can, among other things, start up your
sessions.
[color=blue]
>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.[/color]

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.
[color=blue]
>
>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 :)[/color]

Can I have a sample of Naquadria?

Gordon L. Burditt

[John]

Re: register_global s - turning on

On 14 Jul 2004 05:42:57 GMT, A strange species called
gordonb.qoifh@b urditt.org (Gordon Burditt) wrote:
[color=blue][color=green]
>>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_global s 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_global s switched "ON" by
>>default because of the history of PHP.[/color]
>
>I hope that isn't true, and it should be becoming less true as
>time goes on.
>[color=green]
>>From what I have read I get a little confused. I need to turn "ON"
>>register_glob als otherwise I can't finish off my login pages and use
>>sessions in PHP.[/color]
>
>I recommend that you write PHP code for non-obsolete versions of
>PHP.
>[color=green]
>>
>>However, the advice in one of the posts in the manual at php.net, says
>>to make sure register_global s is OFF to 'avoid session problems'. It
>>also recommend to create a .htaccess file in the document root that
>>contains the following settings:[/color]
>[color=green]
>>1. Set register_global s 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[/color]
>
>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).
>[color=green]
>>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_global s off[/color]
>
>Turns register_global s off. Duh!
>[color=green]
>>php_value session.save_pa th /home/user/siteroot/sess/users[/color]
>
>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.[/color]

So basically using the .htaccess is a safe way of enabling sessions to
work, without having to turn on resgister_globa ls.
[color=blue][color=green]
>>php_value session.gc_maxl ifetime xxx[/color]
>
>How long to save data for sessions that go stale.
>"gc" stands for "garbage collection" (of sessions).
>[color=green]
>>php_value include_path .:/home/user/siteroot.com/sess[/color]
>
>Where to look for stuff included with "include".
>[color=green]
>>php_value auto_prepend /home/user/siteroot.com/sess/path_file.php[/color]
>
>Stick this file on the beginning of every PHP page processed. (an
>"automatic include"). It can, among other things, start up your
>sessions.[/color]

Do I stick that at the start of every single page or just the ones
requiring users to be logged in to access?
[color=blue][color=green]
>>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.[/color]
>
>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.[/color]

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

[color=blue][color=green]
>>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 :)[/color]
>
>Can I have a sample of Naquadria?[/color]

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]

Re: register_global s - turning on

>>>Firstly, I'm not too sure what exactly a .htaccess file is? Is it[color=blue][color=green]
>>
>>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).
>>[color=darkred]
>>>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_global s off[/color]
>>
>>Turns register_global s off. Duh!
>>[color=darkred]
>>>php_value session.save_pa th /home/user/siteroot/sess/users[/color]
>>
>>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.[/color]
>
>So basically using the .htaccess is a safe way of enabling sessions to
>work, without having to turn on resgister_globa ls.[/color]

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_global s.
Session files can be put in an insecure place WITH register_global s.
It's a separate issue.
[color=blue][color=green][color=darkred]
>>>php_value session.gc_maxl ifetime xxx[/color]
>>
>>How long to save data for sessions that go stale.
>>"gc" stands for "garbage collection" (of sessions).
>>[color=darkred]
>>>php_value include_path .:/home/user/siteroot.com/sess[/color]
>>
>>Where to look for stuff included with "include".
>>[color=darkred]
>>>php_value auto_prepend /home/user/siteroot.com/sess/path_file.php[/color]
>>
>>Stick this file on the beginning of every PHP page processed. (an
>>"automatic include"). It can, among other things, start up your
>>sessions.[/color]
>
>Do I stick that at the start of every single page or just the ones
>requiring users to be logged in to access?[/color]

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.

[color=blue][color=green][color=darkred]
>>>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.[/color]
>>
>>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.[/color]
>
>This include path. Is this just where you would put all the .inc
>files that contain the username, password and db connection info etc?[/color]

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.

[color=blue][color=green][color=darkred]
>>>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 :)[/color]
>>
>>Can I have a sample of Naquadria?[/color]
>
>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.[/color]

Gordon L. Burditt