I cared about getting information about hard faults, file I/O, and disk I/O to see if patterns changed with my work. In order to accomplish this, I started Xpef like this (from an admin console):
xperf -start "NT Kernel Logger" -on PROC_THREAD+LOADER+HARD_FAULTS+FILE_IO+FILE_IO_INIT+DISK_IO -stackwalk FileWrite+FileRead+FileFlush -MaxBuffers 1024 -BufferSize 1024 -f output.etl
The first list options after -on is a list of providers. To see the list of installed kernel providers on your system and what they do, open up a command prompt, and run xperf -providers K.
The options after -stackwalk tells Xperf to get call stacks for certain events. The full list of events supported can be found here. I found it very difficult to get stacks, and if you are on a 64-bit version of windows, you have an extra hoop to jump through. I was actually never able to get stacks from an optimized build with symbols, so I ended up just using debug builds when I needed stacks, and opt builds when I wanted good numbers for everything else.
The -MaxBuffers and -BufferSize arguments were useful to prevent events from being dropped (if Xperf doesn’t have enough memory set aside to record an event, it just drops it). You can tweak those values to your needs, but the values I used should be fine.

Once I ran that command in my console, I’d perform the test I wanted to get data on. Upon completion, Xperf needs to be told to stop, and then have it merge (merging may be unnecessary when you only use kernel providers, but I never tested this theory):
xperf -stop "NT Kernel Logger"
xperf -merge output.etl output_final.etl

You can now open output_final.etl to examine the data you just gathered!

make()
{
  pathpat="(/[^/]*)+:[0-9]+"
  ccred=$(echo -e "\033[0;31m")
  ccyellow=$(echo -e "\033[0;33m")
  ccend=$(echo -e "\033[0m")
  /usr/bin/make "$@" 2>&1 | sed -E -e "/[Ee]rror[: ]/ s%$pathpat%$ccred&$ccend%g" -e "/[Ww]arning[: ]/ s%$pathpat%$ccyellow&$ccend%g"
  return ${PIPESTATUS[0]}
}

Of course, improvements and more ideas welcome! Thanks goes to Curtis for this!

It’s worth a listen though. I talk about some of the features of the new download manager (old news now, but he ask for this interview a while ago…), how I got involved with the Mozilla project, and a few other interesting tidbits including what I’ve currently been working on. There is other interesting things in there too!

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.

After helping setup a bit, I figured it would be a good idea to get the spreadsheet all set-up. Upon opening Quattro Pro, I was informed that the trial had run out and I needed to purchase the product. Crap. I thought she got the full version, but I didn’t have time to find out. Luckily, the place had WiFi, so I figured I’d just go download Open Office and install that. About a minute into the download I realized that I could sit here, wait for the download to finish, and then install it and waste about 20 minutes, or I could just use Google Spreadsheets.

I had never used or read any reviews about it, so I wasn’t sure what to expect. I was pleasantly surprised, however. It’s no Excel, but it got the job done. The best part was that you can download it as an xls file, csv file, or as an HTML file.

They have several functions too, like SUM and AVERAGE, but I couldn’t figure out how to get DATE to work. Overall I was impressed with the service, but it still needs some work and better documentation. If you are ever in a bind and need some type of spreadsheet software though, consider using Google Spreadsheets.

Anyway, the article is a pdf, so if you don’t have Adobe, you can get it here.
DRM Logical Analysis