Article Discussion: PHP Security Mistakes

The purpose of this document is to inform PHP programmers of common security mistakes that can be overlooked in PHP scripts. While many of the following concepts may appear to be common sense, they are unfortunately not always common practice. After applying the following practices to your coding, you will be able to eliminate the vast majority of security holes that plague many scripts. Many of these security holes have been found in widely-used open source and commercial PHP scripts in the past.


Read the full article here: PHP Security Mistakes

Tip 5 in the article "PHP Security Mistakes" suggests either using sessions or validating the login every time to protect functionality that requires special privileges. I've been working on a solution to this sort of problem, and I think validating the login every time is much safer. Yet at the end of this tip, the author says, "Personally I recommend using sessions, as the latter solution is not scalable."

I really don't understand what the author means when he says "the latter solution is not scalable." Clearly it's slower, but just how much slower really depends on many things. How fast is the communication path between the PHP application and the database server? How good is the database engine about caching frequently accessed data? How fast are the processors the PHP engine and the database engine are running on, and how loaded are they? Likewise for disk access times.

But if any of those are limiting factors, hardware's pretty cheap nowadays. The increased security from validating the login every time seems more than worth it to me to pay the price of a slight performance hit with every webpage. So exactly what about that solution is not scalable?

application security is not limited to programming security. To protect sebsitive information, the option is to use SSL to secure session, or even smart card (SecureId).

Another simple yet effective thing to mention: If you have a numeric-only variable coming in through a $_GET variable like 'http://foobar.com?id=1', use is_numeric() to validate before letting it run the SQL gaunlet.

That is a load of crap. RTFM



Compare that to what the author writes. He is saying that YOUR script would execute the code, that is false.

i completely agree that you should validate every page load, but not like that... you should never store the username and password in a cookie! i don't care if you hash them both first, any determined attacker can find out the original values if you do that. then they can can log in just like any regular user.

i would hope that they couldn't log in just by copying the cookie contents into their own cookie, since the username and password hopefully at the very least got hashed with the user's IP address, login time, etc.

kind of disappointing, since the author recommended some decent tips for php developers new to security up until then.

Great article. I noticed the inclusion issue at alot of sites aswell. Rather stupid indeed. I think PHP being so user friendly is its weak aswell since alot people will forget these kind of issues.

Actually, I've been thinking of doing something like that as a security measure. I'm setting up a system that people will log into, but it's not the typical e-commerce site where people create their own accounts. There will be a privileged user who creates accounts.

When the normal user wants to log in, I'm going to force the URL to "https://...". So when they enter their user id and password into a form, it travels encrypted across the SSL connection, gets decrypted by SSL at the receiving end and is delivered to my PHP script in plaintext in $_POST[] variables. At that point, I need to store the data somewhere for the next page load. I don't want to store it in $_SESSION, because that data is stored in plaintext in a file in /tmp. I've looked at installing my own session handler to encrypt the information, but I've got a chicken and the egg problem which means that that solution won't help me.

The only other option I can think of is to ship it back to the user in a session cookie. That brings up two questions:

1) I know that when the user sends data to a URL beginning with "https://..." SSL is invoked and the data traveling to the server is encrypted before it's sent. But what happens when the server sends its reply back? Can I count on the server's reply, including the cookies my PHP script sends, also being encrypted when on the wire?

2) After the cookies get across the wire and back to the user's browser, I don't want them written out to disk. I've been hoping if I specify the cookies' lifetime as being the current session, that the browser will maintain them in its memory and not store them on disk. But it seems like this could vary from one browser to another. Does anyone know if my assumption is valid for some or all browsers, and if so for which browsers? I know that any part of the browser's memory could get written out to swap space, and if someone had a high enough level of access to the user's system and was determined enough, they could prowl through the swap space looking for unencrypted passwords. But that's really beyond my control. At the moment, I'm just concerned about whether cookies with a session lifetime are ever written to files in the filesystem, or if I can count on them residing exclusively in memory allocated to the process running the browser.

I see that my hosting company has register_globals = ON. I am going to send them a link to this article and see about them turning if OFF. But I wonder how this could affect php coding on all other sites on the same server?

Is there a way for me to individually set register_globals = OFF on each page of my site, in case they say they don't want to turn register_globals off?

the server's reply should get encrypted, yes. if you want to test that, just sniff the socket on your own machine while testing.


many browsers write the cookies to disk pretty much as soon as they get them, at least in my experience. even if they only keep it in memory and don't write to disk, the data will still exist in the memory for someone to nab (think shared computer, someone has a hack to snag data from ram). when dealing with sessions and cookies, always assume that anyone will have access to the unencrypted values making up the cookie.

i'd recommend reading the open web application security project's guide to building secure web applications (specifically, chaper 7, managing user sessions). it doesn't have all the answers, but it works for a good start.

It's not a load of crap, if the author of the original script is either braindead or doesn't actually care/know anything about basic security measures. Maybe you should RTFM first.

If the script.php script contains a simple include of the page var provided in the URL without any sanity checks (as mentioned in the article), you can quite easily have it include your own PHP code. The only thing you have to do is have the remote (malicious) script echo the PHP code you want to execute on the target server. Since you echo it, the result of the include is your PHP source, which then gets included (and executed) on the target server. So, the author is right, you are wrong.

Hi,

I've created a php web application that requires user login. After validating his UserID & PWD thru the MySQL db, I also create the session and store one the var as:
$_SESSION["usedID"]


The problem is that if I log in to one browser and than close the borwser(without clicking the logout button) and open a new browser, I will still be logged in. So the browser dosen't starts a new session, but continues with the old one. Eventhough, every page in my application checks for that session variable: if( $_SESSION['userID'] )

Can u help me with this?

thanks
-digi_d

what you said about .inc files is important, but not the only solution. on my servers I take several precautions.

1) the .inc files are sent through the php parser so if someone did happen to get a url to one, it would still get parsed and probably spit out an error message.

2) nobody will ever be able to hit a .inc file on my sites via a url. all of my .inc files get stored in directories that are either outside the document root or are in .htaccess protected directories. PHP includes them through the file system, they are never accessed via http protocols so as long as they are protected there is not an issue.

- keith