Re:- Settings related to php.ini

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
pistolfire99
Forum Commoner
Posts: 58
Joined: Thu May 23, 2002 3:18 pm

Re:- Settings related to php.ini

Post by pistolfire99 »

Hey guys/gals,
I am having problems with my php code. I am sure the code is ok, since its straight out from the book. Hence the culprit is my php.ini file. Here is a working demonstration of what errors I am receiving.
Please click here

http://www.i2l2.com/BegPHP/ch04/

click on any .html files and put diff values and on clicking submit, it will take you to the .php page and it has lots of errors in it.
This is getting to my nerves since I can't seen to figure out the problem. I believe its the php.ini under C:\windows (Win XP Pro). The two places where I made any changes to the php.ini file are:-
I turned this option to Off

Code: Select all

register_globals = Off
and I turned this option to 0 from 1

Code: Select all

cgi.force_redirect = 0
If anyone know how to get around my problems then please provide any suggestions. I have already tried using the default settings and it still is giving me a pain.

Thank You in advance :)
User avatar
fatal
Forum Contributor
Posts: 118
Joined: Sat Apr 20, 2002 10:47 am
Location: East Coast

Post by fatal »

Notice: Undefined variable: Question1 in C:\Xitami\webpages\BegPHP\ch04\quiz.php on line 5

Notice: Undefined variable: Question1 in C:\Xitami\webpages\BegPHP\ch04\quiz.php on line 6
Those are the error that i got from the php files, the only solution i can think of is delcaring the varibles at the begining of the script.
pistolfire99
Forum Commoner
Posts: 58
Joined: Thu May 23, 2002 3:18 pm

Post by pistolfire99 »

Yup, thats the same error I am getting too. I downloaded this code for my book from the authors website, Beginning PHP4 from wrox publications. The code is unmodified and unaltered. Its supposed to work out of box. I have also tried the solution that you were mentioning and it still didnt fix things for me:- try this link out...

http://www.i2l2.com/quiz.html
User avatar
mikeq
Forum Regular
Posts: 512
Joined: Fri May 03, 2002 3:33 am
Location: Edinburgh, Scotland

Post by mikeq »

I take it you guys have looked at the messages with the cant post stuff.

i.e. all the bits about $_POST etc

Mike
pistolfire99
Forum Commoner
Posts: 58
Joined: Thu May 23, 2002 3:18 pm

Post by pistolfire99 »

Hey mikeq, would you be kind enough to shed some light into $_POST. I am unaware about the same. I have already installed and uninstalled php and xitami 10 times. Still cant figure it out, now Im trying apache out.
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

I have the same book and all the code worked once I turned global variables on. If your running IIS you don't have to worry about force cgi-redirect. One thing though, when you changed the php.ini file did you restart the server? And if you did, is the php.ini file in the right place? It needs to be in your windows system directory otherwise php will default to the default settings. That should help ya. Copy php.ini to C:\windows, and then restart iis or reboot.

Here are some other settings...

doc_root = F:\Inetpub\wwwroot
or whatever your drive is, yours is probably C:

; **You CAN safely turn this off for IIS, in fact, you MUST.**
; cgi.force_redirect = 1

Notice that it's still commented so it doesn't matter what the setting is..

extension=php_gd.dll
Uncomment that exstension for graphic files in the book

; You should do your best to write your scripts so that they do not require
; register_globals to be on; Using form variables as globals can easily lead
; to possible security problems, if the code is not very well thought of.
register_globals = On

; This directive tells PHP whether to declare the argv&argc variables (that
; would contain the GET information). If you don't use these variables, you
; should turn it off for increased performance.
register_argc_argv = On

That should do it...
Last edited by Benjamin on Fri May 24, 2002 7:36 am, edited 1 time in total.
User avatar
twigletmac
Her Royal Site Adminness
Posts: 5371
Joined: Tue Apr 23, 2002 2:21 am
Location: Essex, UK

Post by twigletmac »

Information about $_POST and all the other predefined variables is available here:
http://www.php.net/manual/en/reserved.variables.php

Like mikeq said there are a lot of posts on this board dealing with the same problem so do a search on $_POST.

Turning register_globals on will solve the problem but then you'll be writing much less secure code (which is why it's off by default). Learning how to use $_POST, $_GET, $_COOKIE etc. is a much better way to go.

Mac
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

Code: Select all

register_globals = Off
That is your problem, turn them on and restart the server.
User avatar
twigletmac
Her Royal Site Adminness
Posts: 5371
Joined: Tue Apr 23, 2002 2:21 am
Location: Essex, UK

Post by twigletmac »

From this on the PHP.net web site:
http://www.php.net/release_4_1_0.php
php.net wrote: For various reasons, PHP setups which rely on register_globals being on (i.e., on form, server and environment variables becoming a part of the global namespace, automatically) are very often exploitable to various degrees. For example, the piece of code:

Code: Select all

<?php
if (authenticate_user()) {
  $authenticated = true;
}
...
?>
May be exploitable, as remote users can simply pass on 'authenticated' as a form variable, and then even if authenticate_user() returns false, $authenticated will actually be set to true. While this looks like a simple example, in reality, quite a few PHP applications ended up being exploitable by things related to this misfeature.

While it is quite possible to write secure code in PHP, we felt that the fact that PHP makes it too easy to write insecure code was bad, and we've decided to attempt a far-reaching change, and deprecate register_globals. Obviously, because the vast majority of the PHP code in the world relies on the existence of this feature, we have no plans to actually remove it from PHP anytime in the foreseeable future, but we've decided to encourage people to shut it off whenever possible.
Honestly, learning how to adjust the code to deal with register_globals being turned off will be more useful in the long run when you come to write your own code and want it to be secure.

Oh and from another answer in a post about the same problem:
http://www.webmasterbase.com/article.php?pid=0&aid=758

Mac
jason
Site Admin
Posts: 1767
Joined: Thu Apr 18, 2002 3:14 pm
Location: Montreal, CA
Contact:

Post by jason »

Code: Select all

register_globals = off
This does not add security, and will not make your programs more secure. Oh, granted, at first glance, it looks like it might, but it doesn't.

When you get right down to it, there is a better way to make sure you are writing clean code:

Code: Select all

error_reporting(E_ALL);
I find that to be a better way to handle undefined and potentially problematic variables.

PHP was designed to be a loosely typed language, and to allow for certain freedoms. Since the inception of the $_GET and $_POST arrays, I have used them extensively, but that doesn't mean I want register_globals off.

Time and time again, people have told me "But Jason, using $_GET['file'] is more secure thatn $file" and time and time again, I tell them "unlink($_GET['file']); is still just as insecure as unlink($file);"
User avatar
twigletmac
Her Royal Site Adminness
Posts: 5371
Joined: Tue Apr 23, 2002 2:21 am
Location: Essex, UK

Post by twigletmac »

Using the $_POST is more secure than just referencing a variable by it's name once it's sent from a form because you can't spoof the script by putting the variable in a query string in the address bar. Having register_globals off means that code will be less exploitable (it won't make it entirely secure - that's down to the skills of the individual coder) than with it on.

It's also not just about code security, register_globals has been deprecated which means that one day it will not be there any more, granted that won't be any time soon but surely learning how to work without relying on it is the best way to make sure that you won't have to rewrite masses of code when it goes?

Writing clean code and writing secure code aren't the same thing - $_POST, $_COOKIE etc are incredibly useful in ensuring that data is coming from where you expect it - error reporting is about ensuring that you haven't mistyped a variable name or aren't trying to access an element in an array that doesn't exist (aside from obvious things like spotting parse errors etc. of course).

Seriously, if having register_globals off adds nothing to PHP then why have the guys behind it bothered? It would have been a lot easier to just leave it the way it was. Maybe they just thought the ensuing problems would be amusing.

Mac
User avatar
volka
DevNet Evangelist
Posts: 8391
Joined: Tue May 07, 2002 9:48 am
Location: Berlin, ger

Post by volka »

and time and time again, I tell them "unlink($_GET['file']); is still just as insecure as unlink($file);"
it is, but one may have hope in "unlink($_GE.....hmmmm, did I double-check and confirm it?" ;)
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

As far as secure code goes, In my opinion it's not the language you use, or the settings you use, it's the ability to have the foresight to understand how your code could be "hacked", and modify it accordingly.
Post Reply