OWASP Top 10: Input Validation Vulnerabilities and Mitigations
This post is focused on providing software developers with clear, simple, actionable guidance for offering input validation security functionality in your software applications.
Table of contents:
- What is input validation in web application security?
- The consequences of improper input validation
- How to ensure proper input validation
- HTML5 validation features
- Types of input validation
- Whitelist input validation and other input security checks
- Input validation against cross site scripting XSS
- Which OWASP Top ten item relates to validating data input?
- What is the OWASP standard?
- Benefits of security validation
What is input validation in web application security?
Input validation, also known as data validation, is the proper testing of any input supplied by a user or application. Input validation prevents improperly formed data from entering an information system. Because it is hard to detect a malicious code user trying to attack your software, applications should check and validate all input entered into a system. Input validation should occur when data is received from an external party, especially if the data is from untrusted sources. An input validation mistake can cause injection attacks, compromised systems, exposure of sensitive information and information leakage. While input validation can be either blacklisted or whitelisted, it is preferable to whitelist data with acceptable inputs. Whitelisting only passes expected data. Contrarily, blacklisting depends on programmers predicting all unexpected data. As a result, programs make mistakes more easily with blacklisting.
Input validation can be adopted using any programming technique that effectively enforces syntactic validation or semantic validation. Syntactic validation checks the type of input/incoming type, content type and lengths, while semantic validation ensures supplied values are sensible in the application context. So if you are entering an email address, syntactic validation would mean checking the syntax (i.e. structure and characters) to ensure that it is a valid email. In contrast, semantic validation might enable (or exclude) only email addresses from specific domains.
What is an input validation attack?
An input validation attack happens when an attacker deliberately enters malicious input, such as a dangerous character, intending to confuse an application and cause it to carry out some unplanned action. Malicious content can damage code, commands, and scripts which are not validated correctly and can be deployed to exploit vulnerabilities. Unchecked input is the main ground of some of the most common types of attacks, including SQL injection, XSS attacks and Buffer Overflow and process control vulnerabilities all stem from incomplete or absent input validation. The OWASP top ten mentions input validation as a mitigation strategy for XSS and SQL injection. Still, it should not be deployed as the primary method of preventing these attacks; even if adequately adopted, it can considerably lower their effect.
The consequences of improper input validation
When reading about web vulnerabilities in this post, you may have realized that many posts have a similar ending: “To mitigate this vulnerability, ensure you carefully validate all user inputs”, even though it is hard to validate rich content submitted by a user. By preventing malicious users from freely entering attacks strings, you can lower your exposure to many injection attacks, including:
- Code injection (RCE)
- SQL injection
- OS command injection
- Cross-site scripting (XSS)
If you look at the CWE-20: Improper validation definition, you will notice that this weakness can precede many others and cause all sorts of application security issues. Some cases of improper data validation include duplicate validation forms, unused validation form, validation forms fields without a validator if the form does not extend the validation class, and unvalidated action forms.
Whereas input validation alone can never prevent all attacks, it can lower the attack surface and reduce the impact of any attacks that do succeed. In addition to its security implications, data validation is also vital for software usability, stability, and performance. When processing invalid data, an application fails to load, return incorrect results, or even crashes the web servers.
Insufficient or lack of validation can also degrade the user experience on other levels. For instance, if a registration page fails to detect an incorrect phone number or email, the user may not be able to confirm their account. If invalid information passes validation in the browser and is only caught during server-side validation, users might experience longer load times or errors.
Be especially careful when validating all input when invoking code that crosses language boundaries, like from an interpreted language to native code. This can create an unexpected interaction between the language boundaries.
How to ensure proper input validation
Validating form fields and other inputs are often done by deploying JavaScript manually or deploying a dedicated library. Adopting validation is a tedious and error-prone process, so you should always explore and deploy existing validation features and functionalities before going the DIY route to building custom validation. Most frameworks and languages have built-in validators that simplify form validation and are more dependable. For input data that should match a certain XML or JSON schema, you should validate inputs against that schema, especially when making API calls where errors can be challenging to troubleshoot.
HTML5 validation features
The HTML5 spec comprises built-in form validation features that allow you to specify validation constraints directly in HTML. These include input field attributes like required to indicate a required field, type to specify the data, filename, max length to define a maximum length limit, and pattern to specify a regex pattern for valid values. Additionally, the spec defines CSS pseudo-classes like invalid: and valid, so you can easily apply different styles based on the validation result.
Built-in form validation features in HTML5 are great to get started with data validation. With just a few additional attributes in standard HTML elements, you get basic data type and content validation with cross-platform support to save a lot of work and provide a native user experience.
Types of Input Validation
There are two principal types of input validation:
Client-side validation
Through forms, users communicate with a digital platform (desktop, web, or mobile). To register on a platform, search, or login, one has to request information from a platform or send data to a platform deploying forms. Regardless of how stylish the interface is, it is still a form.
Client-side validation entails monitoring what you type to ensure that it obeys set guidelines and obtains users’ anticipated format or type of data. Code is written to ensure users do not deviate from what is anticipated while making requests or interacting with a digital platform called client-side validation.
While front-end code manages client-side input validation, back-end code handles server-side input validations. Client-side validation is part of the front-end secure code requirements that exist on the front end. It responds faster to the user’s input and lowers the latency that would exist if one only deployed server-side data validation. Note that client-side validation by itself is not enough to validate data properly as it can be surmounted. Still, validation of all untrusted user input can be a powerful approach for making vulnerable code hard to exploit because it limits what an attacker can input. Additionally, server-side checks support intrusion detection.
Server-side validation
A web server carries out this type of validation after the input has been sent to the server. After the validation process on the server side is over, the feedback is sent back to the client by generating dynamic or new web pages. Because of the high risk of malicious users managing to bypass client-side validation, server-side validation remains a vital second step in any web security process.
It is worth noting that these are not alternative solutions but rather complementary measures. Indeed, any list of form validation best practices will recommend adopting both types of validation. The languages such as ASP.Net and PHP use server-side validation
White list input validation and other input security checks
Regardless of whether your validation check happens on the server sides or client, there are two major input validation techniques:
- Blacklisting
- Whitelisting
Blacklisting
Blacklist validation involves rejecting input known to be bad. Instead of letting in data you like, you are more focused on keeping out data you do not.
Whitelisting
Whitelist validation entails only accepting input known to be good. Generally, this allows only specific file types and extensions to be uploaded. This indicates the input compiles with your anticipated format standards (data type, range, size and length). You run validation checks along with specific criteria, and the input that meets those criteria gets whitelisted. If you are expecting a handful of values, you can use regular expressions to explicitly whitelist them.
Input validation against cross site scripting (XSS)
Encoding is possibly the most important line of XSS defense; however, it is not sufficient to prevent XSS security vulnerabilities in every context. You should validate all inputs as strictly as possible at the point when it is first received from a user.
Examples of input validation include:
- Validating that input comprises only an expected set of special characters.
- If a user supplies a value, it is expected to be numeric, validating that the value actually contains an integer.
- When a user submits a URL that will be returned in responses, validating that it begins with a safe protocol like HTTPS and HTTP, or else, someone might exploit your site with a harmful protocol such as javascript or data.
Input validation should optimally work by blocking invalid input. An alternative approach to cleaning invalid input to make it valid is more error-prone and should be avoided. You can also use HTTP headers to prevent crosssite scripting.
Which OWASP Top ten item relates to validating data input?
Today, numerous vulnerabilities are present in web applications. Vulnerability classification is done by different companies such as Microsoft and OWASP based on their risk rating according to impact, detectability, and prevalence. Classification according to OWASP top ten application security risks that relate to validating data input include:
SQL injections
SQL injection attacks happen when untrusted data is sent to a code interpreter through a form input or other data submission to a web application. For instance, an attacker could enter SQL database code into a form that expects a plaintext username. If that form of input is improperly secured, it could result in that SQL code being executed. This is called an SQL injection attack.
Different injection flaws are OS, SQL and LDAP injection. They occur because of poor input validations.
An injection vulnerability/attack can be prevented by validating and sanitizing user-submitted data. (Sanitation refers to cleaning up the suspicious-looking parts of data, while validation means rejecting suspicious-looking data). Additionally, a database admin can set controls to reduce the amount of information an injection attack can expose. You can prevent SQL injections by separating data from the web application logic.
Missing function level access control
You can find this security vulnerability in web applications that have user-specific control. An application can have three types of users generally:
- Admin users
- Normal users (logged in but have minimum privileges and functions)
- Anonymous users (users without logging in)
Each of these types of users has access to different data, functions, and features. Broken access control weakness exists when a flaw in applications’ logic would enable one type of user to get access to some other type of user.
One simple example of broken access control is when applications use different URLs for different features and do not authenticate users.
You can prevent broken access control risks starting with:
- Implement rate limits
- Remove unnecessary users and services
- Use access control lists and role-based authentication
- Use multi-factor authentication for high valued accounts
Broken authentication and session management
Application functions linked to authentication and session management are often not adopted correctly, allowing attackers or a security researcher to compromise passwords, keys or session tokens or exploit other implementation flaws to assume other users’ identities. They occur by putting session ID in the URL; the application’s timeouts are not set properly.
Insecure deserialization
According to Open Web Application Security Project (OWASP) Top 10, this security risk was added by an industry survey and not based on quantifiable data research.
Insecure deserialization occurs when a software developer exposes a reference to an internal adoption object like a database key, directory, or file. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
How to prevent insecure deserialization:
- Adopting integrity checks such as digital signatures on any serialized objects prevents hostile object creation or data tampering.
- Enforcing strict type constraints during deserialization before object creation since the code generally expects a definable set of classes
- Isolating code that deserializes in low privilege environments when possible
Other Top ten items relate to validating data input include:
- Sensitive Data Exposure.
- XML External Entities (XEE)
- Security Misconfiguration
- Insufficient logging and monitoring
Unexpected user input (Mass assignment)
Some frameworks support the automatic binding of HTTP request parameters to server-side objects deployed by the application.
This auto-binding feature can allow a security researcher to update server-side objects that were not meant to be modified. The attacker can probably modify their access control or circumvent the intended business logic of the application with this feature.
This attack has several names: object injection, auto binding, and mass assignment.
For example, if the user object has a field privilege that specifies the user’s privilege level in the application, a malicious user can look for pages where user data is modified and add privilege (equal) admin to the HTTP parameters sent. If auto-binding is enabled in an insecure fashion, the server-side object representing the user will be modified accordingly.
Two security mechanisms can be deployed to manage this:
- Avoid binding input directly and use Data Transfer Objects (DTOs) instead.
- Allow auto-binding but set up allowlist rules for every feature page to define which fields are allowed to be auto-bound. Please note that allow listing is the recommended minimal approach when building secure software.
What is the OWASP standard?
The OWASP ASVS Application Security Verification Standard Project offers a basis for testing web application technical security controls and provides application developers with a list of requirements for secure development. This standard can be deployed to establish a level of confidence in the security of web applications and validate shared security solutions. Additionally, there is the OWASP ProActive Controls, a document that is prepared for developers who are developing software.
Benefits of security validation
Continuously validate and measure the success of your cybersecurity controls and gain confidence in your preparedness to withstand the attackers targeting your company with open source solutions. Security validation helps you get the latest threat intelligence on threat actor TTP and automates a testing program that provides you with real data on how your security controls are performing, optimizing your environment and making the right investments in the future.
| Reduce risk | Security is of paramount concern when managing internet resources that collect user data. It can help prevent lawsuits and protect the integrity of the company that owns the platform. |
| Error prevention | Input validation does a lot to avert errors from happening. It lowers how a user can do something wrong on a digital platform, ensuring that the software performs much faster. |
| Better user experience | A major source of frustration for business users is getting an input error when trying to request a digital platform. These can be mitigated by validating inputs so that users can send inputs in an acceptable format and are warned when they violate the guidelines. |
Final thoughts: Input validation cheat sheet
Input validations are rather simple to set up. Nonetheless, the impact of these validations cannot be stressed. The upshot for a platform without input validation can be far-reaching if compromised. Generally, understanding what validation parameters are needed for a certain input is vital to ensuring proper validation is done. The use-case of most validation parameters has to be adequately understood as it will aid proper input validation both on the server-side and the client-side.
