Improving Web Application Security: Threats and Countermeasures

Examine how your application validates input because many Web application attacks use deliberately malformed input . SQL injection, cross-site scripting (XSS), buffer overflow, code injection, and numerous other denial of service and elevation of privilege attacks can exploit poor input validation. Table 5.1 highlights the most common input validation vulnerabilities.

Review the following questions to help you identify potential input validation security issues:

• How do you validate input?

• What do you do with the input?

How Do You Validate Input?

What approach to input validation does your design specify? First, your design should lay out the strategy. Your application should constrain, reject, and sanitize all of the input it receives. Constraining input is the best approach because validating data for known valid types, patterns, and ranges is much easier than validating data by looking for known bad characters . With a defense in depth strategy, you should also reject known bad input and sanitize input.

The following questions can help you identify potential vulnerabilities:

• Do you know your entry points?

  Make sure the design identifies entry points of the application so that you can track what happens to individual input fields. Consider Web page input, input to components and Web services, and input from databases.

• Do you know your trust boundaries?

  Input validation is not always necessary if the input is passed from a trusted source inside your trust boundary, but it should be considered mandatory if the input is passed from sources that are not trusted.

• Do you validate Web page input?

  Do not consider the end user as a trusted source of data. Make sure you validate regular and hidden form fields, query strings, and cookies.

• Do you validate arguments that are passed to your components or Web services?

  The only case where it might be safe not to do so is where data is received from inside the current trust boundary. However, with a defense in depth strategy, multiple validation layers are recommended.

• Do you validate data that is retrieved from a database?

  You should also validate this form of input, especially if other applications write to the database. Make no assumptions about how thorough the input validation of the other application is.

• Do you centralize your approach?

  For common types of input fields, examine whether or not you are using common validation and filtering libraries to ensure that validation rules are performed consistently.

• Do you rely on client-side validation?

  Do not. Client-side validation can be used to reduce the number of round trips to the server, but do not rely on it for security because it is easy to bypass. Validate all input at the server.

What Do You Do with the Input?

Check what your application does with its input because different types of processing can lead to various types of vulnerabilities. For example, if you use input in SQL queries your application is potentially vulnerable to SQL injection.

Review the following questions to help you identify possible vulnerabilities:

• Is your application susceptible to canonicalization issues?

  Check whether your application uses names based on input to make security decisions. For example, does it accept user names, file names, or URLs? These are notorious for canonicalization bugs because of the many ways that the names can be represented. If your application does accept names as input, check that they are validated and converted to their canonical representation before processing.

• Is your application susceptible to SQL injection attacks?

  Pay close attention to any input field that you use to form a SQL database query. Check that these fields are suitably validated for type, format, length, and range. Also check how the queries are generated. If you use parameterized stored procedures, input parameters are treated as literals and are not treated as executable code. This is effective risk mitigation.

• Is your application susceptible to XSS attacks?

  If you include input fields in the HTML output stream, you might be vulnerable to XSS. Check that input is validated and that output is encoded. Pay close attention to how input fields that accept a range of HTML characters are processed .