If only writing articles were as easy as testing the security of Web applications. I was recently asked to compile a list of the most common Web application security mistakes. These are the "gotchas" I usually see:
Here's a brief description of the first five common mistakes:
Trust but verify
"Trust but verify" was the motto of one of my favourite bosses. This is a motto that Web application designers and programmers would do well to adopt. While cookies and URL-borne parameters make life much easier for the developer, the data passed in should always be validated.
Many Web-based businesses learned this the hard way with the infamous "shopping cart vulnerability," which enabled cyber thieves to change prices of items placed in the shopping cart. The shopping cart was nothing more than a text-based cookie. Upon checkout, the server would total the prices for the items stored in the cookie. Imagine -- the client had total control over the prices. Worse, the server had no means of validating the data. I'm sure a lot of businesses experienced sticker shock!
The best way to check for this is to clear all cookies, run the application, and look at the cookies written to the disk. I always look at cookie content to validate that sensitive information is not stored in cookies such as roles -- or worse, user IDs and passwords.
Commands can equate to control
I was once asked to look at a system that passed program controls via parameters sent in the URL. As I looked at the source code, I noticed a common thread. System-level commands were embedded in the URL as follows: "action='do something.'"
During testing, I crafted a couple of customised URLs to see how the system handled them. Consequently, I was able to take control of the system via the commands I passed in that the system didn't anticipate: "action='cat xxx >> /etc/passwd.'"
The long and short of it is this: if you pass parameters via the URL-bar, at least parse them for invalid and malicious content. Set some constraints for your parameters so that if an unexpected value is passed in, your application can handle it properly. This is also easy to test -- modify the address in the URL bar and see how the application handles the data.
