+V1.2 Injection Prevention
---+V1.2.1 Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for …
---+V1.2.2 Verify that when dynamically building URLs, untrusted data is encoded according to its context …
---+V1.2.3 Verify that output encoding or escaping is used when dynamically building JavaScript content …
---+V1.2.4 Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized …
---+V1.2.5 Verify that the application protects against OS command injection and that operating system calls …
---+V1.2.6 Verify that the application protects against LDAP injection vulnerabilities, or that specific …
---+V1.2.7 Verify that the application is protected against XPath injection attacks by using query …
---+V1.2.8 Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) …
---+V1.2.9 Verify that the application escapes special characters in regular expressions (typically using a …
---+V1.2.10 Verify that the application is protected against CSV and Formula Injection. The application must …

V1.2 Injection Prevention

Output encoding or escaping, performed close to or adjacent to a potentially dangerous context, is critical to the security of any application. Typically, output encoding and escaping are not persisted, but are instead used to render output safe for immediate use in the appropriate interpreter. Attempting to perform this too early may result in malformed content or render the encoding or escaping ineffective.

In many cases, software libraries include safe or safer functions that perform this automatically, although it is necessary to ensure that they are correct for the current context.

Note: Using parameterized queries or escaping SQL is not always sufficient. Query parts such as table and column names (including "ORDER BY" column names) cannot be escaped. Including escaped user-supplied data in these fields results in failed queries or SQL injection.

1. Prehľad

Názov Štandard
V1.2.1 Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for …

Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure.

V1.2.2 Verify that when dynamically building URLs, untrusted data is encoded according to its context …

Verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path parameters). Ensure that only safe URL protocols are permitted (e.g., disallow javascript: or data:).

V1.2.3 Verify that output encoding or escaping is used when dynamically building JavaScript content …

Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection).

V1.2.4 Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized …

Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This is also relevant when writing stored procedures.

V1.2.5 Verify that the application protects against OS command injection and that operating system calls …

Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding.

V1.2.6 Verify that the application protects against LDAP injection vulnerabilities, or that specific …

Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented.

V1.2.7 Verify that the application is protected against XPath injection attacks by using query …

Verify that the application is protected against XPath injection attacks by using query parameterization or precompiled queries.

V1.2.8 Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) …

Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX injection attacks.

V1.2.9 Verify that the application escapes special characters in regular expressions (typically using a …

Verify that the application escapes special characters in regular expressions (typically using a backslash) to prevent them from being misinterpreted as metacharacters.

V1.2.10 Verify that the application is protected against CSV and Formula Injection. The application must …

Verify that the application is protected against CSV and Formula Injection. The application must follow the escaping rules defined in RFC 4180 sections 2.6 and 2.7 when exporting CSV content. Additionally, when exporting to CSV or other spreadsheet formats (such as XLS, XLSX, or ODF), special characters (including '=', '+', '-', '@', '\t' (tab), and '\0' (null character)) must be escaped with a single quote if they appear as the first character in a field value.

1.1 Odkazy

1.2 Identifikované požiadavky

1.3 Súvisiace predpisy

2. Identifikované požiadavky

Požiadavky
Zdroj Požiadavka

3. Súvisiace predpisy

Predpisy
Zdroj Regulácia
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.