-
Notifications
You must be signed in to change notification settings - Fork 36
Input Handling
OWASP - A1:2017
SQL Injection is found in situations where an end user can submit data to the application residing on the server, which then uses this data to dynamically generate and execute SQL queries to a database (most commonly, via string concatenation). This will generally result in complete compromise of the data in the database, and can often result in compromise of the underlying operating system.
Test all parameters for the possibility of SQL Injection. If source code is available, audit all SQL queries for injectable parameters. For more information on this vulnerability, see PortSwigger's SQL injection article.
Like SQL injection, NoSQL injection occurs when NoSQL database queries are constructed using string concatenation. The impact is generally limited to data manipulation or information leakage in the scope of the affected query.
If the application uses a NoSQL database, test for injectable queries. For more information, see OWASP's article Testing for NoSQL Injection.
When an application uses shell commands to implement application functionality, it must guard against malicious input being provided to a command. If an attacker can provide unescaped input to a shell command, it is extremely likely they can abuse the functionality to execute a command of their choosing.
Thoroughly audit any application functionality that is implemented using shell commands for the possibility of user input being used in the command. For more information, see PortSwigger's OS command injection article.
Templating frameworks allow applications to automatically construct custom output by supplying data at runtime to a preformatted template. However, if user input is supplied to the framework and then evaluated (for example, when dynamically creating or modifying a template itself), code execution can occur.
If the application uses a third-party or custom templating framework, audit the application for any instances of template injection. See Server-Side Template Injection on the PortSwigger blog.
Client-side templating frameworks may also be vulnerable to template injection, leading to XSS; see Client-Side Template Injection on the PortSwigger Knowledge Base.
Audit the application for usage of unsafe functions (evaluation and deserialization). The specific vulnerable functions are language- and library- dependent.
Using static analysis tools can be highly helpful in this area by enumerating call sites for further auditing. The language-specific rulesets created for the Semgrep static analysis tool may provide a useful starting point. Some languages have free, security-focused static analysis tools such as Brakeman for Ruby and Bandit for Python.
Almost every programming language includes functionality to evaluate or execute an arbitrary string as source code at runtime. User input provided to these functions represents a direct path to arbitrary code execution.
OWASP – A8:2017
Many languages allow serializing and deserializing objects to a string. The object can then be stored or transmitted, and reconstituted later. In most cases, this includes the dynamic portions of the object, such as executable code. If user input is provided to an unsafe deserialization function, arbitrary code execution is likely to occur.
When handling file paths, metacharacters such as / and .. allow
traversal outside of the current directory. If an attacker can provide
unfiltered input to functions which perform file access, it is possible
to traverse outside of the default directory to access sensitive files
stored in system or application directories.
Audit the application's use of file handling functions to ensure potentially malicious input is not provided without appropriately blacklisting file metacharacters.
For any application functionality that allows users to upload files or otherwise causes files to be written, test that an attacker cannot control the filename in order to write files outside of the intended directory.
Generally, by overwriting application or system files, an attacker can leverage an arbitrary file write vulnerability to execute code on the server. Communicate with the application team before attempting to exploit this issue to overwrite files that may be necessary for the system or application to function.
Additionally, test file uploads using the EICAR test file to identify the presence of file scanning software. Using antivirus software increases the application's attack surface, but may help to meet regulatory requirements and reduce the likelihood that the application is used to host malicious content.
For application functionality that directly reads files off the filesystem, test that an attacker cannot specify an unintended file in order to read its contents. Attempt to read application source code, sensitive operating system files, infrastructure credentials, or dump user information.
Many languages allow dynamic evaluation of a chosen file (e.g. PHP's
require and include, Ruby on Rails' render). If user input is used to
construct the path provided to these functions, an attacker can cause an
unintended file to be executed, generally leading to code execution.
Audit the application for any instances of dynamic file inclusion.
If possible, review the filesystem permissions of the server on which the application is running. The application should run as a low-privileged user with read-only access to the application directory and read-write access to a dedicated upload directory.
If the application processes or converts uploaded files (for example, images) review the processing library for known vulnerabilities such as file-handling issues or denial of service.
Sandboxing file processing within a container with strict resource limits is strongly recommended.
OWASP – A4:2017
If the application processes XML input, an attacker can potentially add malicious elements that are processed insecurely by an improperly configured XML parser. While processing the document, the parser will attempt to resolve external references, which could take the form of a network request or a file on the local system.
Attempt to insert external entities or recursive entity references into any XML file processed by the application. For more information, see Exploitation: XML External Entity (XXE) Injection on the Depth Security Blog.
When opening a spreadsheet, many viewers (such as Excel on Windows, LibreOffice, and OpenOffice) will parse cells containing metacharacters as spreadsheet formulas. Applications that are vulnerable to formula injection allow untrusted user input to appear in a generated spreadsheet, triggering arbitrary command execution when the spreadsheet is opened.
If the application creates CSVs (or other spreadsheet formats) and
returns them to user, attempt to insert a cell with the content =cmd|' /C calc'!A0.
The following regular expression checks for dangerous characters when
applied to a cell's content: $[=+\-@].
When decompressing an archive file, a poorly configured library or routine may extract files to unexpected locations, or create special files such as symbolic links. If the application extracts compressed archives, test that file locations are strongly restricted and special files cannot be created.
Many decompression libraries do not perform any checking for files designed to explode in memory or storage size when extracted. Sandboxing file processing within a container with strict resource limits is strongly recommended. Communicate with the application team before attempting to exploit this issue to fill memory or storage, which may cause the application to crash.
If the application creates network requests, such as HTTP requests to other applications, verify that an attacker cannot control the destination of the request. An attacker who can cause the application to create arbitrary requests can use this functionality to attack other sites, including internal applications and infrastructure. For more information, see Server Side Request Forgery on the netsparker blog.
Verify that, wherever possible, input is validated using an allowlist of
acceptable values. For instance, a parameter for the current year can be
validated to accept only 4 consecutive digits using a regular
expression like ^\d\d\d\d$.
Check for the possibility of bypasses:
-
Regexes that lack anchors (^ and/or $) will match at any point in the string. For example, the regex
^example\.commatches example.com.attacker.com. -
Depending on the library, regex anchors may match a whole string or only up to a line break.
-
In some cases, null bytes can be used to drop a required suffix. For example, a regex for
\.php$might accept the input/etc/passwd\0.php, while the API used to retrieve the file does not read after the null byte.
If the application applies denylisting of certain characters or strings, check for the possibility of bypasses:
-
It may be possible to construct a malicious input without any banned characters if the denylist is not exhaustive. For example, XSS can be achieved in many situations with highly restricted character sets.
-
If processing such as unescaping is performed after the denylist, escaped characters may bypass the denylist.
When validating input, rejection of invalid inputs is recommended. If the application instead attempts to sanitize invalid inputs, verify that sanitization is effective and cannot be bypassed:
-
If the sanitization is applied in stages, a later stage may strip characters interspersed in an earlier banned phrase. For example, if
<script>and<iframe>are removed consecutively,<scr<iframe>ipt>will bypass the filter. -
If processing such as unescaping is performed after sanitization, escaped characters may bypass the sanitization.
Discuss with the client before attempting to validate issues that may cause excessive processing time or application outages. These types of issues include, but are not limited to:
- Unsafe regular expressions (OWASP)
- Server-side file handling
- Computationally-expensive functions without appropriate rate limiting
- Usage of business processes in unexpected ways to deny service to other users
Request smuggling occurs when a series of HTTP-aware backend servers (for example, nginx in front of an app) handle the Content-Length and Transfer-Encoding headers differently. In this case, it is possible to confuse the application server about where user requests start and end and inject malicious data into requests or responses for other users.
Use the HTTP Request Smuggler Burp plugin to test for mishandling of Content-Length / Transfer-Encoding headers.
If the application returns user input in HTTP headers, test if it is possible to inject new lines and content. If it is possible to target other users with this issue, attempt to inject two newlines to terminate the headers, then include an XSS payload to start the body.
Continue to Cryptography.