Chapter 5. Validate All Input


Wisdom will save you from the ways of wicked men, from men whose words are perverse...

 Proverbs 2:12 (NIV)
Table of Contents
5.1. Command line
5.2. Environment Variables
5.2.1. Some Environment Variables are Dangerous
5.2.2. Environment Variable Storage Format is Dangerous
5.2.3. The Solution - Extract and Erase
5.2.4. Don't Let Users Set Their Own Environment Variables
5.3. File Descriptors
5.4. File Names
5.5. File Contents
5.6. Web-Based Application Inputs (Especially CGI Scripts)
5.7. Other Inputs
5.8. Human Language (Locale) Selection
5.8.1. How Locales are Selected
5.8.2. Locale Support Mechanisms
5.8.3. Legal Values
5.8.4. Bottom Line
5.9. Character Encoding
5.9.1. Introduction to Character Encoding
5.9.2. Introduction to UTF-8
5.9.3. UTF-8 Security Issues
5.9.4. UTF-8 Legal Values
5.9.5. UTF-8 Related Issues
5.10. Prevent Cross-site Malicious Content on Input
5.11. Filter HTML/URIs That May Be Re-presented
5.11.1. Remove or Forbid Some HTML Data
5.11.2. Encoding HTML Data
5.11.3. Validating HTML Data
5.11.4. Validating Hypertext Links (URIs/URLs)
5.11.5. Other HTML tags
5.11.6. Related Issues
5.12. Forbid HTTP GET To Perform Non-Queries
5.13. Counter SPAM
5.14. Limit Valid Input Time and Load Level

Some inputs are from untrustable users, so those inputs must be validated (filtered) before being used. You should determine what is legal and reject anything that does not match that definition. Do not do the reverse (identify what is illegal and write code to reject those cases), because you are likely to forget to handle an important case of illegal input.

There is a good reason for identifying ``illegal'' values, though, and that's as a set of tests (usually just executed in your head) to be sure that your validation code is thorough. When I set up an input filter, I mentally attack the filter to see if there are illegal values that could get through. Depending on the input, here are a few examples of common ``illegal'' values that your input filters may need to prevent: the empty string, ".", "..", "../", anything starting with "/" or ".", anything with "/" or "&" inside it, any control characters (especially NIL and newline), and/or any characters with the ``high bit'' set (especially values decimal 254 and 255, and character 133 is the Unicode Next-of-line character used by OS/390). Again, your code should not be checking for ``bad'' values; you should do this check mentally to be sure that your pattern ruthlessly limits input values to legal values. If your pattern isn't sufficiently narrow, you need to carefully re-examine the pattern to see if there are other problems.

Limit the maximum character length (and minimum length if appropriate), and be sure to not lose control when such lengths are exceeded (see Chapter 6 for more about buffer overflows).

Here are a few common data types, and things you should validate before using them from an untrusted user:

Unless you account for them, the legal character patterns must not include characters or character sequences that have special meaning to either the program internals or the eventual output:

These tests should usually be centralized in one place so that the validity tests can be easily examined for correctness later.

Make sure that your validity test is actually correct; this is particularly a problem when checking input that will be used by another program (such as a filename, email address, or URL). Often these tests have subtle errors, producing the so-called ``deputy problem'' (where the checking program makes different assumptions than the program that actually uses the data). If there's a relevant standard, look at it, but also search to see if the program has extensions that you need to know about.

While parsing user input, it's a good idea to temporarily drop all privileges, or even create separate processes (with the parser having permanently dropped privileges, and the other process performing security checks against the parser requests). This is especially true if the parsing task is complex (e.g., if you use a lex-like or yacc-like tool), or if the programming language doesn't protect against buffer overflows (e.g., C and C++). See Section 7.4 for more information on minimizing privileges.

When using data for security decisions (e.g., ``let this user in''), be sure to use trustworthy channels. For example, on a public Internet, don't just use the machine IP address or port number as the sole way to authenticate users, because in most environments this information can be set by the (potentially malicious) user. See Section 7.12 for more information.

The following subsections discuss different kinds of inputs to a program; note that input includes process state such as environment variables, umask values, and so on. Not all inputs are under the control of an untrusted user, so you need only worry about those inputs that are.