Input validation

Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from persisting in the database and triggering malfunction of various downstream components. Input validation should happen as early as possible in the data flow, preferably as soon as the data is received from the external party.

Data from all potentially untrusted sources should be subject to input validation, including not only Internet-facing web clients but also backend feeds over extranets, from suppliers, partners, vendors or regulators, each of which may be compromised on their own and start sending malformed data.

Input Validation should not be used as the primary method of preventing XSS, SQL Injection and other attacks. However, input validation can significantly contribute to reducing their impact if implemented properly.

Client-side vs Server-side Validation

Input validation shall be implemented on the server-side before any data is processed by an application’s functions, as any JavaScript-based input validation performed on the client-side can be circumvented by an attacker who disables JavaScript or uses a web proxy. Implementing both client-side JavaScript-based validation for UX and server-side validation for security is the recommended approach, leveraging each for their respective strengths.

File Upload Validation

Many websites allow users to upload files, such as a documents, images, and or more. This section helps provide that feature securely.

Upload Verification

• Use input validation to ensure the uploaded filename uses an expected extension type.
• Ensure the uploaded file is not larger than a defined maximum file size.
• If the website supports ZIP file upload, do a validation check before unzipping the file. The check includes the target path, level of compression, estimated unzip size.

Upload Storage

• Use a new filename to store the file on the OS. Do not use any user controlled text for this filename or for the temporary filename.
• When the file is uploaded to web, it’s suggested to rename the file on storage. For example, the uploaded filename is test.JPG, rename it to JAI1287uaisdjhf.JPG with a random filename. The purpose of doing it to prevent the risks of direct file access and ambiguous filename to evade the filter, such as test.jpg;.asp or /../../../../../test.jpg.
• Uploaded files should be analyzed for malicious content (anti-malware, static analysis, etc).
• The file path should not be able to specify by client-side. It’s decided by server-side.

Public Serving of Uploaded Content

• Ensure uploaded images are served with the correct content-type (e.g. image/jpeg, application/x-xpinstall)

Beware of Specific File Types

The upload feature should be using an allowlist approach to only allow specific file types and extensions. However, it is important to be aware of the following file types that, if allowed, could result in security vulnerabilities:

• crossdomain.xml / clientaccesspolicy.xml: allows cross-domain data loading in Flash, Java and Silverlight. If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks. Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named “crossdomain.xml” or “clientaccesspolicy.xml”.
• .htaccess and .htpasswd: Provides server configuration options on a per-directory basis, and should not be permitted.
• Web executable script files are suggested not to be allowed such as aspx, asp, css, swf, xhtml, rhtml, shtml, jsp, js, pl, php, cgi.

Image Upload Verification

• Use image rewriting libraries to verify the image is valid and to strip away extraneous content.
• Set the extension of the stored image to be a valid image extension based on the detected content type of the image from image processing (e.g. do not just trust the header from the upload).
• Ensure the detected content type of the image is within a list of defined image types (jpg, png, etc)

Email Address Validation

Syntactic Validation

The format of email addresses is defined by RFC 5321, and is far more complicated than most people realise. As an example, the following are all considered to be valid email addresses:

• "><script>alert(1);</script>"@example.org
• user+subaddress@example.org
• user@[IPv6:2001:db8::1]
• " "@example.org

Properly parsing email addresses for validity with regular expressions is very complicated, although there are a number of publicly available documents on regex.

The biggest caveat on this is that although the RFC defines a very flexible format for email addresses, most real world implementations (such as mail servers) use a far more restricted address format, meaning that they will reject addresses that are technically valid. Although they may be technically correct, these addresses are of little use if your application will not be able to actually send emails to them.

As such, the best way to validate email addresses is to perform some basic initial validation, and then pass the address to the mail server and catch the exception if it rejects it. This means that the application can be confident that its mail server can send emails to any addresses it accepts. The initial validation could be as simple as:

• The email address contains two parts, separated with an @ symbol.
• The email address does not contain dangerous characters (such as backticks, single or double quotes, or null bytes).
  • Exactly which characters are dangerous will depend on how the address is going to be used (echoed in page, inserted into database, etc).
• The domain part contains only letters, numbers, hyphens (-) and periods (.).
• The email address is a reasonable length:
  • The local part (before the @) should be no more than 63 characters.
  • The total length should be no more than 254 characters.

Semantic Validation

Semantic validation is about determining whether the email address is correct and legitimate. The most common way to do this is to send an email to the user, and require that they click a link in the email, or enter a code that has been sent to them. This provides a basic level of assurance that:

• The email address is correct.
• The application can successfully send emails to it.
• The user has access to the mailbox.

The links that are sent to users to prove ownership should contain a token that is:

• At least 32 characters long.
• Generated using a secure source of randomness.
• Single use.
• Time limited (e.g, expiring after eight hours). After validating the ownership of the email address, the user should then be required to authenticate on the application through the usual mechanism.

Disposable Email Addresses

In some cases, users may not want to give their real email address when registering on the application, and will instead provide a disposable email address. These are publicly available addresses that do not require the user to authenticate, and are typically used to reduce the amount of spam received by users’ primary email addresses.

Blocking disposable email addresses is almost impossible, as there are a large number of websites offering these services, with new domains being created every day. There are a number of publicly available lists and commercial lists of known disposable domains, but these will always be incomplete.

If these lists are used to block the use of disposable email addresses then the user should be presented with a message explaining why they are blocked (although they are likely to simply search for another disposable provider rather than giving their legitimate address).

If it is essential that disposable email addresses are blocked, then registrations should only be allowed from specifically-allowed email providers. However, if this includes public providers such as Google or Yahoo, users can simply register their own disposable address with them.

Sub-Addressing

Sub-addressing allows a user to specify a tag in the local part of the email address (before the @ sign), which will be ignored by the mail server. For example, if that example.org domain supports sub-addressing, then the following email addresses are equivalent:

• user@example.org
• user+site1@example.org
• user+site2@example.org

Many mail providers (such as Microsoft Exchange) do not support sub-addressing. The most notable provider who does is Gmail, although there are many others that also do.

Some users will use a different tag for each website they register on, so that if they start receiving spam to one of the sub-addresses they can identify which website leaked or sold their email address.

Because it could allow users to register multiple accounts with a single email address, some sites may wish to block sub-addressing by stripping out everything between the + and @ signs. This is not generally recommended, as it suggests that the website owner is either unaware of sub-addressing or wishes to prevent users from identifying them when they leak or sell email addresses. Additionally, it can be trivially bypassed by using disposable email addresses, or simply registering multiple email accounts with a trusted provider.