Kingdom: Input Validation and Representation

Input validation and representation problems ares caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input. The issues include: "Buffer Overflows," "Cross-Site Scripting" attacks, "SQL Injection," and many others.

Cross-Site Scripting: Content Sniffing

Java/JSP
Python

Abstract

Sending unvalidated data to a web browser may result in certain browsers executing malicious code.

Explanation

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.

2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but may also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

For the browser to render the response as HTML, or other document that may execute scripts, it has to specify a text/html MIME type. Therefore, XSS is only possible if the response uses this MIME type or any other that also forces the browser to render the response as HTML or other document that may execute scripts such as SVG images (image/svg+xml), XML documents (application/xml), etc.

Most modern browsers do not render HTML or execute scripts when provided a response with MIME types such as application/octet-stream. However, some browsers such as Internet Explorer perform what is known as Content Sniffing. Content Sniffing involves ignoring the provided MIME type and attempting to infer the correct MIME type by the contents of the response.
It is worth noting however, a MIME type of text/html is only one such MIME type that may lead to XSS vulnerabilities. Other documents that may execute scripts such as SVG images (image/svg+xml), XML documents (application/xml), as well as others may lead to XSS vulnerabilities regardless of whether the browser performs Content Sniffing.

Therefore, a response such as <html><body><script>alert(1)</script></body></html>, could be rendered as HTML even if its content-type header is set to application/octet-stream, multipart-mixed, and so on.

Example 1: The following JAX-RS method reflects user data in an application/octet-stream response.


@RestController
public class SomeResource {
    @RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
    public String response5(@RequestParam(value="name") String name){
        return name;
    }
}

If an attacker sends a request with the name parameter set to <html><body><script>alert(1)</script></body></html>, the server will produce the following response:


HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed

<html><body><script>alert(1)</script></body></html>

Even though, the response clearly states that it should be treated as a JSON document, an old browser may still try to render it as an HTML document, making it vulnerable to a Cross-Site Scripting attack.

References

[1] X-Content-Type-Options Mozilla

[2] MIME Type Detection in Windows Internet Explorer Microsoft

[3] Understanding Malicious Content Mitigation for Web Developers CERT

[4] HTML 4.01 Specification W3

[5] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System

[6] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications

[7] INJECT-3: XML and HTML generation requires care Oracle

[8] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692

[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079

[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079

[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079

[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079

[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079

[14] Standards Mapping - Common Weakness Enumeration Top 25 2024 [1] CWE ID 079

[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754

[16] Standards Mapping - FIPS200 SI

[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)

[21] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection

[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation

[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting

[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)

[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)

[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)

[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)

[28] Standards Mapping - OWASP Top 10 2021 A03 Injection

[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4

[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1

[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7

[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7

[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7

[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7

[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7

[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4

[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation

[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation

[41] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116

[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I

[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I

[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I

[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I

[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I

[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I

[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I

[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[59] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I

[63] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I

[64] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)

[65] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting

desc.dataflow.java.cross_site_scripting_content_sniffing

Abstract

Sending unvalidated data to a web browser may result in certain browsers executing malicious code.

Explanation

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.

2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but may also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

For the browser to render the response as HTML, or other document that may execute scripts, it has to specify a text/html MIME type. Therefore, XSS is only possible if the response uses this MIME type or any other that also forces the browser to render the response as HTML or other document that may execute scripts such as SVG images (image/svg+xml), XML documents (application/xml), etc.

Most modern browsers will not render HTML, nor execute scripts when provided a response with MIME types such as application/json. However, some browsers such as Internet Explorer perform what is known as Content Sniffing. Content Sniffing involves ignoring the provided MIME type and attempting to infer the correct MIME type by the contents of the response.
It is worth noting however, a MIME type of text/html is only one such MIME type that may lead to XSS vulnerabilities. Other documents that may execute scripts such as SVG images (image/svg+xml), XML documents (application/xml), as well as others may lead to XSS vulnerabilities regardless of whether the browser performs Content Sniffing.

Therefore, a response such as <html><body><script>alert(1)</script></body></html>, could be rendered as HTML even if its content-type header is set to application/json.

Example 1: The following AWS Lambda function reflects user data in an application/json response.


def mylambda_handler(event, context):
    name = event['name']
    response = {
        "statusCode": 200,
        "body": "{'name': name}",
        "headers": {
            'Content-Type': 'application/json',
        }
    }
    return response

If an attacker sends a request with the name parameter set to <html><body><script>alert(1)</script></body></html>, the server will produce the following response:


HTTP/1.1 200 OK
Content-Length: 88
Content-Type: application/json
Connection: Closed

{'name': '<html><body><script>alert(1)</script></body></html>'}