Best Practices in Input Validation

Paladion
By Paladion

December 15, 2004

Last week, I polled our consultants on the most common software security errors they saw in 2004. Consultants from across our offices pointed out how simple input validation errors continue to be the #1 problem they see daily. This is really not a new problem; it's just been a difficult one. I asked them for their list of best practices for validating inputs the top 10 recommendations they have been making to clients on input validation. Here's the list they came up with

Last week, I polled our consultants on the most common software security errors they saw in 2004. Consultants from across our offices pointed out how simple input validation errors continue to be the #1 problem they see daily. This is really not a new problem; it's just been a difficult one. I asked them for their list of best practices for validating inputs the top 10 recommendations they have been making to clients on input validation. Here's the list they came up with

  1. Validate all inputs at the server, even if they are validated at the client. Client-side validation can be bypassed trivially, so it's essential to validate inputs at the server before accepting them.
  2. Use a uniform, centralized validation engine for checking all inputs. It improves code reusability, and is easier to maintain, debug and upgrade than scattering validation logic across the application.
  3. Use a white list filter with range, length and format, instead of a black list filter. Defining what is allowed and rejecting everything else is safer than rejecting just the suspicious input. Black list filters frequently become obsolete when a new attack is discovered.
  4. For inputs that cannot have white list filters, check the input for embedded HTML script tags. Free form text boxes are the most common vehicles for cross-site scripting attacks.
  5. Identify special characters and escape them consistently during input validation. Escape characters that cause SQL injection before accepting them. If the output contains external input, escape HTML tags interpretable by the browser.
  6. Validate email address inputs against RFC 822 rules before accepting them. This prevents malicious input in email address fields that cause buffer overruns. Most platforms have underlying classes that perform this validation, so this is easier to implement that it sounds.
  7. If the input is a URL, decode it in the host system before validation. RFC 1738 defines the rules for encoding a URL. Special characters like % < > # { } | ^ etc. should always be encoded. But any other characters in the URL can also be encoded. Attackers try to bypass filters by mixing up encoded and non-encoded characters in the input.
  8. When the input is a filename/path, resolve the name in the host OS during validation. Thwart canonicalization attacks by ensuring that the resource paths are resolved before applying business rules for validating them. Prevent second-order attacks from upstream trusted systems by resolving paths in the application.
  9. When the input contains XML documents, validate it against its schema before using it. Prevent XML injection attacks by ensuring that the XML input follows the rules specified in the schema. Avoid down-stream errors that might be caused from an invalid XML input by validating the XML at the earliest point where it crosses a trust boundary.
  10. If you accept UTF-8 encoding, verify that the input does not contain illegal UTF-8 sequences. Multiple representations decode to the same value, but only the shortest representation is legal according to RFC 2279.

Tags: Best Practices

About

Paladion