972322, 6:36 AM Input Vatdation “OWASP Cheat Sheet Series Input Validation Cheat Sheet Introduction This article is focused on providing clear, simple, actionable guidance for providing Input Validation security functionality in your applications. Goals of 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 deta. Input Validation shouldnot be used as the primary methad of preventing XSS, SQL Injection and other attacks which are covered in respective cheat sheets but can significantly contribute to reducing their impact if implemented properly. Input validation strategies Input validation should be applied on both syntactical and Semantic level. ‘Syntactic validation should enforce correct syntax of structured fields (e.g. SSN, date, currency symbol) ‘Semantic validation should enforce correctness of their values in the specific business context (eg. start date is before end date, price is within expected range). Itis always recommended to prevent attacks as early as possible in the processing of the user's (attackers) request. Input validation can be used to detect unauthorized input before it is processed by the application. Intps:ifcheatshectseries.owasp.orgicheatsheetsInput_Valdation_Cheat_Sheet.tm! 19972322, 6:36 AM Input Vatdation “OWASP Cheat Sheet Series Implementing input validation Input validation can be implemented using any programming technique that allows effective enforcement of syntactic and semantic comectness, for exemple: + Data type validators available natively in web application frameworks (such as Django Validators, Apache Commons Validators etc). + Validation against JSON Schema and XML Schema (XSO) for input in these formats. + Typeconversion (eg, Integer.parsetnt() in Java, int() in Python) with strict exception handing «Minimum and maximum value range check for numerical parameters and dates, minmum and maximum length check for strings. + Array of allowed values for small sets of string parameters (e.g. days of week). + Regular expressions for any other structured data cavering the whole input string (*.. .$) andnot using"any character’ wildcard (suchas . or \s) Allow list vs block list Itis a common mistake to use block lst validation in order totry to detect possibly dangerous characters and pattems lke the apostrophe * character thestring 1=1, or the "#example.org © user+subaddress#example.org ¢ usero[1Pv6:2081 :db8: 1] Intps:ifcheatshectseries.owasp.orgicheatsheetsInput_Valdation_Cheat_Sheet.tm! cr972322, 6:36 AM Input Vatdation “OWASP Cheat Sheet Series ©" "@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 restticted 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 any 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 nct contain dangerous characters (such as backticks, single or double quctes, or null bytes). ‘Exactly which characters are dangerous will depend on how the address is going tobe used (echoed in page inserted into database, ete). «The domain part contains only letters, numbers, hyphens (- ) and periods (.). + The email address is areasonable 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. ‘+ Theuser has access to the mailbox. The links that are sent to users to prove ownership should contain a token that is: + Atleast 32 characters long. Intps:ifcheatshectseries.owasp.orgicheatsheetsInput_Valdation_Cheat_Sheet.tm! 79972322, 6:36 AM Input Vatdation “OWASP Cheat Sheet Series ‘+ Generated using a secure source of randomness. + Single use. + Time limited (¢.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). Ifitis 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, ifthat exanple.org domain supports sub-addressing, then the following email addresses are equivalent: © userBexample.org * usertsitettexemple.org + user+sitezeexample.org Many mail providers (such as Microsoft Exchange) donct support sub-addressing. The most notable provider who does is Gmail although there are many others that alsodo. Some users will se a different tag for each website they register on, so that if they start receiving spam tocne of the sub-addresses they can identify which website leaked or sold their email Intps:ifcheatshectseries.owasp.orgicheatsheetsInput_Valdation_Cheat_Sheet.tm! 89972322, 6:36 AM Input Vatdation “OWASP Cheat Sheet Series address. Because it could allow users to register muftiple aocounts with a singleemail address, some sites may wish to block sub-addressing by stripping out everything betweenthe + 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 sellerail addresses. Additionally, it can be trivially bypassed by using disposable email addresses, or simply registering muttiple email accounts with a trusted provider Intps:ifcheatshectseries.owasp.orgicheatsheetsInput_Valdation_Cheat_Sheet.tm! 39