Top 7 PHP Security Blunders

[Quoc Bao]

ni_set() happens a long time after register_globals has done its evil deed. The best way to turn off register_globals in a shared environment is to use "php_value register_globals 0" in your .htaccess.

Ops , this only works when you are using PHP installed as Apache module ;)

[Robert]

On my shared hosting site, if I add this line to the .htaccess file in the top-level directory, it will turn off register_globals:

php_flag register_globals off

Running phpinfo() shows it is ideed off locally:

<?php phpinfo(); ?>

Any comments, potential issues, security holes doing it this way?

[cmuench]

That is a good solution but if someone has access to your .htaccess then your screwed. But if they have access to you .htaccess then they probably have access to your files to.

[dyer85]

@Robert - using .htaccess to modify PHP config is contingent upon PHP being installed as an Apache module. If it's installed as a CGI (not uncommon), that won't work.

[Danny]

what about allow_url_fopen = OFF this prevents many scriptkiddies from abusing poorly written scripts.

:)

[David van Enckevort]

I think your site covers some of the basic mistakes made in php development. However I believe there is a better way to protect against SQL injections than the way you described. You should have a look at the prepared statements in SQL. These are great to protect against SQL injections, since you prepare the statement before you bind parameter data. This way illicit data can never change the SQL statement.

[mkoenig]

Nice 1.

PHP Rocks... but its so easy to screw up. lol

[wonshikee]

A user who creates a new session by logging in should be assigned a fresh session ID using the session_regenerate_id function. A hijacking user will try to set his session ID prior to login; this can be prevented if you regenerate the ID at login.

Why not hijack it after they log in, I don't fully understand the benefit of session_regenerate_id, is it just a way to mitigate some hijacks if the id is compromised prior to user logging in?

[minidak03]

Nice article, I've done a lot of PHP security in the past and it seems like its a never ending battle I've recently got something called Firewall Script which protects against all types of PHP attacks.

I can easily program in all my own security but eventually a software solution is the way to go such a time saver.

I think sitepoint should do a review on it, here is the link http://www.amplegains.com/firewall-software.php

[muzammal786]

Nice article. It is helpful and interesting to read

[Hammer65]

I agree, this article is downright dangerous. This makes our job in the forums, that much harder. addslashes and magic_quotes should NEVER be recommended. They should only be mentioned as being insecure. Any time I see this sort of code published anywhere, I don't hesitate to raise some hell about it. I hate to see this kind of misinformation associated with Sitepoint.

"SQL Insertion". I don't want to be anal about it but we should be holding ourselves to a higher standard especially on a well respected site such as SitePoint ("To whom much is given, much will be required"). Is it really that hard to make a few changes to the article?
-Aaron

I agree, although it's more commonly called SQL injection. Something about having the words Insertion and anal in the same paragraph makes me a little nervous.

[Curtis]

You shouldn't use addslashes to escape your MySQL statements, use mysql_real_escape_string or prepared statements, available in the mysqli extension and PDO.

[Darrell]

This cannot be overstressed or said too many times. I will therefore say it again.

DO NOT USE addslashes().

USE mysql_real_escape_string().

[Colnector]

Regarding register_globals on shared hosting - you don't have to "get a new host!"...

Just modify the .htacess file on your main web folder with the following:
<FilesMatch "\.(php|html?)$">
php_flag register_globals off
</FilesMatch>

(and other PHP related options can be set as well)

[Tim Nicholson]

This is a GREAT article. Thanks for posting it.

One thing that might scare new PHP programmers from even attempting to address things is the preg_match function. It can be very confusing. In the calendar example where you want to ensure numeric values (not strings) for the month and year, a new programmer would be safe in just using inval(). eg $month = intval($_REQUEST['month']);

Then they could use some simple if, then, else logic that they are probably more familiar with to ensure the valid ranges for the month (and year if they want), but even if they don't they've still protected themselves.

So simply using intval() and htmlspecialchars() as you mentioned are easy ways for beginning PHP programmers to provide some protection from many of the issues addressed in the article.

[Allan]

Good overview, thanks. However rather than relying solely on input validation to avoid SQL injection, use mysqli (not mysql) which has support for prepared statements. The code is slightly longer, but easily wrapped in a function.
See the manual for a good example.
Cheers, al.

[Martin]

The article mentions that you can have your own error handling function sending you an e-mail whenever PHP encounters an error. This is a very handy way to get notices about errors. This must however be done with some precaution to prevent malicious attackers from being able to block your organization's e-mail servers, by issuing erroneous PHP-calls to your website!

[logic_earth]

...e-mail whenever PHP encounters an error. This is a very handy way to get notices about errors. This must however be done with some precaution to prevent malicious attackers from being able to block your organization's e-mail servers, by issuing erroneous PHP-calls to your website!

Users should not be able to get PHP to issue internal PHP errors. Sending application error (i.e. failed validation of user input) is not sent to email. Only actual errors from PHP itself.