There are some steps you can take later on to protect your applications from this unknown input. But first, let’s take a look at why you can never trust a user’s input and just how easy it is for someone to spoof a form.

What Does It Mean to Spoof a Form?

It could mean a number of related things, but generally speaking it means submitting form information in a manner other than the original form was intended. The form processing script, completely unaware of the situation, processes the input as if it came from the original form.

For example, if a form generates a URL query string, one way to spoof that form would be to modify the query string and re-visit the URL. The new page would think that my query came from the original form – even though I really crafted the query myself.

Why would someone want to do this? It may be curiosity. “I wonder what happens if I change this variable…” Or it may be malicious. A hacker can spoof a form processing script to send dangerous input to your PHP script.

The Problem With the “Get” Method

It is easiest to spoof a form if the information is transmitted through the “Get” method. This means that the variables are placed into a query string and appended to the form’s action URL.

Let’s say you have a form with three elements – a textarea element, a hidden input, and a select element. Logically, you might think that the hidden input is restricted to whatever value you set it to and the select element is restricted to one of the options you provided.

To make this a little more concrete, let’s assume the textarea contains a post to a multi-user blog, the hidden input contains the author’s name, and the select element includes the category number.

When the user enters the values and clicks “submit,” he’s sent to a URL that looks something like this.

processing.php?text=Bla+bla+bla&author=Walkere&catid=2

What if I wanted to pretend to be someone else – like Bob? I could simply change the ‘author’ variable.

processing.php?text=Bla+bla+bla&author=Bob&catid=2

Maybe I want to post my message in a special category – one that isn’t normally open to me. Again, it’s as simple as changing the catid variable to another number.

Now, a well designed script will notice these data flukes and either ignore them or spit out an error. However, if you have too much faith in form input – and you blindly used the values from your form – you’d soon be in a mess of trouble.

But Post Is More Secure… Right?

The “Post” method is somewhat more secure. Why? Because all of the information is transmitted behind the scenes.

When I was younger, I tried to meddle with the $_GET variables of an online game that I played. I never would have known enough about the workings of the script to spoof a “post” form – but it was so blatantly obvious with “get.”

However, someone “in the know” can easily spoof a form using the post method as well. One way to do this is… write your own form.

If I look at the HTML source of your form, I can easily see what values you’re submitting to the processing script. I can recreate those input elements on a form on my site – and then set the action to your processing script.

In this way, I could make the hidden and select statements regular text inputs – and input whatever values I want. If you’re form processing script isn’t savvy, my custom values will get passed on to the database.

One thing you can do to prevent this is to check the referring URL coming into your script. This will prevent someone from simply creating a form off-site to spoof your script.

Sending an Actual HTTP Request

The final, and most devious way, to spoof a form is to craft your own HTTP request in PHP. This is essentially what a form does – but you can manually craft the request to your liking instead of letting a form do it.

How do we do this?

First, we create a stream context. To do that we create a simple array and then call the function stream_context_create.

$params = array();
$params['http']['method'] = 'post';
$params['http']['headers'] = 'Referer: http://www.google.com';
$params['http']['content'] = $data; // A regular query string with parameters
 
$context = stream_context_create($params);
 
$fp = fopen($processingUrl, 'r', false, $context);
fpassthru($fp);
fclose($fp);

The actual form values are placed in the $data variable. This is in a typical query string format – key=var&key2=var2, etc. The values should also be url encoded.

The nifty thing here is that you can manually specify HTTP headers to be sent with your request. In this example, we set the referring URL to Google. If someone knew your processing script checked the referrer’s address – they could simply spoof it with an HTTP header.

Never Trust Input

The bottom line is – never trust input that you haven’t thoroughly tested, validated, and cleaned.

Even if an input item is supposed to be hidden or supposed to come from a specific set of values – you can’t be sure that the form processing script is going to receive the correct value. The script needs to check the info and make sure that it got what it was looking for.

It’s pretty simple for someone to spoof your form and send any input they like to your processing script. If you don’t close the security holes, then someone will eventually blow them open for you.

The simple solution I suggested involved a foreach loop that cycled through the $_POST array and sent every value along in a hidden input element. After a bit of reflection (and some useful comments), I realized there’s a teeny tiny security hole in that approach – so I’ve slightly modified it to close the loophole.

The Multi-Page Form Snippet

The old snippet of code looked like this…

foreach ($_POST as $key => $val) {
  echo '<input type="hidden" name="' . $key . 
    '" value="' . $val . '" />' . "\r\n";
}

The Security Loophole

What’s the problem? If someone enters a quote into the form, it could break all of the hidden elements. Here’s an example.

Let’s say I type this into a text input.

" /><input type="text" name="newField" value="newValue

The next page would create this…

<input type="hidden" name="firstField" value="" />
<input type="text" name="newField" value="newValue" />

By adding a quote, you prematurely end the first hidden element and can add new html tags. You can combine this with javascript for some potentially nasty effects. I guess. I’m really not sure what you could do with this… but it’s better to be safe than sorry, eh?

How to Fix the Multi-Page Form Snippet

We can close this loophole once and for all with a simple function call – htmlentities. With the proper parameter, this will encode all html entity characters (including quotes), so that the user can’t input a quote or create new HTML tags.

foreach ($_POST as $key => $val) {
  echo '<input type="hidden" name="' . $key . '" value="' 
    . htmlentities($val, ENT_QUOTES) . '" />' . "\r\n";
}

No more problems.

It’s also important to note that this problem isn’t just a security loophole. By not validating the input before creating the hidden element, you could accidentally break the form for a legitimate user. If the user enters a ” inside a text field, it would break the hidden element on the next page.

Why Not Use Sessions or a Database?

Some people have suggested using sessions or a database to accomplish the same thing. That’s certainly possible, but I feel this is a better design choice.

I like to keep the php and html as separate as possible. This allows us to keep all of the input inside of the form until we’re ready to process it. Meanwhile, our processing script sees all of the input as coming from a single form – even if it came from different pages.

By contrast, you need to break up your processing script to use databases. You also need to mix and match $_POST and $_SESSION to use sessions to store the information. It’s functional, but doesn’t seem elegant to me.

With that in mind, this is something of a preference. It’s not better than the other methods – but I think it is semantically more logical. So use what you prefer.

An oft-asked question – and oft-misunderstood – is what is the difference? Is one better than the other?

First, let’s take a quick look at how each one works.

How MD5 Works

MD5 creates a “hash” value based on an input string. It uses a one-way algorithm to turn the password into an unintelligible garble of words. Here’s a sample usage.

echo md5("Bananas");

Output:
1ee31b77d0697c36914b99d1428f7f32

This long string (32 characters) is the md5 hash value of “Bananas.” You can now store it in the database, and when a user wants to log in you compare md5($passwordInput) to this hash value.

Using Crypt to Encrypt a Password

Crypt has very similar functionality, but with a unique twist.

Crypt still encrypts a phrase in a one-way algorithm to create a garbled bunch of characters. Here’s an example…

echo crypt("Bananas");

Output:
$1$upPJosTV$HC4n2bUsQFZk2IDN1CLdg.

What’s unique about the crypt() function is that it uses an encryption key (or “salt”) to vary the encryption process. This means that you can encrypt the same password (“Bananas”) multiple times and get different hash values to store in your database.

Do I Have to Store the Encryption Key or Salt?

This is where the crypt() function gets a bit confusing. No, you don’t… because the encryption key is stored in the password itself.

Take another look at this output.

$1$upPJosTV$HC4n2bUsQFZk2IDN1CLdg.

The bold bit of text ($1$upPJosTV$) is the stored salt or encryption key (read how to use crypt() for more information on how this salt is created).

So, no. You don’t have to store the salt anywhere, because it’s stored in the hash’ed text. You can simply use that as the salt in the future to check if the password is correct. Like this…

if (crypt($passwordInput, $hashedPassword) == $hashedPassword) {
  //  Ok, log in and stuff.  }

Wait… My Encryption Key Is Stored IN the Password?!?

This is where most people think that crypt() is a waste of time. If the great thing about crypt() is that it uses a customizable encryption key, then isn’t it self-defeating to include the encryption key in the stored password?

Not entirely.

The problem with md5() is that everyone knows the encryption algorithm. Sure, you can’t go backwards… but you can easily build a dictionary of known passwords and known hashes. By storing these in a database, it is feasible to do a simple dictionary check to see if you have a password that goes with a known hash.

Why You Should Use Crypt() Instead

Since each crypt() call can use a unique encryption key, there can be no stored dictionary of password hashes.

Here’s an example. Try running this script to see how different salts or encryption keys can change the output of a crypt() call.

echo crypt("Bananas", 'ab') . '<br />';
echo crypt("Bananas", 'ed') . '<br />';
echo crypt("Bananas", 'pz') . '<br />';
echo crypt("Bananas", 'qp') . '<br />';

Output:
abBGdAR.aTnBE
edHaZeqWhmLpw
pzqz3tbQxuuRI
qp/4Jsj38Cq0Y

This illustrates the strength of crypt(). By using a different encryption key, the same password (“Bananas”) can be turned into many different hashes. You can’t simply create a lookup table with known passwords and known hashes – because the hash changes based on the encryption key.

The bottom line is that crypt() doesn’t make your passwords unbreakable or protect them from brute force attacks. If someone wants to take the time to check every possible permutation of characters to get to your password, they can do it.

But crypt() does prevent the use of a password dictionary that contains known passwords and known hashes. This would be a far more efficient way to hack a password than a simple brute force attack. So by using crypt() you’re getting an extra layer of security.

[Note: This article assumes you are using an md5 hash as the salt for crypt(). You could use an extended DES salt or a Blowfish salt for slightly different functionality, but these are not supported on all servers - including mine.]

Some systems generate these initially and have the user log in to set a permanent password. You might also have a “Reset” button, where the script generates a random password and e-mails it to the user.

This quick tutorial will show you how to create an 8 character random password containing a mix of letters and numbers. Or, if you’re impatient, jump straight to the function’s source code

There are plenty of ways to do this. The simplest method would be to take a random number, generate an md5 hash, and then use the first 8 characters as the password.

$password = md5( time() );
$password = substr($password, 0, 8);

But this doesn’t guarantee you an even mix of upper case letters, lower case letters, and numbers. To do that, we’ll need to use a few simple php functions and build a short script.

Build a Loop to Create Eight Characters

We’ll start our script by creating a blank string, looping eight times, and entering a character in the string each time.

$password = '';
for ($x = 0; $x < 8; $x++) {
   $password .= 'a';
}

This creates a blank string ($password) and iterates a loop eight times. At this point, the loop simply enters the letter ‘a’ into $password – so you end output should be ‘aaaaaaaa.’

Generate Random Characters

Now we need to generate random characters to go inside of the string. To do this, we can make use of the rand() and chr() functions. Replace the loop contents with this line.

$password = chr( rand(60, 95) );

chr() takes an integer and returns the ASCII equivalent of that number. In this case, we’re using rand() to get a number between 60 and 95 – so we should get an uppercase letter in return. Our random password should now contain eight random upper-case letters.

Randomly Enter Uppercase, Lowercase, and Numbers

To make the random password more secure, we should randomize whether the new character is a number, an upper-case letter, or a lower-case letter. We can execute a simple “switch” statement to randomly choose which type of character to enter.

Replace the loop contents with this new snippet.

switch ( rand(1, 3) ) {
 
   //  Add a random digit, 0-9
   case 1:
   $password .= rand(0, 9);
   break;
 
   //  Add a random upper-case letter
   case 2:
   $password .= chr( rand(65, 90) );
   break;
 
   //  Add a random lower-case letter
   case 3:
   $password  .= chr( rand(97, 122) );
   break;
}

We’re using rand(1, 3) to randomly choose which case to execute. Each case then enters a different type of character in the string. The first case simply returns a random digit. The second and third cases use chr() and rand() to return a random character.

At this point, the script should give you an eight-character password with a random mix of uppercase letters, lowercase letters, and numbers. Now you can e-mail the password to the user, take a hash of the password, and store it in the database.

For reference, here’s the entire script placed in a function.

function randPassword() {
   $password = '';
 
   for ($x = 1; $x <= 8; $x++) {
      switch ( rand(1, 3) ) {
 
      //  Add a random digit, 0-9
      case 1:
      $password .= rand(0, 9);
      break;
 
      //  Add a random upper-case letter
      case 2:
      $password .= chr( rand(65, 90) );
      break;
 
      //  Add a random lower-case letter
      case 3:
      $password  .= chr( rand(97, 122) );
      break;
      }
   }
 
   return $password;
}

There are a bunch of ways you could create and check passwords – from an insecure string in a database to an encrypted “hash” that you check against user input. This tutorial will show you how to use the crypt() function to store and check passwords in a php script.

What Does the Crypt() Function Do?

The crypt() function takes two parameters – the first parameter is the actual input (the password to test) and the second parameter is a “salt” or encryption key that is used to encrypt the password phrase.

Let’s take a look at what the crypt() function does with some input.

echo crypt("Gobble", "xt");

Would yield the output…

xt0iPj3UKFQSM

The function used the encryption key “xt” to turn “Gobble” into an encrypted mess. Now, a person looking through the database won’t be able to find out a person’s password. They’ll only find the encrypted password – which won’t work if you enter it into a script.

The Crypt() Function Stores the Encryption Key in the Output

There’s an important pattern here, though, that we can see if we look at a couple of crypt() calls in a row.

echo crypt("Gobble", "ab");
echo crypt("Gobble", "td");
echo crypt("Gobble", "pz");

Would yield the output…

ab30/okS7bRdo
tdylLlJ9zwOss
pz0u5z5fgyCK.

You can break each piece of output into two pieces – the first two characters and the last 11 characters.

The first two characters “ab,” “td,” and “pz” are the three “salts” or encryption keys that we used in our crypt() calls. The last 11 characters are the actual encrypted pass phrases.

This simple point is crucial to the functioning of crypt(). It stores the encryption key inside the encrypted phrase, so that you can use it to encrypt a new phrase – and compare them. If you use the encrypted phrase as your “salt” (the second parameter for crypt()), the function will isolate the encryption key and ignore the rest.

So this example would output “Passwords match!”

$password = "Gobble"; // User input
$salt = "ab"; // Encryption key
$encrypted = crypt($password, $salt);
if ( crypt($password, $encrypted) == 
    $encrypted) {
  echo "Passwords match!"; }

In this case we’re using the encrypted password ($encypt) to perform the encryption algorithm on the user’s input ($password) to see if they match. Normally, you would have $encrypted stored in the database to perform comparisons in your script.

Use an MD5 Hash Salt to Encrypt Phrases Over 8 Characters

The final thing to keep in mind about crypt() is that it can use different kinds of salts or encryption keys. The two-character salt we’ve been using is pretty weak. It also has a flaw in functionality – using a two-character encryption key, the crypt() function will ignore everything past the first 8 characters of the phrase to be encrypted.

So both of these statements would have the same output.

echo crypt("Gobbledeygook", "ab");
echo crypt("Gobbledeygah", "ab");

The crypt() function is only encrypting the first eight characters – “Gobblede”. The rest is ignored.

You can change this by using a special type of encryption key – a md5 hash. Under normal circumstances, this is enabled in php, but you can double check by seeing if the constant CRYPT_MD5 is set to ’1′.

An md5 hash salt is formatted like this – $1$xxxxxxxx$. “$1$”, followed by eight random characters, followed by a closing “$”. You could create one yourself to use as a salt.

However, in most cases if you provide no salt or encryption key at all, php will generate a random salt for you. So, for example, when you are entering a new password into the database you can use this statement…

$password = crypt("Gobble");

This variable ($password) can now be stored in the database. Remember that $password holds both the encrypted phrase (Gobble) and the random encryption key. So to check if a user entered the correct password you would fetch $password from the database and use this statement…

if ( crypt($userInput, $password) == $password)
{ //  Ok, the passwords matched }

Now that you know how crypt() works, get to it. Start creating user-authentication scripts and work your encryption magic.

The original post has some header information about this particular hack (a modified c100 shell), as well as a link to some search results about the file. I looked through the source code for the shell script and tested it out on my local server – getting some link-filled files is the least that this script could do.

Once the script is loaded on your server, anyone can access it remotely and have full access to your system.

The script allows you to navigate through the server’s directories like any remote file-manager. I noticed that it could even go up out of the web server root and into my local folders as well.

The script gathers up all the details on your computer – like operating system build, running processes, ip address, etc. The user can run shell commands, create files, upload files, and do other kinds of nasty things.

It would be pretty easy for someone to use this to find the mysql username/password, hack your database, do whatever they want, and pretty wreck your entire site. Or worse, they could use this to do some nasty things to the server itself – potentially wrecking other peoples’ sites.

So how do you protect against this? Well, I’m not sure what you would do to protect against the shell script once it’s loaded up. It looks like it’s built to bypass most security precautions and give the hacker access to whatever he or she wants.

Your best bet is to be vigilant in restricting front-end uploads to your site. If you’ve got an upload script, be sure you restrict what file extensions can be uploaded.

This script needs to be named with a file extension that is read as php – so you should never allow users to upload php files (or html if you set up your server to execute those as php).

Being more restrictive is better than less restrictive – so ban all file extensions except the ones you know are safe. So, for example, you might allow “.jpg, .gif, .png” for pictures, and “.doc, .odt, .pdf, .txt, .rtf” for documents.

If you’ve got any other suggestions for security against this sort of thing, please comment away. Otherwise, take a look at the script so that you are aware of what it can do.