We all know that there is a lot of pressure on companies to offer new or upgraded services over the Internet. We also know that a lot of this pressure funnels to the development groups that are tasked with quickly (usually, too quickly) releasing functionality that the masses can consume. The fact is, exploiting security vulnerabilities in web facing applications is one of the most common ways in which hackers get access to data or systems that they shouldn’t and is also one of the leading risk areas for identity theft.
A cornerstone of almost any type of web application is input: the simple act of asking the user to enter information for the web application to process. The problem is that too many web applications still fail to validate incoming data. It is one of the leading causes of web application compromise. Why is this obvious requirement routinely ignored?
There are at least three places that input validation can occur:
- at the user’s browser as part of client-side HTML code
(e.g., javascript),
- at the web server
- in the web application itself.
Each of these components has an opportunity to evaluate the data that was supplied for a particular field and then determine if it should be rejected or sent on.
From a security perspective, we would like to see input validated in all three places. In addition, we would like to see the server perform output validation before sending data back to the client. Why do we need to check in all of these components? You need to check in all places because you don’t know where corrupt or malicious data may come from.
To illustrate, you can bypass client-side validation by using a web proxy. You can bypass the server by making calls directly to the web application functions. You can even bypass the web application itself, if you have direct access to the database (or file or data store) on the server. The bottom line is there are a number of places that the data can be corrupted and performing input validation in multiple places ensures that accidental or malicious data is not processed.
Most application developers understand the characteristics of acceptable input. It should be a requirement that those characteristics are always validated for each field – that is, do not assume that you can trust the component that just handed you the data.
Should a first name field allow the “<” or “%” characters? Should a monetary number field allow alphabetic or special characters? Should a credit card or social security field allow escaped command sequences? The answer, of course, to all of these is no.
The design philosophy has to be:
- Validate input data wherever possible
- Pay as much attention to what’s going into the web application as what’s coming out of it
Input Validation; it’s not sexy. It is not an interesting technological challenge. It is just a simple best practice that makes your web environment much more secure.
No comments:
Post a Comment