• More people exposed to more parts of the code base
• More review bandwidth so more work can be checked into the tree
• Less dependence on a small set of people

In order to get more people doing this, it would be good to document to look for, and how to make sure the code is sound. I’m sure every reviewer does things a bit differently, but I’m going to share my process. There are two types of review I do these days: feedback and review.

Feedback

Feedback is pretty simple to do, and I can usually fly though any patch (even large ones) quickly. This isn’t very thorough (in fact, I tend to keep it to general comments), but I look for the following things:

• correct API usage (XPCOM, jsm, whatever)
• internal invariants are not violated
• any new APIs created make sense and aren’t confusing
• code style matches what’s there, or follows the style guide

Review

Review is more important because once a patch gets r+, it can generally land in the tree. Consequentially, I tend to spend a lot more time on any given patch. In addition to all the things I do for a feedback request (which are looked at more closely for a review), I’ll also look at the following:

• evaluate how well tested is the code that is being added/modified. If it isn’t well tested, I’ll generally suggest a set of test cases that I feel are the bare minimum this needs to land.
• evaluate how this might impact other work going on in this area of the codebase
• ensure this doesn’t add any I/O on the GUI thread
• apply the patch and run the tests
• if the patch looks like it might regress performance, ask for the author to verify that it does not

Note that a number of these things may not be done if I know what the patch author has already done to ensure the patch is safe.

Trusting the User

First of all, just don’t do it. The number one, most important rule you can have as a developer is to never, ever, trust the data you receive from your users. Ever. A large number of the vulnerabilities (some of which I’ll be discussing) can actually be avoiding if the proper precautions are taken and the user’s data is properly processed. As a developer you might think “none of the people that are interested in my web site would be malicious, so I don’t have to worry about that.” That isn’t a wise idea to have, however, as a user could unintentionally enter some data in that exploits a security hole, and now you are up a creek without a paddle.

Let me reiterate this point. Never, ever trust data from the user. Even if you check something client side with JavaScript, you should not trust it. Remember that some people turn off JavaScript, making those checks completely useless. Being paranoid about user input and assuming everything they can do could be malicious will greatly prevent many of the common security vulnerabilities found in PHP applications.

Descriptive Error Messages

While these can be a big help when debugging, descriptive error messages can also be a big help to potential attackers. Based on the information given in an error message, a malicious user could find out information about your application’s database structure, file system layout, or other worse things. Make sure that any error checking you do with the users data will give the least amount of information needed by the user to correct whatever they did wrong.

In addition to your own generated errors, PHP can report a variety of script errors, warnings, and notices, all of which a malicious user could use against you. The good news is that you can disable these on your production server with an .htaccess directive or in your php.ini file by setting error_reporting to 0. Do not try using ini_set though! If a fatal error occurs in your script, the value you specify with ini_set will not have any affect, so everything you are trying to prevent being displayed will still be displayed.

The best way to keep track of the errors, warnings, and notices that are not important to the user, but are useful to you when debugging is to use PHP’s built in logging functions. You can do this just like you do with error reporting by setting the error_logging directive to true and setting the error_log directive to the filename that you want to log to. If these are set with ini_set, the error simply won’t be logged so it isn’t a security risk (just harder for you as the developer to debug). Once you have the log file setup, simply use the trigger_error function like so:

trigger_error('A serious error occurred: DETAILS', E_USER_ERROR);

The first parameter is a string with whatever you want to be logged. The second parameter is the PHP error type, which defaults to E_USER_NOTICE if left unspecified.

Insecure Database Setup

The default username and password for popular databases are well known. Leaving these at their default value allows for easy entry to anyone who is able to figure out where your database server is. The default setup is the first thing an attacker would try in an attempt to get in, so try not to make their job easier!

It is also a good idea to set up different users with specific privileges for your web application. Ideally, anything that a normal user can do should fall under a limited account. By only allowing the client’s database user to insert and update tuples, or rows in the table, you drastically cut back on the type of damage they can do. Of course, you’ll probably need to have some ability to delete an arbitrary tuple, but with this restriction it seems impossible to do. The good news is that there is a trivial way to get around this. Simply add another field to the database called something like is_deleted and have it set to 0 by default. When you want to delete something, simply set it to 1. When you are querying data, just look for results that do not have is_deleted set to 1, and it will appear to be deleted. The administrators should use a different database user that allows for deleting, and every so often they can run a script that deletes these entries.

SQL Injection Attacks

SQL injection attacks come about from developers trusting their users to not be malicious. These attacks are the most common security hazard when communicating with a database. Since the most popular database system in use today with PHP applications is MySQL, these examples are going to be written with its api functions. Let’s take a look at the common example of a login script. Generally, they’ll be some query like this:

$sql = “SELECT * FROM `user` WHERE `uname` = '{$_POST['uname']}' AND `pwd` = '{$_POST['pwd']}'”;
$query = mysql_query($sql);

While this might look safe, it isn’t. What if some user entered in “' OR 1 = 1 #” as their username? Now the query will result in all the rows in the table being returned, but that’s clearly not what we want! The query that is executed will look like this:

SELECT * FROM `user` WHERE `uname` = '' OR 1 = 1 # AND `pwd` = ''

This clearly isn’t what we wanted, so let’s take a look why this is the result. The hash symbol (#) indicates a comment, and MySQL will simply ignore everything after it. Since one always equals one, all tuples will be returned. Now, if the developer didn’t check for the number of rows and just grabs the first result returned by the query, the attacker will now be logged in as the first user in the user table. You’ll often find that the first user is an administrator of some type, so this attacker can now go around your site as an administrator. With a bit more effort, the attacker could create an account for themselves, modify entries in the table, or worse. This all happened because we violated our first rule and trusted user input.

There are two solutions to this problem, and both of which are fairly easy to implement. If you are determined to use the mysql_* functions (or are required to use PHP < 5.1), you have to escape the users input like so:

$uname = mysql_real_escape_string($_POST['uname']);
$pwd = mysql_real_escape_string($_POST['pwd']);
$sql = “SELECT * FROM `user` WHERE `uname` = ‘$uname’ AND `pwd` = ‘$pwd’”;
$query = mysql_query($sql);

Be careful if the magic_quotes_gpc directive is set, as you'll have to remove the slashes it adds before calling mysql_real_escape_string because some things will get escaped twice. The magic_quotes_gpc directive adds a slash before single-quotes, double-quotes, backslashes, and NULs. MySQL's function escapes three additional characters; \n, \r, and \x1a. As a result, some things are escaped twice, which produces results other than what we intended.

If you are lucky enough to be using PHP 5.1 or later, you'll have the ability to use the PHP Data Object (PDO) class. The PDO class is an abstraction layer used to interface with databases. The best part about it is that it was designed in a way that defending against SQL injection attacks is just part of the process. Let's take a look at how we can write our query with PDO:

$stmt = $db->prepare(“SELECT * FROM user WHERE uname = :uname AND pwd
= :pwd”);
$stmt->execute(array(':uname' => $_POST['uname'], ':pwd' => $_POST['pwd']));
$result = $stmt->fetch();

Calling PDO->prepare and then PDOStatement->execute gives you two benefits. First, it will properly escape the variables you pass in, preventing the SQL injection attack. Secondly, if you plan on issuing a SQL statement multiple times, calling PDO->prepare initially, then calling PDOStatement->execute each time you want to run the query, your calls will be optimized by the database driver by caching the query plan and meta data. This can result in huge performance benefits. There is also a function that is just like mysql_query, and that's PDO->query, but I wouldn't recommend using it because of the benefits obtained by PDO->prepare and PDOStatement->execute.

Improper Handling of Includes

Some websites like to dynamically include another page with a url parameter. While this can be incredibly useful, it can also be incredibly dangerous. The PHP code to include this file might look something like this:

Now, a url like index.php?p=news.html. works just fine. However, we are trusting our user here to not enter something malicious in the query string. What if the url is index.php?p=.htpasswd? The malicious user suddenly has our .htpasswd file, and with the right resources, could figure out passwords to log in to secured parts of the website. The attacker could potentially get any file that your webserver has permission to access. The fix for this is to check the filename against a list of ones that you are expecting. You should also set the PHP directive open_basedir to the paths that you will be opening files from. PHP will then make sure that you never open a file outside of the specified path(s).

If your server is not configured properly, this hole could be used to execute a remote php script as well, letting the attacker run arbitrary code on your server. To prevent this, set the allow_url_fopen directive to false. This can only be set in your .htaccess file or php.ini, however, so don't try using ini_set.

Conclusion

Assuming that your site is safe from attackers without actually taking steps to ensure that it is safe is an accident waiting to happen. Assuming that everyone is out to get you and your site, while it might seem to be a symptom of paranoia, can save you a lot of headaches if something bad were to happen. Most of the common security problems with PHP are the result of trusting the user, so remember our first rule, never, ever trust the data you receive from your user.

Well, my initial plans were to use XBL to implement a large portion of the code as per conversations with my co-conspirator Alex. Well, bz brought up an intersting point – XBL isn’t applied to elements that have a CSS property of display:none. Well, seeing as how repetition templates are supposed to be hidden with that CSS property, I couldn’t use XBL.

As a result, I get to test my knowledge of C++. Yey! I’d like to state right now that my skills in C++ are not great. In fact, I have very little expereice with it. I mean, I only have had two classes in C++, and one was a very basic course. I feel it goes without saying that I really have my work cut out for myself.

All is not lost, however. There are some really useful tools that are making this so much easier. For example, lxr lets me easily look at existing code and see how things are done the “right” way. Then, there is always a ton of documentation available on Devmo, XUL Planet, and occasionally Google comes into play. Then of course I always have the wonderful folks on irc in #developers. Folks like biesi, bz, and timeless have helped me countless times, and I am really greatful.

This is going to be a long and and winding road, but it will be very beneficial for me. I’ve already learned a lot, and I’ve got a lot more to learn.

#include
using namespace std;

class Babies {};

int
main()
{
  try {
    throw Babies();
  } catch(class Babies e) {
    cout << "Congratulations.  You caught the babies." << endl;
  }
  return 0;
}

I mean, come on...where else can you legally throw Babies?

The bug has to deal with a security error that isn’t an error in the current version of Firefox, but is an error in Bon Echo, the alpha release of Firefox 2.0. It’s a good thing that I test these things, as that would have been a big monkey wrench once 2.0 came out. I’ve found a workaround for it, but I fear that the workaround leaves the same security hole open that was patched in Bon Echo.

Regrettably, it also happens to be bug that kills the main feature of my most popular extension, RTSE. It will also kill the main feature in an extension I’ve been planning to make. Can we say ‘Curses’ anyone? Of course, this won’t affect Firefox 1.5.0.*, so those of you who uses the stable builds of Firefox will have nothing to worry about for some time.

I’ll keep updating this in the comments for anyone that is interested.

For background information, this attribute is spec’d out by WHATWG, who, as stated on their website, are “a loose unofficial collaboration of Web browser manufacturers and interested parties who wish to develop new technologies designed to allow authors to write and deploy Applications over the World Wide Web.”

The ping attribute is supposed to allow tracking of what links a user clicks on. Now, many might say “Woah, I don’t want my clicking to be tracked!” However, I can assure you that many websites already do this. The catch is that they don’t exactly inform you that they are doing it. The idea of this spec is to make this easier for developers to do, but at the same to have User Agents (i.e. browsers) give the user options. The whole spec can be found here, but in summary, the benefits of this attribute to the user are numerous.

• It will allow the user to see the final target location plainly
• It will allow the user to disable the notifications without losing the underlying link functionality (many methods that currently accomplish the same goal will break if the user disables javascript)
• It will allow the browser to send the ping when the user isn’t actively loading a page so that the target page loads faster

Maybe it’s just me, but it seems to me that this is a good thing. By making things easier for developers, they’ll probably use it (especially once a few other browsers pick it up), and by doing so give the users more control over their privacy. It seems as though most people just pick out the fact that it is now easier for websites to track where you are going, and are completely overlooking the fact that it gives the user a lot more control. Even with this though, I think most people probably won’t care, but will get the added security of easily knowing when they are being tracked. For me, that is significantly better than the current situation on the web.

Go figure. Took me 30 minutes to find that annoying bug.