Expect The Unexpected

One of the biggest failures of input validation is writing the routines in JavaScript and placing them in the browser. At first, it may seem desirable to use any client-side scripting language for validation routines because the processing does not have to be performed on the server. Client-side filters are simple to implement and are widely supported among web browsers (although individual browser quirks still lead to developer headaches ). Most importantly, they move a lot of processing from the web server to the end-user's system. This is really a pyrrhic victory for the application. The web browser is an untrusted, uncontrollable environment, because all data coming from and going to the web browser can be modified in transit irregardless of input validation routines. It is much cheaper to buy the hardware for another web server to handle the additional server-side input validation processing than to wait for a malicious user to compromise the application with a simple "%0a" in a parameter.

Attacks against input validation routines can target different aspects of the application. It is important to understand how an attacker might exploit an inadequate validation routine. The threats go well beyond mere "garbage data" errors.

• Data storage   This includes characters used in SQL injection attacks. These characters can be used to rewrite the database query so that it performs a custom action for the attacker. An error might reveal information as simple as the programming language used in the application or as detailed as a raw SQL query sent from the application to its database.

• Other users   This includes cross-site scripting and other attacks related to "phishing." The attacker might submit data that rewrites the HTML to steal information from an unsuspecting user or mislead that user into divulging sensitive information.

• Web server's host   These attacks may be specific to the operating system, such as inserting a semicolon to run arbitrary commands on a UNIX web server. An application may intend to execute a command on the web server, but be tricked into executing alternate commands through the use of special characters.

• Application content   An attacker may be able to generate errors that reveal information about the application's programming language. Other attacks might bypass restrictions on the types of files retrieved by a browser. For example, many versions of the Nimda worm used an alternate encoding of a slash character (used to delimit directories) to bypass the IIS security check to keep users from requesting files outside of the web document root.

• Buffer overflows in the server   Overflow attacks plagued programs for years and web applications are no different. This attack involves throwing as much as possible against a single variable or field and watching the result. The result may be an application crash or could end up executing arbitrary commands. Buffer overflows are typically more of a concern for compiled languages like C and C++ rather than interpreted languages like Perl or Python. The nature of web platforms based on .NET and Java make application-layer buffer overflows very difficult because they don't allow the programmer to directly deal with stack and heap allocations (which are the playground of buffer overflows). It is more likely that a buffer overflow will exist in the language platform.

• Obtain arbitrary data access   A user may be able to access data for a peer user, such as one customer being able to view another customer's billing information. A user may be able to access privileged data, such as an anonymous user being able to enumerate, create, or delete users. Data access also applies to restricted files or administration areas of the application.