PHP Security Mistakes - Tips 5, 6
(Page 4 of 4 )
5. For protected areas, use sessions or validate the login every time.
There are some cases where programmers will only use some sort of login.php script to first validate their username and password (entered through a form), test if they're an administrative or valid user, and actually set a variable through a cookie, or even hide it as a hidden variable. Then in the code, they check to see if they have access like this:
if($admin)
{
// let them in
}
else
{
// kick them out
}
The above a code makes the fatal assumption that the $admin variable can only come from a cookie or input form that the malicious user has no control over. However, that is simply not the case. With register_globals enabled, injecting designed input into the $admin variable is as easy as calling the script like so:
script.php?admin=1
Furthermore, even if you use the superglobals $_COOKIE or $_POST, a malicious user can easily forge a cookie or create his own HTML form to post any information to your script.
There are two good solutions to this problem. One is on the same track as setting an $admin variable, but this time set $admin as a session variable. In this case, it is stored on the server and is much less likely to be forged. On subsequent calls to the same script, your user's previous session information will be available on the server, and you will be able to verify if the user is an administrator like so:
if( $_SESSION['admin'] )
The second solution is to only store their username and password in a cookie, and with every call to the script, validate the username and password and verify if the user is an administrator. You could have two functions -- one called validate_login($username,$password) that verified the user's login information, and one called is_admin($username) that queried the database to see if that username is an administrator. The code would be placed at the top of any protected script:
if( !validate_login( $_COOKIE['username'], $_COOKIE['password'] ) )
{
echo "Sorry, invalid login";
exit;
}
// the login is ok if we made it down here
if( !is_admin( $_COOKIE['username'] ) )
{
echo "Sorry, you do not have access to this section";
exit;
}
Personally I recommend using sessions, as the latter solution is not scalable.
6. If you don't want the file contents to be seen, give the file a .php extension.
It was common practice for awhile to name include files or library files with a .inc extension. Here's the problem: if a malicious user simply enter the .inc file into his browser, it will be displayed as plain text, not parsed as PHP. Even if the browser did not like the file type, an option to download it would most likely be given. Imagine if this file had your database login and password, or even more sensitive information.
This goes for any other extension other than .php (and a few others), so even a .conf or a .cfg file would not be safe.
The solution is to put a .php extension on the end of it. Since your include files or config files usually just define variables and/or functions and not really output anything, if your user were to load this, for example, into their browser:
http://yoursite.com/lib.inc.php
they would most likely be shown nothing at all, unless of your lib.inc.php outputs something. Either way, the file would be parsed as PHP instead of just displaying your code.
There are also some reports of people adding Apache directives that will deny access to .inc files; however, I do not recommend this because of the lack of portability. If you rely on .inc files and that Apache directive to deny access to them and one day you move your scripts to another server and forget to place the Apache directive in, you are wide open.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 286 
