Processing User Input (input validation and sanitisation)¶
Processing user input should always be done with care and thought behind what the application is expecting to receive from a user request, and what the application actually receives. Validation should always attempt to only accept parameters and values that look exactly as expected and reject or drop anything else.
| # | Description | ASVS |
|---|---|---|
| IV1.0.1 | Validate input using positive validation in that the application accepts input that it expects and rejects anything else. Positive validation should include strong typing for structured data validating against a defined schema including the allowed characters, length, and pattern | 5.1 |
| IV1.0.2 | Sanitise all input the application receives, no matter the source. Use a well-maintained library or framework to sanitise your input, rather than custom code. | 5.2 |
| IV1.0.3 | Accept only parameters that are known to the application. | 5.1 |
| IV1.0.4 | Use HTTP security headers as a defence in depth method to protect against client side attacks | 14.4 |
| IV1.0.5 | Make distinctions about the source of a request parameter by only processing a parameter if it is sent via the method the application expects (GET parameters, POST parameters, cookies, HTTP headers). | 5.1 |
| IV1.0.6 | Verify that output encoding and the processing of sensitive systems is context-aware, such as ensuring that: - SQL and Operating System commands are parameterised where possible - LDAP queries are protected from injection attacks - file inclusion attacks are not possible - any other injection attempt is accounted for Only allow the backend system to process the actions mentioned and ensure that any parameter that is sent to a function for processing is sanitised, validated, and trusted. |
5.3 |
| IV1.0.7 | Verify that XML external entity processing is turned off on XML parsers and that an application accepting XML input rejects XML containing external entity processing. | 5.5 |
| IV1.0.8 | Ensure memory safe parameters and functions are used to prevent overflow attacks. | 5.4 |
| IV1.0.9 | Validate that SSRF attacks are prevented via sanitisation and validation of data and input fields, specifically relating to URLs, protocols, domains, paths and ports. If this data is required for the field, ensure that there is an allow list of domains, ports, paths and protocols. | 5.2 |
| IV1.0.10 | Where possible, ensure that SQL queries are made using an ORM or entity framework to ease development and utilise security protections against injection attacks (such as parameterised queries). | 5.3 |