Avoiding 10 common Web-application flaws

• Tags:
• Security,
• Internethackers,
• Programming Errors,
• Attackers

Ronald Anthony Lewis Builder.com

Published: 19 Feb 2004 11:40 GMT

• 
• 
• 
• 
• 

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:

Blind trust of information retrieved from cookies and parameters passed in the URL

Unchecked input on screens

Pre-validation accounts

Unconstrained user navigation

Setting Web folder permissions incorrectly

Caching of sensitive information

Leaving Web server demos installed (like those loaded by default with IIS)

Forgetting to change default passwords on the database backend

Not loading security patches

Leaving Web administration ports enabled

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.

• 
• 
• 
• 

• Share this article:
• Digg
• Slashdot
• Del.ici.ous
• Stumble
• Reddit

• Most Recent
• Most Popular
• Most Discussed