It's a mistake because attackers are quite clever; they can often think of yet another dangerous data value.Instead, determine what is , check if the data matches that definition, and reject anything that doesn't match that definition.If you can keep malicious data from entering your program, or at least keep it from being processed, your program becomes much harder to attack.This is very similar to how firewalls protect computer networks from attackers; it won't prevent all attacks, but it does make a program much more resistant.This process is called checking, validating, or filtering your data.One obvious question is, where should the checking be performed?
In nearly all secure programs, your first line of defense is to check every piece of data you receive.Thus, if you know that "/" is dangerous, look at your pattern to make sure it wouldn't let that character through.Of course, all of this begs the question: what are the legal values?You may know that allowing users to include "/" would be a bad idea, but just checking for this one character would probably be a mistake. Instead, check to make sure the input matches a certain pattern that you know is safe, and reject anything not matching the pattern.It's still a good idea to identify values you know are dangerous: you can use them to (mentally) check your validation routines.On the other hand, if you're too permissive, you may not find that out until after your program has been subverted.For example, let's say that you're going to create filenames based on certain inputs from a user. How about leading dashes (which can cause problems in poorly-written scripts)? In most cases, if you create a list of "illegal" characters, an attacker will find a way to exploit your program.For security it's best to be extremely conservative to start with, and allow just the data that you know is legal.After all, if you're too restrictive, users will quickly report that the program won't allow legitimate data to be entered.To indicate whether a particular input is valid, without any additional information as to means a field is invalid.In the future, if we decide we need to store the reason something was invalid, we can replace the true/false with a string containing an error message.The answer depends, in part, on the kind of data that you're expecting.So the next few sections will describe some common kinds of data that programs expect -- and what to do about them.Let's start with what would appear to be one of the easiest kinds of information to read -- numbers.