Performing input validation means to check your input to be sure you can process it. The tricky part is that by validating it, you're already doing some minor processing, and that can create a hidden vulnerability.
The first step is usually to validate the length of the input. Most input will temporarily land in a finite buffer. Ensure that the amount of input you copy into the buffer doesn't exceed the length of the buffer - if there's too much input and not enough buffer, this can create a classic "buffer overflow" problem; exploiting these is a staple of hackers.
The next step is to ensure the data is in the format you expect. If you're expecting a number, ensure the bytes contain only digits and permitted number symbols, such as plus, minus, separator, decimal point, currency symbol, etc. Note that these are locale specific: in the US, a million dollars could be entered as
1,000,000.00, while in Germany a million Euros could be entered as
1.000.000,00. If you're expecting alphanumeric characters and numbers, use a "white-list" to accept only the characters you expect. It's safer to rely on a whitelist of good characters than a blacklist of bad characters; your blacklist may keep you safe with your configuration as of today, but let's say someone in the future replaces your database with a different database. It's possible one of the unexpected characters permits a SQL injection. Same is true with scripting and HTML.
Note that if you reverse these checks, and test for special characters before checking the input length, your validation code might be vulnerable to a buffer overflow. It's important to do them in the order that keeps you safest.
So the next step is to appropriately encode the input. For example, if you're going to accept
> and put the results on a web page, you'll probably want to make sure you're HTML encoding the symbols so you don't inadvertently create a hole where an attacker can plant a
<script>attack!</script> on the output page.
It's also advised to attempt to protect against SQL injections here (protect someone entering something bad like
' OR 1=1;DROP TABLE STUDENTS-- , but that's a double edged sword, because it doesn't fully guarantee protection. You might try to prevent this by putting in a validation check against accepting the apostrophe character. The next line of defense must be in the code that interfaces with SQL, and that code needs to be responsible for executing the queries safely (using Parameterized SQL queries, ORMs, or other defensive strategy.) You could pen-test your input against the above SQL injection attack, and not find a flaw because you only know about the one kind of injection attack. But let's assume the attacker figures out a new avenue of attack and tries using HTML encoding to get around your check, and it turns out you forgot to test and/or sanitize against that type of input. You could still be vulnerable unless you're careful with the SQL coding. This is a small example of how a defense in depth strategy can help keep you safe.