Advice on PHP settings for all you technomaniacs
Moderator: General Moderators
Advice on PHP settings for all you technomaniacs
What type of settings on your version of PHP would affect something like passowrd controls?
Imagine the scenario, you want to code your system to allow sessions so users can log in and log out, users have different types, i.e admin, guest and restrictions on the activities they do.
When you try and code this people say "oh by the way make sure you have etc etc switched on and etc etc switched off"
My question is what are these "etcs' what settinggs would people be referring to?
Also do you think that in certain environments these settings would have a legitimate reason to be switched off and unavailable say if you were using a server not controlled by you.
Any information would be welcome. Im gathering this data from a range of sources so your technical input would be invaluble.
Thanks
Imagine the scenario, you want to code your system to allow sessions so users can log in and log out, users have different types, i.e admin, guest and restrictions on the activities they do.
When you try and code this people say "oh by the way make sure you have etc etc switched on and etc etc switched off"
My question is what are these "etcs' what settinggs would people be referring to?
Also do you think that in certain environments these settings would have a legitimate reason to be switched off and unavailable say if you were using a server not controlled by you.
Any information would be welcome. Im gathering this data from a range of sources so your technical input would be invaluble.
Thanks
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
I think he is talking about the PHP setting in the ini file. I think.
If that is the case, some of the ones more commonly mentioned around here are:
I know there are more that we talk about, but these are the ones, off the top of my head, that get the most airtime.
If that is the case, some of the ones more commonly mentioned around here are:
Code: Select all
register_globals = Off
display_errors = Off
short_tags = Off
asp_style_tags = Off- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
Yes, many organization would turn these settings to off if they are not defaulted to off. Mostly becaase of Security. Some of these can be overridden by using ini_set(), but in most cases, you want these settings off.mohson wrote:Yep Everah thats exactly what im talking about, now to the second part of my question would certain organisations turn things like the ones you mentioned off for security or other reasons?
And if they did would it be possible to work around this, i.e. as feyed has mentioned?
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
register_globals is easy to deal with: write your script such that it doesn't require them to be on by using the superglobals -- $_GET, $_POST, $_FILES, $_COOKIE, $_SESSION, $_SERVER, etc..
display_errors: this can often be controlled from an .htaccess file, or by using set_error_handler() to create your own handlers for errors.
short_tags: always always use "<?php" instead of "<?". Same goes for "<?php echo" as opposed to "<?=".
asp_style_tags: same as short tags, as far as anyone should be concerned.
display_errors: this can often be controlled from an .htaccess file, or by using set_error_handler() to create your own handlers for errors.
short_tags: always always use "<?php" instead of "<?". Same goes for "<?php echo" as opposed to "<?=".
asp_style_tags: same as short tags, as far as anyone should be concerned.
So therefore I could argue that I cannot create an administration section using sessions because this would require settings in the ini file to be altered and as a result this could breach the organisations security.
This doesnt prevent the system from having security as the organisation has its own password control which can password protect directories.
Still is mine a valid argument?
This doesnt prevent the system from having security as the organisation has its own password control which can password protect directories.
Still is mine a valid argument?
Also, to avoid register_globals exploitation, always define your variables.
is open to exploitation via register_globals, if the user enters: http://www.example.com/page.php?loggedin=foo
Code: Select all
<?php
if ($user->isLoggedIn()) {
$loggedin = true;
}
if (isset($loggedin)) {
$view->display('membersarea');
}
?>- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
No you could not argue that. There are session settings in the php.ini file, but there is nothing preventing you from using native PHP sessions to create an administration section. There is also nothing preventing you from creating a databases managed session application to handle administration.mohson wrote:So therefore I could argue that I cannot create an administration section using sessions because this would require settings in the ini file to be altered and as a result this could breach the organisations security.
This doesnt prevent the system from having security as the organisation has its own password control which can password protect directories.
Still is mine a valid argument?
The settings we have discussed in this thread would not prevent you from using sessions at all.
No. You can create an Administration section with all of those settings switched off, using sessions or otherwise.mohson wrote:So therefore I could argue that I cannot create an administration section using sessions because this would require settings in the ini file to be altered and as a result this could breach the organisations security.
This doesnt prevent the system from having security as the organisation has its own password control which can password protect directories.
Still is mine a valid argument?
You don't even need to put Admin only php scripts into a separate directory, as with a decent control at the beginning of the script you can grant/deny access based on your own criteria.
just to add to Jenk's example above, the correct way to do this is:
Code: Select all
<?php
$loggedin = false;
// this way, no matter what the user does with the URL, $loggedin is always reset to false
if ($user->isLoggedIn()) {
$loggedin = true;
}
if ($loggedin) {
$view->display('membersarea');
}
?>