Worst Security Problems I've Seen - Web Edition

I thought it would be fun to put together a list of the worst security mistakes that either I've personally seen or coworkers have personally seen and described to me. Unfortunately, as I compiled the list it became too long for a single blog post, so instead of one giant list of security problems, I've created three separate lists broken down by technology. In this post, I'll focus on web issues.

Using default passwords for a common CMS

Content management system (CMS) products allow users to log in and update their own websites without help from a developer. Early on in my career I worked with one particular CMS which was quite well-known, in no small part because advertisements for their product were everywhere.

Our system administrator was poking around one day on a website (I won't give away the company, but you've probably heard of them) that we hadn't built, just curious to see if they were running this CMS, so he typed the URL for the typical login page. Success! He found a login page! Then he put in the default username and password for the super administrator account (admin as both username and password). Success again! At this point, my coworker was in the system with rights to do just about anything. He created a piece of content with title "CHANGE YOUR DEFAULT ADMINISTRATOR PASSWORD" and left.

The moral of the story here is that you should never leave default passwords in place. There is never a good reason to do this. If my friend had been someone nefarious, he could have pretty severely defaced the website of a well-known organization. If that's not enough to convince you, you should realize that not changing default passwords has been cited as a cause for taking several websites down a few weeks ago.

Storing prices in hidden fields on an eCommerce site

Another consultant I worked with was poking around the internet and found an eCommerce site (this is another company you've heard of) that looked poorly built. He approached the owners of the site and offered to rewrite it, but the company turned him down. To prove to the owners how badly the site was built, he bought a product worth $500 for a penny.

How did he do it? The developers of the site decided to store the prices for each item in the cart in hidden fields on the page so the price would stay constant throughout the purchase process. Unfortunately, these hidden fields are easy to find if you know how to find them, and browsers make it surprisingly easy to change their values if you know even a little JavaScript.

The moral of the story is don't store valuable information within hidden fields on the page. And if you're a consultant looking for new customers, purchasing products worth hundreds of dollars for a penny is an effective way to get more customers.

Data from queries going directly into the database

I was debugging some problems with the search functionality that a coworker designed for a system we were building. What I found was that the page where you entered your search criteria sent information to the display page using this format, with the part called a query string underlined:

http://site/page.aspx?[dbfield1]=[searchvalue1]&[dbfield2]=[searchvalue2]

By itself, this approach isn't necessarily a security problem. By putting your search criteria in the query string, you're broadcasting to the world what you're searching for, but no other harm was done. No, instead the problem occurred when the developer had set up the display page to dump the results from the query string directly into the database. Why is that a problem? Someone could put a little bit of code into the search criteria and do some damage to the database. (The damage would be limited if you were smart about the way you set up your database permissions, but that's a topic for another post.) The situation reminds me a bit of this comic:

(Image found on the xkcd website here: http://xkcd.com/327/)

Instead, the developer should have been more careful about the information being passed to the database. Aside from using different text than the column names, which would obscure some of the internals of the system from users, the original developer should have put in other safeguards against SQL injection attacks. Luckily, I fixed the problem before anyone was able to exploit the vulnerability.

Password in query string

Remember in the previous section how data stored in query strings can be seen by any server that intercepts the web traffic? Yeah, don't store sensitive information like passwords in there. I found an instance in a SharePoint site where a consultant we hired did just that. Since it was functionality that wasn't working and didn't leverage SharePoint capabilities, we just ripped it out rather than fixing it.

Using jQuery to hide buttons in SharePoint

Speaking of SharePoint, anyone who has worked with the tool knows that setting up permissions can be fairly difficult if you want to do anything at a more granular level than SharePoint does easily. I have, on more than one occasion, seen developers resort to using jQuery to hide fields that should be hidden. While that seems like a nice solution, there are two problems with it:

• What I said about data and items on a page being easily found and manipulated by JavaScript is true here – if the field is on the page, then a technologically savvy user can find it.
• SharePoint has about a half dozen ways to see information. While it's convenient for users to be able to pull data in a number of different formats, it makes it nearly impossible to reliably hide all places where data could be found (even if you think JavaScript is reliable).

The lesson here: if you need field-level security in your solution, don't use SharePoint. Trust me, just don't.

User-entered text being displayed as HTML

Ok, I'm going to cheat a little bit here and include a security hole that we almost introduced. I was working on a website and the client requested that the users be able to format some of the text so headers and colors could be used. We found an HTML editor to use on the site. I got it working and tested it for most scenarios, then decided just for fun to see if I could run a Cross-Site Scripting (XSS) attack, where I injected some JavaScript to load malicious code. Much to my chagrin, I was successful.

The lesson here: test third party components before using them.

Final thoughts

Luckily no real damage was done in any of these scenarios. I've been fortunate and have never been in a situation where my company or client was hacked due to something we missed. One must always be vigilant, though, since security problems can be introduced at any time, and it only takes one exploited hole for a serious problem to occur.