Input validation is one of the most critical parts of application with security perspective. Most of the common issues like SQL injection or XSS come into existence with not having proper validation at the input layer. We have seen there are several entry points to the application over HTTP and each of these entry points need proper validation before consuming the value into the business logic. By having strong input validation can help in reducing severe threats and protect logic as well.
An attacker tries to induce faults in the application by doing fuzzing on HTTP inputs and if validations are not in place then application breaks giving vital clue and information out. There are several different types of validations required and based on the validation application works. Here is a list of popular validations
1.) Size and length validation
2.) Data type validation
3.) Meta character validation
4.) File type validation
5.) Data ranges
2.) Data type validation
3.) Meta character validation
4.) File type validation
5.) Data ranges
HTTP protocol is all string and there are no bifurcations for type of data. Hence, it is up to developer to validate the content before consuming in the application. If at design level central validation control is not designed then developer would take input and process in the business logic. Not having right input validation can lead to logical bypass and several other issues and vulnerabilities get injected. Input validation is one of the most fundamental requirements for the application and it acts as first line of defense in the source code.
There is range of different possible injections which can help in disrupting the logic.
1.) SQL injection
2.) File system access injection
3.) Remote command execution
4.) XML poisoning
5.) Source code injection
6.) LDAP etc.
2.) File system access injection
3.) Remote command execution
4.) XML poisoning
5.) Source code injection
6.) LDAP etc.
Here are the characters which can cause this type of injections in the application if code is not validating it.
| Attack vector | Possible characters or string |
| XML poisoning | Recursive same pattern as part of attacks |
| Parameter tampering (Characters) | double quotes (“), single quote (‘), ampersand (&), percentage (%) |
| Parameter tampering (Data type) | Data type mismatch. |
| Parameter tampering (Abnormal values) | Large or negative value causing EOF/BOF |
| SQL injection | single quote (‘), double quotes (“), hyphen (-) , “or 1=1”. |
| XPATH injection | slash (/), double slash (//), dot(.), double dot (..), @, =, <, >, *, “’ or 1=1 or ”=’” as attack strings |
| LDAP injection | bracket (“(“) and * |
| Directory traversal and File system access | Dot dot slash (../), “../../../etc/passwd”, ../../../autoexec.bat. |
| Operating System command execution | Pipe (|) |
| Brute forcing | Multiple requests from the same IP address |
| Buffer overflow | Large-sized buffer injection. |
All above characters can help an attacker to bypass the logic and craft an exploit. Successful injection can be damaging for the application and an attacker can gain rights and access to confidential information to full system as well.
Solution to protect application
There are two broad approaches to protect application against this sort of attack vector.
1.) Applying validation across application – each parameter needs to be validated before consuming into application layer. Set of checks like length, data type, character filters etc. needs to be made before using inside the application. One needs to identify each and every entry point to the application and then apply secure coding across it.
2.) Another approach is putting a module in the application at HTTP layer for validation and it is also known as web application firewall. We are interested in filtering capabilities of it to protect our inputs. This has overhead to the application but getting some momentum in the industry in last few years.
One of the best approaches is to provide protection at the source code level itself so no dependent on any external checks and lock down.
For example here is a simple way of adding rule on .NET framework using built in form capability.
<%@ language="C#" %>
<form id="form1" runat="server"> <asp:TextBox ID="txtName" runat="server"/> <asp:Button ID="btnSubmit" runat="server" Text="Submit" /> <asp:RegularExpressionValidator ID="regexpName" runat="server" ErrorMessage="Valication failed." ControlToValidate="txtName" ValidationExpression="^[a-zA-Z'.\s]{1,40}$" /> </form>
Above code will compare against regular expression shown below.
^[a-zA-Z'.\s]{1,40}$
It will take values from a to z and A to Z with maximum length of 40. This way full protection can be applied to the parameter “txtName”.
Similar result can be achieved by applying at source code execution and code is shown below.
Regex reg = new Regex(@"^[a-zA-Z'.]{1,40}$"); Response.Write(reg.IsMatch(txtName.Text));
if (!Regex.IsMatch(txtName.Text, @"^[a-zA-Z'.]{1,40}$")) { // Validation failed }
Hence, there are various different ways validation can be achieved at application layer. Objective is not to allow certain values to the application layer.