PHP Security

[john tindell]

Hey does anyone know any method of making a PHP site secure. I mean though coding it and not the server setup. I have read up this topic on php.net and i was wondering if anyone here had discovered good methods of adding security to their site.

I ask this because a forum my friend set up, phpBB i think, someone used a crack or something to gain view all the users passwords. I want to be able to stop this happening though my own coding.

Thanks

[CornedBee]

It's always a combination of server settings (or rather, php.ini settings) and coding.

First, disable register_globals.
Next, get rid of all evals. Not that eval itself is very evil (pun NOT intended), but it's rarely necessary and poses a security risk if some user input sneaks into the eval'ed string.
Next, be sure to check every bit of user input very carefully. Where does it go, what's done with it? Letting user input into SQL queries for example is asking for trouble. Writing it out as it is is too, that's the "sneak JavaScript into a page and fool users to reveal details" trick that was used against some online banking site.
User input always comes through the variables $_GET, $_POST, $_COOKIES and sometimes $_REQUEST. Then there's $_FILES where uploaded files are stored and another thing which stores the input in a PUT request.

Hmm, that's all I can think of for now. Others might add things.

[Electroman]

What if you dont have the ability to turn register_globals off :(. I haven't ask my host to yet but I would expect them not to considering how many other users are on the same server.

[CornedBee]

Then unset every global variable you're going to use before using it.
unset($config);
$config = ...

[Electroman]

Originally posted by CornedBee
Then unset every global variable you're going to use before using it.
unset($config);
$config = ... Ow well I always initialise the variables before I use them anyway;), treat it a bit like C++:D. What was that about eval anyway?

As for for letting user input be used in SQL satements isn't it safe to use the AddSlashes() function before putting it in? Not to mention limiting the username being used by php files to the bare minimum they need. For example php scripts will rarly need to create tables, some will only need to ever use Select & Update.

[CornedBee]

addslashes should keep you safe, but I'm not a specialist there.

eval executes the string you pass as PHP, so it's generally a VERY bad idea to give the user even the faintest chance of modifying this string.

[john tindell]

Cheers for all the feedback.


CornedBee: is there a way to check to see if global vars are set on at the beggining of the code?



Sorry stupid question :rolleyes:

print ini_get('register_globals');

[KTottE]

Actually CornedBee, any data that is in a $_GET, $_POST or $_COOKIE array will also be in the $_REQUEST-array, since $_REQUEST is just a gathering of the $_GET, $_POST and $_COOKIE arrays into one (and I think $_FILES too, more details on www.php.net)

Two valuable tips for more secure PHP coding, aside from what's already been mentioned (read on www.php.net for function specifics):

* Never trust input. If it's not defined by you, consider it to be harmful and take action to prevent the input to destroy the script.
If you're sending a variable into an SQL query, double, triple and quadrouple-check it for any harmful contents before you send it in the query.

* Always use the extension .php instead of .inc (or .tpl) when you are including files, because this will prevent people from accessing the contents of that file. If someone enters the address for an .inc-file, the webserver will print this out as plain text, very bad if you're storing sensitive information like database passwords in an included file. If they enter the address for a .php file, the file will be executed and nothing will happen.

[CornedBee]

Actually CornedBee, any data that is in a $_GET, $_POST or $_COOKIE array will also be in the $_REQUEST-array
With "sometimes" I was referring to the low frequency of $_REQUEST being used.

[KTottE]

Ah, ok :)