From the course: Programming Foundations: Secure Coding

Input validation

From the course: Programming Foundations: Secure Coding

Start my 1-month free trial Buy for my team

Input validation

“

- One of the most repetitive security issue groupings we find in software development today is various input validation bugs. While input validation exists in many different contexts, we're going to focus on the client's 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're talking about SQL injection, but there are several other types. In fact, any code that relies on an interpreter for execution can be subject to an injection attack. The concept is rather simple. A structured statement is created that anticipates user input to complete the statement before it is then run through an interpreter. For example, in SQL, we could write a statement that is something like select * FROM users WHERE username = "some value". Now at runtime, the software takes user input and simply concatenates 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 vector based on lack of proper input validation. The most common and continually on the OWASP Top 10 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, which is then rendered in the client browser and the exploit is executed. Often these scripts send data back to the attacker server. What I've just described is called a persistent cross-site scripting attack. However, there are a couple others. Reflected cross-site scripting is often used in phishing attacks where the malicious script actually originates in the request itself. There are also exploits in the document object model or DOM that can be triggered, but we won't go deeper than to just say that they exist. 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 deny listing. Deny lists look for key patterns like script tags to filter out the input. Deny listing 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 called allow listing, which is much more effective than deny listing. Allow listing looks at the pattern that the data should have, such as length or symbols, and requires that the input matches that pattern before it's ever accepted. For instance, an email address must contain the @ 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 as well. It's important to note that some of these attack vectors can be mitigated in lower levels of the system, specifically SQL and associated injection attacks. More on that later, but it's a great time to discuss that security in layers is always the most effective approach.

Contents