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.
Cross-Site Scripting: Content Sniffing
Abstract
El envío de datos no validados a un explorador web puede dar lugar, en algunos casos, a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:
1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.
2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.
El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.
Para que el explorador represente la respuesta como HTML u otro documento que pueda ejecutar scripts, debe especificar un tipo de MIME
La mayoría de los exploradores modernos no representan el HTML ni ejecutan scripts cuando se proporcione una respuesta con tipos de MIME como
Cabe destacar que un tipo de MIME de
Por lo tanto, una respuesta como
Ejemplo 1: El siguiente método JAX-RS refleja los datos de usuario en una respuesta
Si un usuario malintencionado envía una solicitud con el parámetro
Aunque la respuesta establece claramente que se debe tratar como un documento JSON, un explorador antiguo todavía podría intentar representarlo como documento HTML, por lo que sería vulnerable a un ataque Cross-Site Scripting.
1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.
2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.
El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.
Para que el explorador represente la respuesta como HTML u otro documento que pueda ejecutar scripts, debe especificar un tipo de MIME
text/html
. Por lo tanto, un ataque XSS solo es posible si la respuesta usa este tipo de MIME o cualquier otro que también fuerce al explorador a representar la respuesta como HTML u otro documento que pueda ejecutar scripts, como imágenes SVG (image/svg+xml
), documentos XML (application/xml
), etc. La mayoría de los exploradores modernos no representan el HTML ni ejecutan scripts cuando se proporcione una respuesta con tipos de MIME como
application/octet-stream
. Sin embargo, algunos exploradores como Internet Explorer realizan lo que se conoce como Content Sniffing
. Content Sniffing consiste en ignorar el tipo de MIME proporcionado e intentar deducir el tipo de MIME correcto a partir del contenido de la respuesta.Cabe destacar que un tipo de MIME de
text/html
es solo uno de los tipos de MIME que pueden generar vulnerabilidades a ataques XSS. Otros documentos que pueden ejecutar scripts, como las imágenes SVG (image/svg+xml
) y los documentos XML (application/xml
) entre otros, pueden provocar vulnerabilidades a ataques XSS con independencia de si el explorador realiza Content Sniffing. Por lo tanto, una respuesta como
<html><body><script>alert(1)</script></body></html>
podría representarse como HTML aunque su encabezado content-type
esté definido en application/octet-stream
, multipart-mixed
, etc.Ejemplo 1: El siguiente método JAX-RS refleja los datos de usuario en una respuesta
application/octet-stream
.
@RestController
public class SomeResource {
@RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
public String response5(@RequestParam(value="name") String name){
return name;
}
}
Si un usuario malintencionado envía una solicitud con el parámetro
name
definido en <html><body><script>alert(1)</script></body></html>
, el servidor produce la siguiente respuesta:
HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed
<html><body><script>alert(1)</script></body></html>
Aunque la respuesta establece claramente que se debe tratar como un documento JSON, un explorador antiguo todavía podría intentar representarlo como documento HTML, por lo que sería vulnerable a un ataque Cross-Site Scripting.
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 - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[15] Standards Mapping - FIPS200 SI
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] 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)
[20] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[23] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2021 A03 Injection
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] 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
[38] 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
[39] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[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 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.java.cross_site_scripting_content_sniffing
Abstract
El envío de datos no validados a un explorador web puede dar lugar, en algunos casos, a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:
1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.
2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.
El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.
Para que el explorador represente la respuesta como HTML u otro documento que pueda ejecutar scripts, debe especificar un tipo de MIME
La mayoría de los exploradores modernos no representarán el HTML ni ejecutarán scripts cuando se proporcione una respuesta con tipos de MIME como
Otros documentos que pueden ejecutar scripts, como las imágenes SVG (
Por lo tanto, una respuesta como
Ejemplo 1: La siguiente función AWS Lambda refleja los datos de usuario en una respuesta
Si un usuario malintencionado envía una solicitud con el parámetro
Aunque la respuesta establece claramente que se debe tratar como un documento JSON, un explorador antiguo todavía podría intentar representarlo como documento HTML, por lo que sería vulnerable a un ataque Cross-Site Scripting.
1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.
2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.
El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.
Para que el explorador represente la respuesta como HTML u otro documento que pueda ejecutar scripts, debe especificar un tipo de MIME
text/html
. Por lo tanto, un ataque XSS solo es posible si la respuesta usa este tipo de MIME o cualquier otro que también fuerce al explorador a representar la respuesta como HTML u otro documento que pueda ejecutar scripts, como imágenes SVG (image/svg+xml
), documentos XML (application/xml
), etc. La mayoría de los exploradores modernos no representarán el HTML ni ejecutarán scripts cuando se proporcione una respuesta con tipos de MIME como
application/json
. Sin embargo, algunos exploradores como Internet Explorer realizan lo que se conoce como Content Sniffing
. Content Sniffing consiste en ignorar el tipo de MIME proporcionado e intentar deducir el tipo de MIME correcto a partir del contenido de la respuesta.Cabe destacar que un tipo de MIME de text/html
es solo uno de los tipos de MIME que pueden generar vulnerabilidades a ataques XSS.Otros documentos que pueden ejecutar scripts, como las imágenes SVG (
image/svg+xml
) y los documentos XML (application/xml
) entre otros, pueden provocar vulnerabilidades a ataques XSS con independencia de si el explorador realiza Content Sniffing. Por lo tanto, una respuesta como
<html><body><script>alert(1)</script></body></html>
podría representarse como HTML aunque su encabezado content-type
esté definido en application/json
.Ejemplo 1: La siguiente función AWS Lambda refleja los datos de usuario en una respuesta
application/json
.
def mylambda_handler(event, context):
name = event['name']
response = {
"statusCode": 200,
"body": "{'name': name}",
"headers": {
'Content-Type': 'application/json',
}
}
return response
Si un usuario malintencionado envía una solicitud con el parámetro
name
definido en <html><body><script>alert(1)</script></body></html>
, el servidor produce la siguiente respuesta:
HTTP/1.1 200 OK
Content-Length: 88
Content-Type: application/json
Connection: Closed
{'name': '<html><body><script>alert(1)</script></body></html>'}
Aunque la respuesta establece claramente que se debe tratar como un documento JSON, un explorador antiguo todavía podría intentar representarlo como documento HTML, por lo que sería vulnerable a un ataque Cross-Site Scripting.
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 - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[15] Standards Mapping - FIPS200 SI
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] 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)
[20] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[23] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2021 A03 Injection
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] 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
[38] 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
[39] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[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 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.python.cross_site_scripting_content_sniffing