Chapter 6: Input Validation Attacks

Overview

Input validation routines serve as a first line of defense for a web application. Many attacks like SQL injection, HTML injection (and its subset of cross-site scripting), and verbose error generation are predicated on the ability of an attacker to submit some type of unexpected input to the application. These routines try to ensure that the data is in a format and of a type that is useful to the application. Without robust checks that minimize the potential for misuse, the integrity of an application and its information can be compromised.

Imagine the credit card field for an application's shopping cart. First of all, the credit card number will only consist of digits. Furthermore, most credit card numbers are only 16 digits long, but a few will be less. So, the first validation routine will be a length check. Does the input contain 14 to 16 characters ? The second check will be for content. Does the input contain any character that is not a number? We could add another check to the system that determines whether or not the data represents a reasonable credit card number. The value "0000111122223333" is definitely not a credit card number, but what about "4435786912639983"? A simple function can determine if a 16-character value satisfies the checksum required of valid credit card numbers . The syntax of a credit card number can be checked to a rather specific degree, such as a card type that uses only15 digits, starts with a 3 and the second digit isa4ora7. Note that the credit card example demonstrates how to test the validity of the inputthe string of digits. The example does not make any attempt to determine if the number corresponds to a valid card, matches the user 's name and address, or otherwise validate the card itself. This chapter focuses on the dangers inherent to placing trust in user-supplied data and the ways an application can be attacked if it does not properly restrict the type of data it expects.

Data validation can be complex, but it forms a major basis of application security. Application programmers must exercise a little prescience to figure out all of the possible values that a user might enter into a form field. We just mentioned three simple checks for credit card validation: length, content, checksum. These tests can be programmed in JavaScript, placed in the HTML page, and served over SSL. The JavaScript solution sounds simple enough at first glance, but it is also one of the biggest made by developers. As we will see in the upcoming sections, client-side input validation routines can be bypassed and SSL only preserves the confidentiality of a web transaction. In other words, we can't trust the web browser to perform the security checks we expect and encrypting the connection (via SSL) has no bearing on the content of the data submitted to the application.