What is input validation?

The act of ensuring data being input to your software is in a valid format.

We use input validation to restrict incoming data in an attempt to limit the ability of an attacker to do harm. We’re limiting things like SQL injection and JavaScript injection, but we’re potentially also covering attacks we don’t know about yet.

We also use input validation simply to ensure the data matches what the bussiness wants it to be. If we want a phone number then it should look like one!

Input validation is good at limiting risk as it can reduce the types of characters available to an attacker although it has to be used with care to ensure it isn’t restricting genuine input.

Good examples of input validation are specific and strictly limit data to what is reasonable, for example:

• A phone number can contain only numbers, hyphens and brackets and should be no longer than 20 characters
• A postcode cannot be more than 12 characters long and can contain numbers, letters and spaces
• An ID must be formatted as a Guid (e.g. “160702a4-7eb1-44e9-ba6e-4c6886b67ca8”)

Bad examples of input validation:

• The person’s name must be a string – there are lots of characters that wouldn’t reasonably be in a person name that could be used as an attack
• The person’s name must contain only the characters A-Z – this is a whitelist which negatively affects usability. People with non-English names may have accented characters (Renée), also anyone with a hyphen (Johnson-Lynn) or apostrophe (O'Neill) in their name will incorrectly fail validation.
• A person’s address must not contain the characters “£$%^&*-“ - this is a blacklist, typically a whitelist is better as you’re being more specific about what you’ll accept.

Regular expressions (regex) are often used for input validation - Some good regex samples can be found at OWASP.

Input validation can be used in web pages to stop people entering values you don’t want, this provides a good user experience by quickly showing the user their data is wrong. At this point it doesn’t provide any protection to your web service, so that validation must also be used when the data is being accepted by the server.

What can go wrong if we don’t validate input?

What could go wrong inside our service:

• SQL injection
• Command injection
• Javascript (XSS) injection
• lots of other things that we haven’t even thought of yet

What else could go wrong?

If our service is an API the at some point we’re delivering the data we store to another service, that could be a web page, a desktop application, or another service. If we have allowed un-validated input then our data will be given to whatever consumes it and could potentially pose a problem to it. Those consumers could be prone to exactly the same issues our service is (SQL / command / JavaScript etc injections) and they may not be impressed if our data has compromised their service.

Unknown Unknowns

Input validation can provide protection at so many levels, it can protect against known attacks such as SQL injection, but it also has the potential to protect against attacks that are as yet unknown. Attacks often use non-standard characters (like <&~|;) to work and if you only allow letters, numbers and a few basic pieces of punctuation then you’re clearly limiting the likelihood of some attacks.

Conclusions

Input validation is an important part of Defence in depth, it covers known vulnerabilities and potentially helps out with protection for as yet unknown attacks. The best part is that it’s incredibly simple to implement*, you apply a regular expression to all input fields and feel all warm and content that you’ve got a little more depth to your security.

*Ok, regular expressions aren’t always simple