Input validation issues

- One of the most repetitive security issues we find in software development today is input validation bugs. With input validation issues exist in many different contexts. We are going to focus on the client server input validation issues and how to possibly address them. Let's get started by talking about the attack vectors at play. Injection attacks are one of the most common and most publicized exploits, not just in the input validation arena but globally. Often when we think about injection attacks we are talking about SQL injection. But there are several other types. In fact, anything that is interpreted can be subject to an injection attack. The concept is rather simple. A structured statement is created, then anticipates user input to complete that statement before it is run through an interpreter. For example, in SQL we could write a statement that is something like SELECT star from users WHERE username equals some value. Now at run time we take user input and simply concatenate the statement before execution. If an attacker can find this scenario, they can provide input that not only completes this statement, but also executes a new statement by simply adding a semicolon. This provides the attacker more information about the system than the developer ever intended. Scripting attacks are another very common attack based on lack of proper input validation. The most common, and continually on the OWASP Top Ten, is cross-site scripting, or XSS attacks. The concept again is rather simple. The attacker injects a script through a user input field or some other post or put method. That script is then served to a victim through his or her browser. The script is then rendered in the client browser of the victim and the exploit is executed. Often these scripts send data of some kind back to the attacker's server. So what I just described is called a persistent cross-site scripting attack. However, there are a couple other types. Reflected cross-site scripting is often used in phishing attacks, where the malicious script actually originates in the request. There are also exploits in the dom that can be attacked. All of these exploits are based on lack of input validation. While these attacks can be nasty, the fixes for them are relatively straightforward. One approach is to require validation of all user input. One such validation technique is called blacklisting. Blacklists look for key patterns like script tags and filter the input out. Blacklisting is often one of the first attempts, but they tend to be easy to circumvent and should not be used alone. Another validation technique is whitelisting. And it's much more effective than blacklisting. Whitelisting looks at the pattern that the data should have, such as length or symbols, and requires that the data matches that pattern before it's ever accepted. For instance, an email address must contain the at symbol and end with a dot and a valid top-level domain. In either case, the validation should always be applied server side and be the first thing executed. Now you can apply validations client side to save the server call, but it still must be executed server side. The reason is that you could always post back to the server without the actual webpage. So never rely only on client side input validation.