Reino: Input Validation and Representation
Los problemas de validación y representación de entradas están causados por metacaracteres, codificaciones alternativas y representaciones numéricas. Los problemas de seguridad surgen de entradas en las que se confía. Estos problemas incluyen: «desbordamientos de búfer», ataques de «scripts de sitios», "SQL injection" y muchas otras acciones.
Insecure Sanitizer Policy
Abstract
El uso de datos controlados por el usuario o que no son de confianza para definir la directiva de corrección de HTML podría permitir a un atacante evitar los requisitos de corrección y ejecutar ataques de Cross-Site Scripting (XSS).
Explanation
El término general "administración de entrada" describe funciones como la validación, la corrección, el filtrado y la codificación/decodificación de datos de entrada: Los ataques de scripts de sitios, la inyección de código SQL y las vulnerabilidades detectadas en el control de los procesos tienen todos su origen en la administración incorrecta o inexistente de entradas. La corrección de entradas, que implica la transformación de la entrada a una forma aceptable, normalmente se implementa además de la validación de entradas. La corrección de HTML hace referencia a la limpieza completa de la entrada del usuario para permitir únicamente etiquetas, atributos y elementos que se consideran seguros.
La implementación de una directiva de corrección de HTML completa es difícil, la clave de implementación correcta es comprender el contexto en el que se van a utilizar los datos. Cada contexto tiene sus propias vulnerabilidades y un tamaño no encaja con todos. Mientras que es útil utilizar un corrector de HTML (por ejemplo el corrector de HTML OWASP) para protegerse frente a vulnerabilidades de XSS en aplicaciones web, una implementación incorrecta puede conducir a una falsa sensación de seguridad.
Ejemplo 1: El siguiente código Java utiliza la variable de entrada controlada por el usuario
Un usuario malintencionado puede provocar que la directiva de corrección HTML acepte elementos peligrosos como <script> proporcionándolos a
La implementación de una directiva de corrección de HTML completa es difícil, la clave de implementación correcta es comprender el contexto en el que se van a utilizar los datos. Cada contexto tiene sus propias vulnerabilidades y un tamaño no encaja con todos. Mientras que es útil utilizar un corrector de HTML (por ejemplo el corrector de HTML OWASP) para protegerse frente a vulnerabilidades de XSS en aplicaciones web, una implementación incorrecta puede conducir a una falsa sensación de seguridad.
Ejemplo 1: El siguiente código Java utiliza la variable de entrada controlada por el usuario
elements
en la creación de una directiva de corrección HTML:
...
String elements = prop.getProperty("AllowedElements");
...
public static final PolicyFactory POLICY_DEFINITION = new HtmlPolicyBuilder()
.allowElements(elements)
.toFactory();
....
Un usuario malintencionado puede provocar que la directiva de corrección HTML acepte elementos peligrosos como <script> proporcionándolos a
elements
.References
[1] OWASP Cross-Site Scripting (XSS) Prevention Cheat Sheet
[2] Understanding Malicious Content Mitigation for Web Developers CERT
[3] HTML 4.01 Specification W3
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [1] CWE ID 079
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1), SI-15 Information Output Filtering (P0)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation, SI-15 Information Output Filtering
[16] 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)
[17] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[18] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[19] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[20] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] 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
[36] 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
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[50] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.java.insecure_sanitizer_policy