Several weeks ago, I received a frantic call from an administrator of a site running a popular fork of osCommerce, saying he had 72 hours to fix dozens of vulnerabilities reported by ScanAlert–the company behind the “Hacker Safe” PCI compliance logo–or his right to display the Hacker Safe logo would be revoked. I ended up doing the job I was asked to do: I not only eliminated all of reported vulnerabilities, but in the eyes of ScanAlert, the site was now able to display the presumably more stringent Visa branded PCI compliance seal, which it hadn’t been able to do before. Although the customer was relieved and even downright ecstatic about the outcome, I was left with some very mixed feelings about ScanAlert, and the work I had done.

First, I’ll describe the solution I implemented, then I’ll blow a lot of hot air about my general misgivings about ScanAlert and my “solution.” And before we go any further, let me say that in no way am I implying that either osCommerce or PHP is inherently weak on security, so settle down already.

Becoming “Hacker Safe”

Upon receiving ScanAlert’s report, I immediately saw that almost all of vulnerabilities reported by ScanAlert were cross site scripting (XSS) vulnerabilities. Now, I’m not particularly knowledgeable about XSS attacks, but I really didn’t need to be to see what ScanAlert was doing and figure out how to strategize around it(!). Basically, ScanAlert was sending various GET and POST requests to the system remotely and scanning the response to see if they had successfully injected what could be malicious code in the response.

The administrator who contacted me assumed I would sift through the code and fix each error individually on a per case basis, which given the large number of vulnerabilities as well as the size and complexity of the osCommerce code base, would probably not get done in the 72 hour window. Even if I focused on updating just the core functions and classes in osCommerce, I am not sure I could have plugged every hole in time. Furthermore, such changes would introduce a tremendous maintenance burden whenever the site was upgraded to a new version of osCommerce, especially as the administrator had no real knowledge of PHP. And, given various constraints, that included the administrator’s reluctance to contribute any code he has paid for to open source projects, it didn’t appear practical to try to update the core osCommerce code and submit changes back to the project.

So, just to be clear, my goal really wasn’t to “fix” this aspect of osCommerce or even to make the site more secure necessarily, it was to achieve “Hacker Safe” approval in a given amount of time and do so in a way that could be maintained by the system administrator.

Fortunately, this fork of osCommerce had theme/templating capabilities, and the site was already using a customized template , which meant that I could inject the code into the main template script, and it would execute before any output was sent to the browser and “sanitize” any user input at that point. Because I would be injecting the code into a customized template that was already being maintained and accounted for in upgrades, I could add this code without adding to the administrator’s responsibilities.

Now, I thought I remembered that in PHP, a stock approach to preventing XSS when constructing the response is to use the built-in htmlentities() function, so I started there, quickly coming up with this basic approach:

function sanitize(&$input) {
  foreach ($input as $key => $value) {
    $input[$key] = htmlentities(html_entity_decode($value));
 }
}
if (! empty($_GET)) {
  sanitize($_GET);
}
if (! empty($_POST)) {
  sanitize($_POST);
}

The reason I used both html_entity_decode() and htmlentities() together is because it became apparent that at certain points in osCommerce, htmlentities() was being applied to some values in the course of processing requests, so by calling html_entity_decode() (the result of which is the opposite of calling htmlentities()) on every value first, I could ensure that the values would be encoded in such a way as to be appropriate for input to htmlentities().

This approach plugged some holes, but wasn’t nearly enough to satisfy ScanAlert, so after some quick Googling, I came across a small PHP function designed to more aggressively scrub data against XSS attacks. I substituted that function for the htmlentities(html_entity_decode($value)) call above, re-ran ScanAlert and viola, no more XSS vulnerabilities! Not only did the site now have Hacker Safe approval, it now also had Visa PCI compliance, which it hadn’t had before.

Obviously, this approach is pretty generally applicable outside of osCommerce and could be adapted to work outside of PHP also with a little work. Even in the case of osCommerce, which does not follow an MVC approach in the least, I was able to find a point just prior to rendering the browser template where I could inject this code. It was effective in achieving PCI compliance, at least as judged by ScanAlert, and it might even turn out to be a quick and easy way to truly and effectively combat XSS vulnerabilities in general.

What did I really accomplish?

Although I have a decent amount of knowledge about, and experience with, both PHP and osCommerce based applications, you may have noticed that I am not an expert on Web application security, and this was my first brush with trying to achieve PCI compliance. Its a little scary that with no real directly applicable knowledge I was able to easily implement a solution.

From the beginning, the entire ScanAlert situation seemed sketchy. This site had been displaying the Hacker Safe logo for several weeks, telling customers that the site had been scanned, tested and certified. During that time, no updates were made to the underlying code, yet suddenly, more than 80 vulnerabilities were detected, and all but four were XSS errors.

Also, we were given 72 hours to fix the site, which was certainly nice of ScanAlert. Yet, anyone going to the site during that time would be told that the site was “Hacker Safe” even though there were presumably over 80 vulnerabilities on the site. I don’t know about you, but 80 vulnerabilities sounds like a lot, so, should we really be promising customers they are “Hacker Safe” in this situation?

As I read ScanAlert’s reports in more detail and discovered what they were doing, it was evident that other than port scanning, detecting XSS vulnerabilities is ScanAlert’s bread and butter. (It did detect an “SQL injection” vulnerability when it found a script outputting the results of the phpinfo() function in PHP. Presumably, from this output, ScanAlert’s software saw that PHP was compiled with MySQL support and dutifully reported that the database was “MS SQL”.)

So basically, when it came to the Web application itself, ScanAlert only really checks for one class of vulnerabilities, and this isn’t surprising when you realize that all ScanAlert does is probe the application remotely, and obviously, they don’t want to damage their customers’ sites, which significantly limits the effectiveness of probing for say, SQL injection vulnerabilities.

Yet in a Dilbertesque attempt to quantify the unquantifiable, ScanAlert claims that their scans account for 99.9% of all Web application vulnerabilities. (Interestingly, this figure was plastered all over the ScanAlert site at one time, and now I can’t find it anywhere…) Anecdotally, I don’t even think that ScanAlert can claim to account for 99.9% of XSS vulnerabilities.

But perhaps I’m being too judgmental, and looking at this situation from the wrong point of view. PCI guidelines were developed by the credit card companies as a way of reassuring customers that it was indeed safe to use their credit cards on compliant sites. In other words, its ultimately a marketing ploy, and ScanAlert is just taking this to an extreme. If your site is not PCI compliant (and this needs to be verified quarterly, I believe), the credit card companies may stop accepting your business until you get with the program, but there is no rule saying that you have to use ScanAlert or any other company. But you probably don’t want to scan your own site on a regular basis, so ScanAlert is just one of many companies willing to provide that service for you.

And ScanAlert supplies obvious value added services: they scan your site daily (presumably) and allow you to display a logo saying as much, so your customers can also have a false sense of security. ScanAlert claims that displaying the Hacker Safe logo translates directly into increased sales on your site.

And of course, this is ultimately what is boils down to, money. Whether or not your site is more secure it has the appearance of being more secure, and that’s what ScanAlert really sells. And if you display the Hacker Safe logo, you’re selling it too. The problem I have with this is that is relies on and exploits the ignorance of customers and even the site administrators. Before this job, I really didn’t know what was behind the Hacker Safe logo, nor did I care. I’m sure I simply felt reassured when I saw it.

And despite trying to educate my client with what little new found knowledge I had, I don’t think he fully understood all these implications either. So, despite having a completed job, a happy client and money in the bank to show for it, I am left wondering if this really was a successful job, or if I am merely a player in someone else’s game.

Is the site more secure now? Yes, to a point, many obvious holes were plugged. But even if the site is now 99.9% “hacker proof” that .1% is still probably plenty of room for a determined cracker.

What is even more disturbing to me is what this says about the security of the code that I (and probably you too) create. I don’t think I’m alone when I say that I am under considerable pressure to complete projects, which means adding features, functionality. Its my boss’ job to squeeze as much out of me as he can in as little time as possible. And its a full time job just getting that damn computer to do what it should do, I just don’t have a lot of time to protect against what it shouldn’t do.

And in all that spare time I get, I have to constantly continue learning my craft (reading about design best practices for example) as well as the keeping up with the various languages, libraries and frameworks to practice that craft. What, you think Ruby on Rails is the last framework you will ever have to learn? Ha! Some people probably thought that about Struts too…

Learning these tools and practices is interesting–dare I say fun–and leaves me feeling like I have improved my skills and made myself more productive and more valuable to my employer. Even if time wasn’t a factor, deeply educating myself about application security just isn’t as sexy.

I think our best hope for salvation in this situation is the fact that as open source developers, we don’t have to know everything and test it all ourselves. We can invest in collaboration, putting our security best practices into the code for our libraries and frameworks thereby benefiting from each others’ knowledge and hard work.

I’d be interested to hear others’ thoughts on this. What resources to you use to educate yourself and keep up to date about security concerns? What FOSS tools do you use to secure your code or check for vulnerabilities?