application_security/input_validation

168 notes in this subject, read out of this brain and free to use. This is page 3 of 3.

gRPC Protocol Buffer message validation with protoc-gen-validate

Use protoc-gen-validate to automatically validate Protocol Buffer messages. Import 'validate/validate.proto' in .proto files. Add validation rules like [(validate.rules).string.email = true] for email fields, [(validate.rules).string = {min_len: 1, max_len: 100}] for string length, and [(validate.rules).int32 = {gte: 0, lte: 150}] for integer range validation.

gRPC input validation requirement

Protocol Buffers provide type safety but not business logic validation. Always perform thorough server-side validation on all incoming messages.

gRPC allowlist validation for string inputs

Use allowlist validation for string inputs to prevent unexpected characters and injection attempts.

gRPC safe database query with parameterization in Go

Always validate user input before database operations (e.g., email format validation with isValidEmail()). Use parameterized queries with placeholders: query := "SELECT id, name, email FROM users WHERE email = ?"; row := db.QueryRow(query, email). This prevents SQL injection attacks.

Parameter entities enable file retrieval via URL references

Parameter entities allow for the retrieval of content using URL references in XML. An attacker can define a parameter entity with a SYSTEM reference to a local file and another parameter entity with a SYSTEM reference to a remote DTD. The remote DTD can then reference the file parameter entity and send its contents to an attacker-controlled server via a URL parameter. This technique is used when direct entity expansion fails to return file contents.

Malformed XML documents cause parser fatal errors and stop execution

If an XML document does not follow the W3C XML specification's definition of a well-formed document, it is considered malformed. When an XML parser detects that a document is malformed, it will detect a fatal error, stop execution, and the document should not undergo any additional processing. The application should display an error message.

Use W3C-compliant XML processors for malformed document handling

To deal with malformed documents, developers should use an XML processor that follows W3C specifications and does not take significant additional time to process malformed documents. Developers should only use well-formed documents, validate the contents of each element, and process only valid values within predefined boundaries.

Malformed XML documents may consume excessive CPU resources (DoS risk)

A malformed document may affect the consumption of Central Processing Unit (CPU) resources. In certain scenarios, the amount of time required to process malformed documents may be greater than that required for well-formed documents. An attacker may exploit an asymmetric resource consumption attack to take advantage of the greater processing time to cause a Denial of Service (DoS). To analyze the likelihood of this attack, analyze the time taken by a regular XML document versus the time taken by a malformed version of that same document, and consider how an attacker could use this vulnerability in conjunction with an XML flood attack using multiple documents to amplify the effect.

XML parser recovery mode may cause unexpected data integrity issues

Certain XML parsers have the ability to recover malformed documents by trying their best to return a valid tree with all the content that they can manage to parse, regardless of the document's noncompliance with specifications. Since there are no predefined rules for the recovery process, the approach and results from these parsers may not always be the same. Using malformed documents might lead to unexpected issues related to data integrity.

Deeply nested XML without closing tags causes stack overflow (coercive parsing)

A coercive attack in XML involves parsing deeply nested XML documents without their corresponding ending tags to make the victim use up and eventually deplete the machine's resources, causing a denial of service on the target. Reports of a DoS attack in Firefox 3.67 included the use of 30,000 open XML elements without their corresponding ending tags. Removing the closing tags simplified the attack since it requires only half of the size of a well-formed document to accomplish the same results. The number of tags being processed eventually caused a stack overflow.

Define strict XML schemas instead of DTD for validation

To avoid vulnerabilities from invalid XML documents, each XML document must have a precisely defined XML Schema (not DTD) with every piece of information properly restricted to avoid problems of improper data validation. Use a local copy or a known good repository instead of the schema reference supplied in the XML document. Perform an integrity check of the XML schema file being referenced, bearing in mind the possibility that the repository could be compromised. In cases where the XML documents are using remote schemas, configure servers to use only secure, encrypted communications to prevent attackers from eavesdropping on network traffic.

Attackers can inject additional XML tags without schema validation

If there is no control on the document's structure (no schema), the application could process different well-formed messages with unintended consequences. An attacker can inject additional tags to affect the behavior of the underlying application. For example, an attacker could close elements early and introduce bogus elements with attacker-controlled values, then add empty elements to keep the structure well-formed. If the application processes only the first values provided without performing any type of control on the structure, the attacker could achieve unintended behavior like purchasing an item at a manipulated price.

DTD has limited restrictions compared to XML Schema

DTD has a very limited set of possibilities compared to the type of restrictions that can be applied in XML documents using XML Schema. Certain schemas do not offer enough restrictions for the type of data that each element can receive, which could expose the application to undesired values within elements or attributes that would be easy to constrain when using other schema languages.

XML Schema enumeration constraint for allow-listed values

Certain types of values should only be restricted to specific sets (e.g., traffic lights have only three colors, only 12 months are available). This is the most perfect allow-list scenario for an application: only specific values will be accepted. Such a constraint is called enumeration in an XML schema. The XML schema element restriction uses enumeration with xs:enumeration value attributes to define each allowed value.

Use minLength and maxLength XML Schema constraints for string data

Whenever using an element or an attribute in locations where certain specific sizes matter (to avoid overflows or underflows), it would be logical to check whether the data length is considered valid. XML schemas can constrain a string using minLength and maxLength restrictions to avoid unusual scenarios. Alternatively, a length restriction can be used to specify a specific exact length that must be valid.

Use pattern constraints in XML Schema for format validation

When you want to ensure that data complies with a specific pattern, you can create a specific definition for it using pattern restrictions in XML schemas. For example, Social Security Numbers must use a specific set of characters, a specific length, and a specific pattern. The pattern attribute uses regular expressions to restrict allowed values.

Use assertion constraints in XML Schema to validate element relationships

Assertion components constrain the existence and values of related elements and attributes on XML schemas. An element or attribute will be considered valid with regard to an assertion only if the test evaluates to true without raising any error. The variable $value can be used to reference the contents of the value being analyzed. For example, assertions can ensure that a denominator is not zero, which would prevent division by zero errors.

Use positiveInteger for quantities to prevent negative value attacks

XML Schema numeric data types can include different ranges of numbers (negativeInteger, nonNegativeInteger, positiveInteger, nonPositiveInteger). When defining a quantity element that will be used in calculations like price * quantity, using positiveInteger instead of integer prevents an attacker from providing a negative number that could result in a negative price on the user's account. This prevents logical vulnerabilities where attackers could exploit negative quantities.

Avoid using float and double data types for monetary values

The data types float and double contain real numbers and special values like -Infinity, NaN, and +Infinity. If these special values are not required and only real numbers are expected, the data type decimal is recommended. Not considering the whole spectrum of possible values for a data type could make underlying applications fail. If special values Infinity and NaN are not required for monetary values like prices, use decimal instead of float or double.

Use positiveInteger for denominators to prevent divide-by-zero

Whenever using user-controlled values as denominators in a division, developers should avoid allowing the number zero. In XSLT, using zero as a divisor triggers the error FOAR0001. Other applications may throw other exceptions and the program may crash. XML Schema positiveInteger data type (positive numbers only, excluding zero) can be used for denominator elements to prevent zero values from being valid. Alternatively, an assertion constraint can be used to disallow zero explicitly.

minOccurs and maxOccurs XML Schema attributes control element repetition

The minOccurs and maxOccurs attributes specify minimum and maximum limits for element occurrences in XML Schema. The default value for both attributes is 1. If a value is optional, it could contain minOccurs of 0. If there is no limit on the maximum amount, it could contain maxOccurs of unbounded. Applications using unbounded occurrences should test what happens when they receive an extremely large amount of elements to be processed. Since computational resources are limited, the consequences should be analyzed and eventually a maximum number ought to be used instead of an unbounded value to prevent denial of service.

Jumbo payload depth attack uses many deeply nested elements

A depth attack is a primary method to make an XML document larger than normal by using a huge number of elements, element names, and/or element values. In most cases, the overall result will be a huge document. This type of attack can be combined with other XML entity expansion attacks.

Jumbo payload width attack uses many attributes

A width attack is a primary method to make an XML document larger than normal by using a huge number of attributes, attribute names, and/or attribute values. In most cases, the overall result will be a huge document that consumes processing resources.

Small jumbo payloads with entity expansion bypass size-based filters

An attacker can create very small XML documents that produce results similar to processing traditional jumbo payloads through entity expansion. For example, a small document can reference a remote huge.xml file through a DOCTYPE SYSTEM entity definition. The purpose of such a small payload is that it allows an attacker to send many documents fast enough to make the application consume most or all of the available resources.

Schema poisoning occurs when attackers modify schema files

When an attacker is capable of introducing modifications to a schema, there could be multiple high-risk consequences. The effect of these consequences will be more dangerous if the schemas are using DTD (e.g., file retrieval, denial of service). An attacker could exploit this type of vulnerability in numerous scenarios depending on the location of the schema.

Embedded XML schemas can be manipulated by attackers

The most trivial type of schema poisoning takes place when the schema is defined within the same XML document. All restrictions on elements defined in an embedded DTD could be removed or altered, allowing the sending of any type of data to the server. Furthermore, if the server is processing external entities, the attacker could use the schema to read remote files from the server. Attacks through embedded schemas are commonly used to exploit external entity expansions. Embedded XML schemas can also assist in port scans of internal hosts or brute force attacks.

Schema file permissions must restrict write access

Local schema files must have correct permissions to prevent unauthorized modifications. If the local schema does not contain the correct permissions, an internal attacker could alter the original restrictions. Schema files should have permissions that allow only authorized users to make modifications (not world-writable or group-writable).

HTTP schema references are vulnerable to man-in-the-middle attacks

When XML documents reference remote schemas using the unencrypted Hypertext Transfer Protocol (HTTP), the communication is performed in plain text and an attacker could easily tamper with traffic. When documents reference remote schemas using HTTP connection, the connection could be sniffed and modified before reaching the end user. Remote schema files should be referenced using encrypted protocols like HTTPS instead.

DNS cache poisoning can redirect schema references to attacker-controlled servers

Remote schema poisoning may be possible even when using encrypted protocols like HTTPS. When software performs reverse Domain Name System (DNS) resolution on an IP address to obtain the hostname, it may not properly ensure that the IP address is truly associated with the hostname. If an attacker compromises the DNS being used, a hostname could now point to an IP controlled by the attacker. When accessing the remote file, the victim may actually be retrieving the contents of a location controlled by an attacker.

Malicious employees can poison schemas hosted by third parties

When third parties host and define schemas, the contents are not under the control of the schemas' users. Any modifications introduced by a malicious employee or an external attacker in control of these files could impact all users processing the schemas. Subsequently, attackers could affect the confidentiality, integrity, or availability of other services, especially if the schema in use is DTD.

XXE attacks use DTD entity declarations to read files

If the parser uses a DTD, an attacker might inject data that may adversely affect the XML parser during document processing. Using the DTD capabilities of referencing local or remote files it is possible to affect file confidentiality. In addition, it is also possible to affect the availability of the resources if no proper restrictions have been set for the entities expansion. XXE attacks can be used to read local files like /etc/passwd by declaring entities with SYSTEM references to local file paths.

Recursive entity references create circular entity definitions

When the definition of an element A is another element B, and that element B is defined as element A, that schema describes a circular reference between elements. This type of recursive entity reference can cause parser issues.

Quadratic blowup attack with large entity references

Instead of defining multiple small, deeply nested entities, an attacker in this scenario defines one very large entity and refers to it as many times as possible, resulting in a quadratic expansion (O(n^2)). For example, defining a 100,000 character entity and referencing it 100,000 times results in 100,000 x 100,000 characters in memory, consuming all available resources.

Billion Laughs attack exploits exponential entity expansion

The Billion Laughs attack occurs when an XML parser tries to resolve external entities included in a DTD schema with exponentially expanding entity definitions. Each entity level references the previous level multiple times, causing exponential memory consumption. For example, LOL references itself 10 times, LOL1 references LOL 10 times, LOL2 references LOL1 10 times, and so on for 9 levels, resulting in 3 x 10^9 (3 billion) entity expansions. When the parser expands LOL9, it will cause the application to consume all available memory until the process crashes.

SOAP specification forbids DTD usage

The Simple Object Access Protocol (SOAP) specification forbids DTDs completely. This means that a SOAP processor can reject any SOAP message that contains a DTD. Despite this specification, certain SOAP implementations did parse DTD schemas within SOAP messages, allowing attackers to exploit entity expansion vulnerabilities in SOAP messages that technically violate the SOAP specification.

Reflected file retrieval via XXE in XML responses

When an XXE vulnerability exists, an attacker can define entities with SYSTEM references to local files. If the parser allows references to external entities, it might include the contents of that file in the XML response or in the error output. For example, defining an entity xxe with SYSTEM "/etc/passwd" and then referencing it in the XML will cause the file contents to be expanded and potentially reflected back to the attacker.

Server-side request forgery (SSRF) via XXE

Server Side Request Forgery (SSRF) happens when the server receives a malicious XML schema, which makes the server retrieve remote resources such as a file via HTTP/HTTPS/FTP, etc. SSRF has been used to retrieve remote files, to prove a XXE when you cannot reflect back the file, perform port scanning, or perform brute force attacks on internal networks.

External DNS resolution as SSRF proof of concept

Sometimes it is possible to induce the application to perform server-side DNS lookups of arbitrary domain names through XXE. This is one of the simplest forms of SSRF, but requires the attacker to analyze the DNS traffic. An example uses a DOCTYPE PUBLIC declaration with a suspicious domain name in the system identifier, forcing the parser to perform DNS resolution on that domain.

XML port scanning via error-based responses

If you are unable to see the response from the remote server, you may be able to use the information generated by the error response to determine port status. For example, a web service may leak details on what went wrong in error messages when trying to establish a connection (e.g., "Server returned HTTP response code: 401 for URL: http://192.168.1.1:80"). These error messages can reveal whether a port is open or closed on internal systems.

XML port scanning via timeout-based responses

The scanner could generate timeouts when it connects to open or closed ports depending on the schema and underlying implementation. If timeouts occur while trying to connect to a closed port (which may take one minute), the time of response when connected to a valid port will be very quick (one second, for example). The differences between open and closed ports becomes quite clear through timing analysis.

XML port scanning via time-based analysis

Sometimes it may be difficult to tell the differences between closed and open ports because the results are very subtle. The only way to know the status of a port with certainty would be to take multiple measurements of the time required to reach each host, then analyze the average time for each port to determine the status of each port. This type of attack will be difficult to accomplish if it is performed in higher latency networks.

XML brute forcing via XXE with embedded credentials

Once an attacker confirms that it is possible to perform a port scan via XXE, performing a brute force attack is a matter of embedding the username and password as part of the URI scheme (http, ftp, etc). For example, an attacker can define an entity with SYSTEM "http://username:password@example.com:8080" to attempt authentication with different credential combinations against services discovered via XXE port scanning.

XXE vulnerable Java code using StAX parser

Java applications using XMLInputFactory (StAX parser) without disabling external entity processing are vulnerable to XXE attacks. The code creates an XMLStreamReader and iterates through XML events, outputting text content. If a malicious DTD defines an entity that references a local file like /etc/passwd, the file contents will be expanded and output through the stream events.

Normalize CDATA sections may alter content interpretation

Certain XML parsers may consider normalizing the contents of CDATA sections. This means that they will update the special characters contained in the CDATA section to contain the safe versions of these characters even though normalization is not required by specification. For example, libxml could transform a CDATA section containing "<script>a=1;</script>" into "<script>a=1;</script>". Although well-formed, its contents may be considered malformed or change intended meaning depending on the situation.

Sec-Fetch-Dest header for resource isolation

The Sec-Fetch-Dest header is automatically included by the browser and specifies the end goal of a request. It is part of the Fetch Metadata standard. Example: if Sec-Fetch-Dest equals 'iframe', the resource is being loaded into an iframe. You can use this to build resource isolation policies, such as returning a 403 status code for requests with Sec-Fetch-Dest: iframe to prevent embedding. Check browser support at https://caniuse.com/?search=sec-fetch before using, and implement appropriate fallback handling if the header is not present.

Cache timing defense: unpredictable tokens for resources

Protect resources from cache timing attacks by using unpredictable tokens in the URL, for example: /avatars/admin.svg?token=be9••••••03. Tokens should be unique per user and random. Since an attacker cannot guess the token, they cannot detect whether the resource was loaded from cache.

XXE vulnerabilities in Java XML parsers (DOM, DOM4J, SAX)

Java applications are vulnerable to XXE (XML External Entity) attacks when using XML parsers without disabling external entity processing. This affects multiple parser types: 1. **DOM Parser (DocumentBuilderFactory/DocumentBuilder)**: Parses XML documents and expands entities defined in DTD declarations. Malicious DTDs can reference local files like /etc/passwd, causing file contents to be expanded and accessible through the parsed document. 2. **DOM4J Parser (SAXReader)**: Parses XML documents using SAXReader and outputs the parsed result. When external entity processing is enabled, malicious DTDs can reference local files like /etc/passwd, causing file contents to be expanded and included in the output. 3. **SAX Parser (SAXParserFactory with DefaultHandler)**: Parses XML documents using SAXParserFactory and a DefaultHandler to process character events. Malicious DTDs can reference local files like /etc/passwd, causing file contents to be expanded and output through the character handler. In all cases, the vulnerability occurs when applications fail to disable external entity processing. An attacker can craft a malicious DTD that references sensitive files, and the expanded entity content becomes accessible to the application and potentially to the attacker.

XML DoS protection against oversized and recursive payloads

Validation against oversized payloads and recursive payloads is required to protect against XML Denial of Service attacks.

Give your agent this brain