537 elementos encontrados
Debilidades
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca Header Manipulation de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies u Open Redirect.
Explanation
Se producen vulnerabilidades de manipulación de cookies cuando ocurre lo siguiente:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.



2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.



Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como Cross-Site Request Forgery, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Al tratarse de un encabezado de respuesta HTTP, los ataques de manipulación de cookies también pueden provocar otros tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de Header Manipulation es la división de respuesta HTTP. Para realizar un ataque de división de respuesta HTTP con éxito, la aplicación debe permitir entradas que contengan caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación pretende enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernos impiden la inyección de caracteres malintencionados en los encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, como el valor de la cookie se compone de la entrada de usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para author no contiene ningún carácter CR ni LF. Si un atacante envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", la respuesta HTTP se dividiría en dos respuestas con el siguiente formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el atacante controla la segunda respuesta, y esta se puede crear con cualquier contenido de cuerpo y encabezado deseado. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y de la Web, Cross-Site Scripting y el secuestro de páginas.

Desfiguración de usuarios de sitios: Un atacante puede realizar una única solicitud en un servidor vulnerable que haga que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparte la misma conexión TCP con el servidor. Esto se puede lograr si se convence al usuario de que envíe la solicitud malintencionada por sí mismo o de forma remota en situaciones donde el atacante y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque y hacer que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación, pero que redirija información privada, como los números de cuenta y las contraseñas, al atacante.

Envenenamiento de caché: El impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilizan varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas (la respuesta prevista del servidor y la respuesta generada por el atacante), un atacante puede hacer que un nodo intermedio, como un servidor proxy compartido, desvíe al atacante una respuesta generada por el servidor destinada al usuario. Como la solicitud realizada por el atacante genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del atacante, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del atacante ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El atacante envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar toda la información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Open Redirect: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede ayudar a los ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca Header Manipulation de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies u Open Redirect.
Explanation
Se producen vulnerabilidades de manipulación de cookies cuando ocurre lo siguiente:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Cookie Manipulation: Cuando se combina con ataques como la falsificación de solicitudes entre sitios, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Al tratarse de un encabezado de respuesta HTTP, los ataques de manipulación de cookies también pueden provocar otros tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de Header Manipulation es la división de respuesta HTTP. Para realizar un ataque de división de respuesta HTTP con éxito, la aplicación debe permitir entradas que contengan caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación pretende enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernos de hoy impiden la inyección de caracteres malintencionados en los encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, como el valor de la cookie se compone de la entrada de usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un atacante envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", la respuesta HTTP se dividiría en dos respuestas con el siguiente formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el atacante controla la segunda respuesta, y esta se puede crear con cualquier contenido de cuerpo y encabezado deseado. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios: Un atacante puede realizar una única solicitud en un servidor vulnerable que haga que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparte la misma conexión TCP con el servidor. Esto se puede lograr si se convence al usuario de que envíe la solicitud malintencionada por sí mismo o de forma remota en situaciones donde el atacante y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque y hacer que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación, pero que redirija información privada, como los números de cuenta y las contraseñas, al atacante.

Envenenamiento de caché: El impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilizan varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes adquieren el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, un atacante puede aprovechar la misma vulnerabilidad de raíz para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas (la respuesta prevista del servidor y la respuesta generada por el atacante), un atacante puede hacer que un nodo intermedio, como un servidor proxy compartido, desvíe al atacante una respuesta generada por el servidor destinada al usuario. Como la solicitud realizada por el atacante genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del atacante, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del atacante ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El atacante envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar toda la información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Open Redirect: Si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede contribuir a los ataques de suplantación de identidad.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Algunos piensan que en el mundo de las plataformas móviles, las vulnerabilidades de las aplicaciones web clásicas como la manipulación de encabezados y cookies no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 2: el siguiente código adapta el Example 1 a la plataforma Android.


...
CookieManager webCookieManager = CookieManager.getInstance();
String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
webCookieManager.setCookie(url, setCookie);

...
Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Cross-User Defacement: Un atacante puede realizar una única solicitud en un servidor vulnerable que haga que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparte la misma conexión TCP con el servidor. Esto se puede lograr si se convence al usuario de que envíe la solicitud malintencionada por sí mismo o de forma remota en situaciones donde el atacante y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque y hacer que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación, pero que redirija información privada, como los números de cuenta y las contraseñas, al atacante.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


<?php
$author = $_GET['AUTHOR_PARAM'];
...
header("author: $author");
?>


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo 1: El siguiente segmento de código lee la ubicación desde una solicitud HTTP y establece en un encabezado el campo de ubicación de una respuesta HTTP.


location = req.field('some_location')
...
response.addHeader("location",location)


Si una cadena compuesta por caracteres alfanuméricos, como “index.html”, se envía en la solicitud, la respuesta HTTP que incluye esta cookie podría mostrarse de la siguiente forma:


HTTP/1.1 200 OK
...
location: index.html
...


Sin embargo, dado que el valor de la ubicación se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para some_location no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", la respuesta HTTP debería dividirse en dos respuestas de la siguiente forma:


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar Cache-Poisoning, Cross-Site Scripting, Cross-User Defacement, Page Hijacking, Cookie Manipulation u Open Redirect.
Explanation
Las vulnerabilidades de Cookie Manipulation se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, Cookie Manipulation es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Cookie Manipulation: Cuando se combina con ataques como Cross-Site Request Forgery, los usuarios malintencionados pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de Cookie Manipulation también pueden provocar otro tipos de ataques como:

HTTP Response Splitting:
Uno de los ataques más comunes de Header Manipulation es HTTP Response Splitting. Para realizar un ataque de HTTP Response Splitting con éxito, la aplicación debe permitir entradas que contengan los caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation_cookies
Abstract
Incluir datos no validados en un encabezado SMTP puede permitir que los atacantes agreguen encabezados arbitrarios, como CC o BCC, que pueden usar para filtrar el contenido del correo hacia ellos mismos o para utilizar el servidor de correo como un bot de spam.
Explanation
Se producen vulnerabilidades de SMTP Header Manipulation cuando:

1. Los datos entran en una aplicación a través de un origen no confiable, más frecuentemente en una solicitud HTTP en una aplicación web.

2. Los datos se incluyen en un encabezado SMTP enviado a un servidor de correo sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, SMTP Header Manipulation es un medio para lograr un fin, no un fin en sí mismo. En esencia, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado SMTP.

Uno de los ataques más comunes de SMTP Header Manipulation se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formulario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado puede definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo 1: El siguiente segmento de código lee el asunto y el cuerpo de un formulario de contacto:


func handler(w http.ResponseWriter, r *http.Request) {
subject := r.FormValue("subject")
body := r.FormValue("body")
auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
to := []string{"recipient@example.net"}
msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
if err != nil {
log.Fatal(err)
}
}


Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


...
subject: [Contact us query] Page not working
...


Sin embargo, como el valor del encabezado se construye a partir de la entrada de usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para subject no contiene ningún carácter CR ni LF. Si un atacante envía una cadena maliciosa, como "¡¡Felicitaciones!! ¡¡Ha ganado la lotería!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", los encabezados SMTP tendrían el siguiente formato:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


Esto permite que un atacante genere mensajes de spam o envíe correos electrónicos anónimos, entre otros ataques.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 93
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.golang.header_manipulation_smtp
Abstract
La inclusión de datos sin validar en un encabezado SMTP puede permitir a los usuarios malintencionados agregar encabezados arbitrarios, como CC o BCC, que pueden utilizar para acceder al contenido del correo o utilizar el servidor de correo como un bot de correo no deseado.
Explanation
Las vulnerabilidades de manipulación de encabezado SMTP se producen cuando:

1. Los datos entran en una aplicación a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP en una aplicación web.

2. Los datos se incluyen en un encabezado HTTP que se envía a un servidor de correo sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado SMTP es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado SMTP.

Uno de los ataques más comunes de manipulación de encabezado SMTP se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formulario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado podrá definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo 1: El siguiente segmento de código lee el asunto y el cuerpo de un formulario de contacto:


String subject = request.getParameter("subject");
String body = request.getParameter("body");
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("webform@acme.com"));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
message.setSubject("[Contact us query] " + subject);
message.setText(body);
Transport.send(message);


Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


...
subject: [Contact us query] Page not working
...


Sin embargo, dado que el valor del encabezado se crea a partir de la entrada de un usuario no validado, la respuesta solo mantendrá esta forma si el valor introducido para subject no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "¡Felicidades! ¡¡Ha ganado la lotería!!\r\ncc:victim1@mail.com,victim2@mail.com ...", entonces los encabezados SMTP tendrían la siguiente forma:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


En la práctica, esto permitirá a un usuario malintencionado elaborar mensajes de correo no deseado o enviar mensajes anónimos entre otros ataques.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.java.header_manipulation_smtp
Abstract
La inclusión de datos sin validar en un encabezado SMTP puede permitir a los usuarios malintencionados agregar encabezados arbitrarios, como CC o BCC, que pueden utilizar para acceder al contenido del correo o utilizar el servidor de correo como un bot de correo no deseado.
Explanation
Las vulnerabilidades de manipulación de encabezado SMTP se producen cuando:

1. Los datos entran en una aplicación a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP en una aplicación web.

2. Los datos se incluyen en un encabezado HTTP que se envía a un servidor de correo sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado SMTP es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado SMTP.

Uno de los ataques más comunes de manipulación de encabezado SMTP se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado podrá definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo 1: El siguiente segmento de código lee el asunto y el cuerpo de un formulario de contacto:


$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);


Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


...
subject: [Contact us query] Page not working
...


Sin embargo, dado que el valor del encabezado se crea a partir de la entrada de un usuario no validado, la respuesta solo mantendrá esta forma si el valor introducido para subject no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "¡Felicidades! ¡¡Ha ganado la lotería!!\r\ncc:victim1@mail.com,victim2@mail.com ...", entonces los encabezados SMTP tendrían la siguiente forma:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


En la práctica, esto permitirá a un usuario malintencionado elaborar mensajes de correo no deseado o enviar mensajes anónimos entre otros ataques.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.php.header_manipulation_smtp
Abstract
La inclusión de datos sin validar en un encabezado SMTP puede permitir a los usuarios malintencionados agregar encabezados arbitrarios, como CC o BCC, que pueden utilizar para acceder al contenido del correo o utilizar el servidor de correo como un bot de correo no deseado.
Explanation
Las vulnerabilidades de manipulación de encabezado SMTP se producen cuando:

1. Los datos entran en una aplicación a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP en una aplicación web.

2. Los datos se incluyen en un encabezado HTTP que se envía a un servidor de correo sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado SMTP es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado SMTP.

Uno de los ataques más comunes de manipulación de encabezado SMTP se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado podrá definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo 1: El siguiente segmento de código lee el asunto y el cuerpo de un formulario de contacto:


body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
"subject: [Contact us query] " + subject,
"to: support@acme.com",
"mime-version: 1.0",
"content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)


Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


...
subject: [Contact us query] Page not working
...


Sin embargo, dado que el valor del encabezado se crea a partir de la entrada de un usuario no validado, la respuesta solo mantendrá esta forma si el valor introducido para subject no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "¡Felicidades! ¡¡Ha ganado la lotería!!\r\ncc:victim1@mail.com,victim2@mail.com ...", entonces los encabezados SMTP tendrían la siguiente forma:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


En la práctica, esto permitirá a un usuario malintencionado elaborar mensajes de correo no deseado o enviar mensajes anónimos entre otros ataques.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
El programa crea un campo de formulario oculto.
Explanation
A menudo, los programadores confían en el contenido de los campos ocultos, suponiendo que los usuarios no podrán verlos ni manipular su contenido. Los atacantes pueden burlar estas suposiciones. Examinan los valores escritos en los campos ocultos y los alteran o reemplazan si contenido por datos de ataque.

Ejemplo 1:

HtmlInputHidden hidden = new HtmlInputHidden();


Si los campos ocultos contienen información confidencial, esta se incluirá en la caché al igual que el resto de la página. Esto provoca que la información confidencial se almacene en la caché del explorador sin que el usuario lo sepa.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 472
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[5] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[6] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[7] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[8] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[9] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[10] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[32] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.hidden_field
Abstract
El programa crea un campo de formulario oculto.
Explanation
A menudo, los programadores confían en el contenido de los campos ocultos, suponiendo que los usuarios no podrán verlos ni manipular su contenido. Los atacantes pueden burlar estas suposiciones. Examinan los valores escritos en los campos ocultos y los alteran o reemplazan si contenido por datos de ataque.

Ejemplo 1:

Hidden hidden = new Hidden(element);


Si los campos ocultos contienen información confidencial, esta se incluirá en la caché al igual que el resto de la página. Esto provoca que la información confidencial se almacene en la caché del explorador sin que el usuario lo sepa.
References
[1] IDS14-J. Do not trust the contents of hidden form fields CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 472
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[6] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[7] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[8] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[9] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[10] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[32] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[33] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.hidden_field
Abstract
Se utiliza un campo de formulario oculto.
Explanation
A menudo, los programadores confían en el contenido de los campos ocultos, suponiendo que los usuarios no podrán verlos ni manipular su contenido. Los atacantes pueden burlar estas suposiciones. Examinan los valores escritos en los campos ocultos y los alteran o reemplazan si contenido por datos de ataque.

Ejemplo 1: Una etiqueta <input> del tipo hidden indica el uso de un campo oculto.

<input type="hidden">


Si los campos ocultos contienen información confidencial, esta se incluirá en la caché al igual que el resto de la página. Esto provoca que la información confidencial se almacene en la caché del explorador sin que el usuario lo sepa.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 472
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[5] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[6] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[7] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[8] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[9] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[10] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[32] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.content.html.hidden_field
Abstract
El encabezado X-XSS-Protection está explícitamente deshabilitado, lo que puede aumentar el riesgo de ataques de scripts entre sitios.
Explanation
El encabezado X-XSS-Protection normalmente está habilitado de forma predeterminada en los navegadores modernos. Cuando el valor del encabezado se establece en false (0), se deshabilita la protección frente a ataques Cross-Site Scripting.

El encabezado se puede establecer en varios lugares y se debe comprobar que no presente errores de configuración y manipulaciones malintencionadas.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] HttpResponse.AppendHeader Method
[4] How to prevent cross-site scripting security issues
[5] HOW TO: Disable the Documentation Protocol for ASP.NET Web Services
[6] Configuring Services Using Configuration Files
[7] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[15] Standards Mapping - FIPS200 CM
[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.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[23] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[25] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[26] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.dotnet.html5_xss_protection
Abstract
El encabezado X-XSS-Protection se encuentra deshabilitado de forma explícita, lo que puede aumentar el riesgo de ataques Cross-Site Scripting.
Explanation
El encabezado X-XSS-Protection normalmente está habilitado de forma predeterminada en los navegadores modernos. Cuando el valor del encabezado se establece en false (0), se deshabilita la protección frente a ataques Cross-Site Scripting.

El encabezado se puede establecer en varios lugares y se debe comprobar que no presente errores de configuración ni manipulaciones malintencionadas.

Ejemplo 1: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar la protección XSS:

<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] 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
[34] 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
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_cross_site_scripting_protection
Abstract
El encabezado X-XSS-Protection está explícitamente deshabilitado, lo que puede aumentar el riesgo de ataques de scripts entre sitios.
Explanation
El encabezado X-XSS-Protection normalmente está habilitado de forma predeterminada en los navegadores modernos. Cuando el valor del encabezado se establece en false (0), se deshabilita la protección frente a ataques Cross-Site Scripting.
El encabezado se puede establecer en varios lugares y se debe comprobar que no presente errores de configuración y manipulaciones malintencionadas.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] Node.js Security Checklist
[4] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 CM
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[18] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.javascript.html5_cross_site_scripting_protection
Abstract
El encabezado X-XSS-Protection está explícitamente deshabilitado, lo que puede aumentar el riesgo de ataques de scripts entre sitios.
Explanation
El encabezado X-XSS-Protection normalmente está habilitado de forma predeterminada en los navegadores modernos. Cuando el valor del encabezado se establece en false (0), se deshabilita la protección frente a ataques Cross-Site Scripting.

El encabezado se puede establecer en varios lugares y se debe comprobar que no presente errores de configuración y manipulaciones malintencionadas.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] django-secure
[4] SECURE_BROWSER_XSS_FILTER
[5] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[13] Standards Mapping - FIPS200 CM
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[19] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[21] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[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.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_cross_site_scripting_protection
Abstract
El método Application_BeginRequest está vacío o no incluye una llamada a una función para establecer X-Content-Type-Options en nosniff o intenta quitar el encabezado
Explanation
El ataque de reconocimiento MIME es la práctica de inspeccionar el contenido de una secuencia de bytes con el fin de intentar deducir el formato de archivo de los datos que contiene.

Si el ataque de reconocimiento MIME no se deshabilita explícitamente, algunos exploradores se podrían manipular para que interpretaran los datos de una manera no deseada y permitir ataques de scripts entre sitios.

Para cada página que contenga contenido controlable por el usuario, debe utilizar el encabezado HTTP X-Content-Type-Options: nosniff.
References
[1] Reducing MIME type security risks
[2] ASP.NET Configuration Files
[3] Global.asax Syntax
[4] IE8 Security Part V: Comprehensive Protection
[5] Custom HttpModule Example
[6] HttpResponse Class
[7] MIME types and stylesheets
[8] Standards Mapping - Common Weakness Enumeration CWE ID 554
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[16] Standards Mapping - FIPS200 CM
[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.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[24] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[25] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[26] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[27] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.dotnet.html5_mime_sniffing
Abstract
La aplicación aplica el algoritmo de reconocimiento MIME o no establece X-Content-Type-Options en nosniff.
Explanation
El ataque de reconocimiento MIME es la práctica de inspeccionar el contenido de una secuencia de bytes con el fin de intentar deducir el formato de archivo de los datos que contiene.

Si el ataque de reconocimiento MIME no se deshabilita explícitamente, algunos exploradores se podrían manipular para que interpretaran los datos de una manera no deseada y permitir ataques de scripts entre sitios.
Al escribir una aplicación web, utilice el encabezado HTTP X-Content-Type-Options: nosniff en cada página que podría incluir contenido controlable por el usuario.
Al escribir una aplicación cliente, no debe usar el algoritmo de reconocimiento MIME para determinar el tipo de contenido de la respuesta del servidor.

Ejemplo 1: El siguiente código utiliza net.http.DetectContentType() para determinar el tipo de contenido de la respuesta:


...
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)

content_type := DetectContentType(body)
...
References
[1] OWASP OWASP Secure Headers Project
[2] WHATWG MIME Sniffing
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.golang.html5_mime_sniffing
Abstract
La aplicación no establece X-Content-Type-Options en nosniff ni deshabilita explícitamente este encabezado de seguridad.
Explanation
El ataque de reconocimiento MIME es la práctica de inspeccionar el contenido de una secuencia de bytes con el fin de deducir el formato de archivo de los datos que contiene.

Si el ataque de reconocimiento MIME no se deshabilita de forma explícita, los atacantes pueden manipular algunos exploradores para que interpreten los datos de una manera no deseada y se permitan así ataques Cross-Site Scripting. Para cada página que contenga contenido controlable por el usuario, debe utilizar el encabezado HTTP X-Content-Type-Options: nosniff.

Ejemplo 1: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar la protección contra reconocimiento MIME:

<http auto-config="true">
...
<headers>
...
<content-type-options disabled="true"/>
</headers>
</http>
References
[1] OWASP OWASP Secure Headers Project
[2] Standards Mapping - Common Weakness Enumeration CWE ID 554
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 CM
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_mime_sniffing
Abstract
La aplicación Node.js no establece X-Content-Type-Options como nosniff ni deshabilita explícitamente este encabezado de seguridad.
Explanation
El ataque de reconocimiento MIME es la práctica de inspeccionar el contenido de una secuencia de bytes con el fin de intentar deducir el formato de archivo de los datos que contiene.

Si el ataque de reconocimiento MIME no se deshabilita explícitamente, algunos exploradores se podrían manipular para que interpretaran los datos de una manera no deseada y permitir ataques de scripts entre sitios.

Para cada página que contenga contenido controlable por el usuario, debe utilizar el encabezado HTTP X-Content-Type-Options: nosniff.
References
[1] Node.js Security Checklist
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.javascript.html5_mime_sniffing
Abstract
La aplicación de Django no establece X-Content-Type-Options como nosniff ni deshabilita explícitamente este encabezado de seguridad.
Explanation
El ataque de reconocimiento MIME es la práctica de inspeccionar el contenido de una secuencia de bytes con el fin de intentar deducir el formato de archivo de los datos que contiene.

Si el ataque de reconocimiento MIME no se deshabilita explícitamente, algunos exploradores se podrían manipular para que interpretaran los datos de una manera no deseada y permitir ataques de scripts entre sitios.

Para cada página que contenga contenido controlable por el usuario, debe utilizar el encabezado HTTP X-Content-Type-Options: nosniff.
References
[1] SECURE_CONTENT_TYPE_NOSNIFF
[2] django-secure
[3] OWASP OWASP Secure Headers Project
[4] Standards Mapping - Common Weakness Enumeration CWE ID 554
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 CM
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[18] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_mime_sniffing
Abstract
No se configura la directiva de seguridad de contenido (CSP).
Explanation
La directiva de seguridad de contenido (CSP) es un encabezado de seguridad declarativo que permite a los desarrolladores establecer los dominios en los que el sitio puede cargar contenido o con los que puede inicializar conexiones cuando se procesa en el explorador web. Esta directiva proporciona una capa de seguridad adicional contra vulnerabilidades críticas, como los ataques Cross-Site Scripting, el secuestro de clics (clickjacking), el acceso de origen cruzado y similares, por encima de la validación de entrada y la comprobación de listas de permitidos en el código.

Spring Security y otros marcos de trabajo no agregan encabezados de directiva de seguridad de contenido de forma predeterminada. El autor de la aplicación web debe declarar las directivas de seguridad que se deben aplicar o supervisar los recursos protegidos para poder aprovechar esta capa adicional de seguridad.
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[3] Standards Mapping - Common Weakness Enumeration CWE ID 1173
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_missing_content_security_policy
Abstract
La aplicación no prohíbe que los exploradores permitan que sitios de terceros representen su contenido.
Explanation
Permitir que un sitio web se agregue a un marco puede ser un problema de seguridad. Por ejemplo, esto puede conducir a vulnerabilidades de secuestro de clics (clickjacking) o permitir las comunicaciones no deseadas entre marcos.

De forma predeterminada, los marcos de trabajo como Spring Security incluyen el encabezado X-Frame-Options para indicar al explorador si la aplicación debe enmarcarse o no. Si se deshabilita o no se establece este encabezado, se pueden presentar vulnerabilidades entre marcos.

Ejemplo 1: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar el encabezado X-Frame-Options:

<http auto-config="true">
...
<headers>
...
<frame-options disabled="true"/>
</headers>
</http>
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 1021
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.7 HTTP Security Headers Requirements (L1 L2 L3)
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_missing_framing_protection
Abstract
La directiva de seguridad de contenido (CSP) está configurada con una directiva demasiado permisiva que puede suponer riesgos de seguridad.
Explanation
La directiva de seguridad de contenido (CSP) es un encabezado de seguridad declarativo que permite a los desarrolladores especificar en el explorador comportamientos permitidos relacionados con la seguridad, como una lista de ubicaciones permitidas desde las que se puede recuperar contenido. Esta directiva proporciona una capa de seguridad adicional contra vulnerabilidades críticas, como los ataques Cross-Site Scripting, el secuestro de clics (clickjacking), el acceso de origen cruzado y similares, por encima de la validación de entrada y la comprobación de listas de permitidos en el código. Sin embargo, un encabezado configurado de manera incorrecta no puede proporcionar esta capa de seguridad adicional. La directiva se define con la ayuda de 15 directivas que incluyen ocho que controlan el acceso a recursos: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. Estas ocho directivas toman una lista de orígenes como un valor que especifica dominios a los que el sitio puede acceder en relación con una función contemplada en esa directiva. Los desarrolladores pueden utilizar el carácter comodín * para indicar la totalidad o una parte del origen. Otras palabras clave de lista de orígenes, como 'unsafe-inline' y 'unsafe-eval', permiten tener un control más granular de la ejecución de scripts, pero son potencialmente dañinas. Ninguna de las directivas es obligatoria. Los exploradores bien permiten todos los orígenes de una directiva no incluida en la lista, o bien obtienen su valor de una directiva default-src opcional. Además, la especificación de este encabezado ha evolucionado con el tiempo. Se implementó como X-Content-Security-Policy en Firefox hasta la versión 23 y en IE hasta la versión 10, y se implementó como X-Webkit-CSP en Chrome hasta la versión 25. Estos dos nombres han quedado en desuso en favor del nombre Content Security Policy, que ahora es estándar. Dada la cantidad de directivas, dos nombres alternativos reemplazados y la forma en la que se tratan varias repeticiones del mismo encabezado y las directivas repetidas en un solo encabezado, hay una alta probabilidad de que los desarrolladores configuren este encabezado incorrectamente.

Ejemplo 1: El siguiente código define una directiva default-src demasiado insegura y permisiva:

<http auto-config="true">
...
<headers>
...
<content-security-policy policy-directives="default-src '*'" />
</headers>
</http>
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[7] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[8] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[23] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_overly_permissive_content_security_policy
Abstract
La directiva de seguridad de contenido (CSP) está configurada con una directiva demasiado permisiva que puede suponer riesgos de seguridad.
Explanation
La directiva de seguridad de contenido (CSP) es un encabezado de seguridad declarativo que permite a los desarrolladores especificar en el explorador comportamientos permitidos relacionados con la seguridad, como una lista de permitidos desde la que se puede recuperar contenido. Esta directiva proporciona una capa de seguridad adicional contra vulnerabilidades críticas, como los ataques de Cross-Site Scripting, el secuestro de clics (clickjacking), el acceso de origen cruzado y ataques similares, por encima de la validación de entradas y la comprobación de listas de permitidos en el código. Sin embargo, un encabezado configurado de manera incorrecta no puede proporcionar esta capa de seguridad adicional. La directiva se define con la ayuda de 15 directivas que incluyen ocho que controlan el acceso a recursos: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. Estas ocho directivas toman una lista de orígenes como un valor que especifica dominios a los que el sitio puede acceder en relación con una función contemplada en esa directiva. Los desarrolladores pueden utilizar el carácter comodín * para indicar la totalidad o una parte del origen. Otras palabras clave de lista de orígenes, como 'unsafe-inline' y 'unsafe-eval', permiten tener un control más granular de la ejecución de scripts, pero son potencialmente dañinas. Ninguna de las directivas es obligatoria. Los exploradores bien permiten todos los orígenes de una directiva no incluida en la lista, o bien obtienen su valor de una directiva default-src opcional. Además, la especificación de este encabezado ha evolucionado con el tiempo. Se implementó como X-Content-Security-Policy en Firefox hasta la versión 23 y en IE hasta la versión 10, y se implementó como X-Webkit-CSP en Chrome hasta la versión 25. Estos dos nombres han quedado en desuso en favor del nombre Content Security Policy, que ahora es estándar. Dada la cantidad de directivas, dos nombres alternativos reemplazados y la forma en la que se tratan varias repeticiones del mismo encabezado y las directivas repetidas en un solo encabezado, hay una alta probabilidad de que los desarrolladores configuren este encabezado incorrectamente.

En este caso, se ha configurado una directiva *-src con una directiva demasiado permisiva como *Ejemplo 1: La siguiente configuración django-csp define una directiva demasiado permisiva e insegura default-src:


...
MIDDLEWARE = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", '*')
...
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[3] Mozilla django-csp
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[8] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[24] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_overly_permissive_content_security_policy
Abstract
El programa define una política de compartir recursos de origen cruzado (CORS) demasiado permisiva.
Explanation
Antes de HTML5, los exploradores web aplicaban la directiva de mismo origen, la cual garantiza que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web deben provenir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podía servir a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. HTML5 permite que JavaScript acceda a datos de diferentes dominios si se define un nuevo encabezado de HTTP llamado Access-Control-Allow-Origin. Con este encabezado, un servidor web define los dominios que pueden acceder a su dominio mediante solicitudes de origen cruzado. Sin embargo, tenga cuidado al definir el encabezado, ya que una directiva CORS demasiado laxa puede permitir que una aplicación malintencionada se comunique con la aplicación víctima de forma inapropiada y se produzcan ataques de suplantación, robo de datos y retransmisión, entre otros.

Ejemplo 1: El código siguiente es un ejemplo del uso de un carácter comodín para especificar mediante programación los dominios con los que la aplicación se puede comunicar.


Response.AppendHeader("Access-Control-Allow-Origin", "*");


Utilizar el * como el valor del encabezado de Access-Control-Allow-Origin indica que el JavaScript que se está ejecutando en cualquier dominio puede acceder a los datos de la aplicación.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.dotnet.html5_overly_permissive_cors_policy
Abstract
El programa define una directiva de Uso compartido de recursos entre orígenes (CORS) excesivamente permisiva.
Explanation
Antes de HTML5, los exploradores web aplicaban la directiva de mismo origen, la cual garantiza que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web deben provenir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podía servir a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. HTML5 permite que JavaScript acceda a datos de diferentes dominios si se define un nuevo encabezado de HTTP llamado Access-Control-Allow-Origin. Con este encabezado, un servidor web define los dominios que pueden acceder a su dominio mediante solicitudes de origen cruzado. Sin embargo, tenga cuidado al definir el encabezado, ya que una directiva CORS demasiado laxa puede permitir que una aplicación malintencionada se comunique con la aplicación víctima de forma inapropiada y se produzcan ataques de suplantación, robo de datos y retransmisión, entre otros.

Ejemplo 1: El código siguiente es un ejemplo del uso de un carácter comodín para especificar mediante programación los dominios con los que la aplicación se puede comunicar.


<websocket:handlers allowed-origins="*">
<websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>


Utilizar * como el valor del encabezado Access-Control-Allow-Origin indica que los datos de la aplicación son accesibles para JavaScript que se ejecuta en cualquier dominio.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_overly_permissive_cors_policy
Abstract
El programa define una política de compartir recursos de origen cruzado (CORS) demasiado permisiva.
Explanation
Antes de HTML5, los exploradores web aplicaban la directiva de mismo origen, la cual garantiza que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web deben provenir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podía servir a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. HTML5 permite que JavaScript acceda a datos de diferentes dominios si se define un nuevo encabezado de HTTP llamado Access-Control-Allow-Origin. Con este encabezado, un servidor web define los dominios que pueden acceder a su dominio mediante solicitudes de origen cruzado. Sin embargo, tenga cuidado al definir el encabezado, ya que una directiva CORS demasiado laxa puede permitir que una aplicación malintencionada se comunique con la aplicación víctima de forma inapropiada y se produzcan ataques de suplantación, robo de datos y retransmisión, entre otros.

Ejemplo 1: El código siguiente es un ejemplo del uso de un carácter comodín para especificar mediante programación los dominios con los que la aplicación se puede comunicar.


<?php
header('Access-Control-Allow-Origin: *');
?>


Utilizar el * como el valor del encabezado de Access-Control-Allow-Origin indica que el JavaScript que se está ejecutando en cualquier dominio puede acceder a los datos de la aplicación.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.php.html5_overly_permissive_cors_policy
Abstract
El programa define una política de compartir recursos de origen cruzado (CORS) demasiado permisiva.
Explanation
Antes de HTML5, los exploradores web aplicaban la directiva de mismo origen, la cual garantiza que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web deben provenir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podría proporcionar JavaScript que cargue información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. HTML5 permite que JavaScript acceda a datos de diferentes dominios si se define un nuevo encabezado de HTTP llamado Access-Control-Allow-Origin. Con este encabezado, un servidor web define los dominios que pueden acceder a su dominio mediante solicitudes de origen cruzado. Sin embargo, tenga cuidado al definir el encabezado, ya que una directiva CORS demasiado laxa puede permitir que una aplicación malintencionada se comunique con la aplicación víctima de forma inapropiada y se produzcan ataques de suplantación, robo de datos y retransmisión, entre otros.

Ejemplo 1: El código siguiente es un ejemplo del uso de un carácter comodín para especificar mediante programación los dominios con los que la aplicación se puede comunicar.


response.addHeader("Access-Control-Allow-Origin", "*")


Utilizar el * como el valor del encabezado de Access-Control-Allow-Origin indica que el JavaScript que se ejecuta en cualquier dominio puede acceder a los datos de la aplicación.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.python.html5_overly_permissive_cors_policy
Abstract
El programa define una política de uso compartido de recursos entre orígenes (CORS) demasiado permisiva.
Explanation
Antes de HTML5, los exploradores web aplicaban la directiva de mismo origen, la cual garantiza que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web deben provenir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podría proporcionar JavaScript que cargue información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. HTML5 permite que JavaScript acceda a datos de diferentes dominios si se define un nuevo encabezado de HTTP llamado Access-Control-Allow-Origin. Con este encabezado, un servidor web define los dominios que pueden acceder a su dominio mediante solicitudes de origen cruzado. Sin embargo, tenga cuidado al definir el encabezado, ya que una directiva CORS demasiado laxa puede permitir que una aplicación malintencionada se comunique con la aplicación víctima de forma inapropiada y se produzcan ataques de suplantación, robo de datos y retransmisión, entre otros.

Ejemplo 1: A continuación, se muestra un ejemplo sobre cómo utilizar un carácter comodín para especificar con qué dominios se puede comunicar la aplicación.


play.filters.cors {
pathPrefixes = ["/some/path", ...]
allowedOrigins = ["*"]
allowedHttpMethods = ["GET", "POST"]
allowedHttpHeaders = ["Accept"]
preflightMaxAge = 3 days
}


El uso de * como valor del encabezado de Access-Control-Allow-Origin indica que el JavaScript que se ejecute en cualquier dominio podrá acceder a los datos de la aplicación.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.scala.html5_overly_permissive_cors_policy
Abstract
El programa define una política de compartir recursos de origen cruzado (CORS) demasiado permisiva.
Explanation
Antes de HTML5, los exploradores web aplicaban la directiva de mismo origen, la cual garantiza que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web deben provenir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podía servir a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. HTML5 permite que JavaScript acceda a datos de diferentes dominios si se define un nuevo encabezado de HTTP llamado Access-Control-Allow-Origin. Con este encabezado, un servidor web define los dominios que pueden acceder a su dominio mediante solicitudes de origen cruzado. Sin embargo, tenga cuidado al definir el encabezado, ya que una directiva CORS demasiado laxa puede permitir que una aplicación malintencionada se comunique con la aplicación víctima de forma inapropiada y se produzcan ataques de suplantación, robo de datos y retransmisión, entre otros.

Ejemplo 1: El código siguiente es un ejemplo del uso de un carácter comodín para especificar mediante programación los dominios con los que la aplicación se puede comunicar.


Response.AddHeader "Access-Control-Allow-Origin", "*"


Utilizar el * como el valor del encabezado de Access-Control-Allow-Origin indica que el JavaScript que se está ejecutando en cualquier dominio puede acceder a los datos de la aplicación.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.vb.html5_overly_permissive_cors_policy
Abstract
El programa devuelve un mensaje entre documentos con un origen de destino demasiado permisivo.
Explanation
Una de las nuevas características de HTML5 son los mensajes entre documentos. Esta función permite que las secuencias devuelvan mensajes en otras ventanas. La API correspondiente permite al usuario especificar el origen de la ventana de destino. No obstante, se debe prestar especial atención a la hora de especificar el origen de destino, dado que un origen de destino demasiado permisivo hará posible que un script malicioso pueda comunicarse con la ventana en cuestión de forma inapropiada, lo que permitiría la suplantación de identidad, el robo de datos, la retransmisión y otras formas de ataque.

Ejemplo 1: el siguiente ejemplo utiliza un carácter comodín para especificar mediante programación el origen de destino del mensaje que se va a enviar.


WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
webview.postWebMessage(message, Uri.parse("*"));


Utilizando el * como el valor del origen de destino, se indica que la secuencia envía un mensaje a una ventana independientemente de su origen.
References
[1] Michael Schmidt HTML5 Web Security
[2] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[3] Standards Mapping - Common Weakness Enumeration CWE ID 942
[4] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[5] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[11] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[12] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
desc.controlflow.java.html5_overly_permissive_message_posting_policy
Abstract
El programa devuelve un mensaje entre documentos con un origen de destino demasiado permisivo.
Explanation
Una de las nuevas características de HTML5 son los mensajes entre documentos. Esta función permite que las secuencias devuelvan mensajes en otras ventanas. La API correspondiente permite al usuario especificar el origen de la ventana de destino. No obstante, se debe prestar especial atención a la hora de especificar el origen de destino, dado que un origen de destino demasiado permisivo hará posible que un script malicioso pueda comunicarse con la ventana en cuestión de forma inapropiada, lo que permitiría la suplantación de identidad, el robo de datos, la retransmisión y otras formas de ataque.

Ejemplo 1: el siguiente ejemplo utiliza un carácter comodín para especificar mediante programación el origen de destino del mensaje que se va a enviar.


o.contentWindow.postMessage(message, '*');


Utilizando el * como el valor del origen de destino, se indica que la secuencia envía un mensaje a una ventana independientemente de su origen.
References
[1] Michael Schmidt HTML5 Web Security
[2] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[3] Standards Mapping - Common Weakness Enumeration CWE ID 942
[4] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[5] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[11] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[12] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
desc.structural.javascript.html5_overly_permissive_message_posting_policy
Abstract
Si se establece el encabezado Referrer-Policy en Unsafe-URL, es posible que las aplicaciones expongan datos confidenciales del sitio y del usuario (incluidos tokens de sesión, nombres de usuario y contraseñas) a sitios de terceros.
Explanation
De forma predeterminada, los exploradores no envían el encabezado de referencia con las solicitudes originadas desde HTTPS a vínculos HTTP sin cifrar. Sin embargo, cuando el destino de una solicitud también es HTTPS, se envía el encabezado independientemente del origen. Un desarrollador puede dejar información confidencial en las URL, las cuales se exponen a sitios de terceros mediante el encabezado de referencia. El encabezado Referrer-Policy se introduce para controlar el comportamiento del explorador en relación con el encabezado de referencia. La opción Unsafe-URL elimina todas las restricciones y envía el encabezado de referencia con cada solicitud.

Ejemplo 1: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar la directiva de referencia segura predeterminada:

<http auto-config="true">
...
<headers>
...
<referrer-policy policy="unsafe-url"/>
</headers>
</http>
References
[1] Referrer-Policy
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - Common Weakness Enumeration CWE ID 942
[4] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[5] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002418, CCI-002420, CCI-002421, CCI-002422
[7] Standards Mapping - FIPS200 CM
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[31] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3250.1 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3250.1 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3250.1 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3250.1 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3250.1 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.html5_overly_permissive_referrer_policy
Abstract
La directiva de seguridad de contenido (CSP) se configura en el modo de supervisión, lo que significa que el explorador no la aplica.
Explanation
La directiva de seguridad de contenido (CSP) es un encabezado de seguridad declarativo que permite a los desarrolladores establecer los dominios en los que el sitio puede cargar contenido o con los que puede inicializar conexiones cuando se procesa en el explorador web. Esta directiva proporciona una capa de seguridad adicional contra vulnerabilidades críticas, como los ataques Cross-Site Scripting, el secuestro de clics (clickjacking), el acceso de origen cruzado y similares, por encima de la validación de entrada y la comprobación de listas de permitidos en el código.

El encabezado Content-Security-Policy-Report-Only brinda la capacidad para que los administradores y los autores de aplicaciones web supervisen las directivas de seguridad, en lugar de aplicarlas. Generalmente, este encabezado se utiliza mientras se desarrollan o se prueban directivas de seguridad para un sitio. Cuando se considera que una directiva es efectiva, es posible utilizar el encabezado Content-Security-Policy para aplicarla.

Ejemplo 1: El siguiente código establece una directiva de seguridad de contenido en el modo Report-Only:

<http auto-config="true">
...
<headers>
...
<content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
</headers>
</http>
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_unenforced_content_security_policy
Abstract
Una directiva de seguridad de contenido (CSP) se configura en el modo de supervisión, lo que significa que el explorador no la aplica.
Explanation
Una directiva de seguridad de contenido (CSP) es un encabezado de seguridad declarativo que permite a los desarrolladores establecer los dominios en los que el sitio puede cargar contenido o con los que puede inicializar conexiones cuando se procesa en el explorador web. Esta directiva proporciona una capa de seguridad adicional contra vulnerabilidades críticas, como los ataques Cross-Site Scripting, el secuestro de clics (clickjacking), y el acceso de origen cruzado, además de la validación de entrada y la comprobación de listas de permitidos en el código.

El encabezado Content-Security-Policy-Report-Only brinda la capacidad para que los administradores y los autores de aplicaciones web supervisen las directivas de seguridad, en lugar de aplicarlas. Generalmente, este encabezado se utiliza mientras se desarrollan o se prueban directivas de seguridad para un sitio. Cuando se considera que una directiva es efectiva, es posible utilizar el encabezado Content-Security-Policy para aplicarla en su lugar.

Ejemplo 1: El siguiente código establece una directiva de seguridad de contenido en el modo Report-Only:

response.content_security_policy_report_only = "*"
References
[1] OWASP Content Security Policy
[2] W3C Content Security Policy 1.1
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_unenforced_content_security_policy
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

Solo puede obtener los datos del primer parámetro
Puede obtener los datos del último parámetro
Puede obtener los datos de todos los parámetros y concatenarlos juntos


Por ejemplo:
- ASP.NET/IIS utiliza todas las apariciones de los parámetros
- Apache Tomcat utiliza solo la primera aparición e ignora las demás.
- mod_perl/Apache convierte el valor en una matriz de valores

Ejemplo 1: según el servidor de aplicaciones y la lógica de la propia aplicación, la siguiente solicitud podría provocar confusión en el sistema de autenticación y permitir que un atacante suplante a otro usuario.
http://www.server.com/login.aspx?name=alice&name=hacker

Ejemplo 2: el siguiente código utiliza la entrada de una solicitud HTTP para representar dos hipervínculos.

...
String lang = Request.Form["lang"];
WebClient client = new WebClient();
client.BaseAddress = url;
NameValueCollection myQueryStringCollection = new NameValueCollection();
myQueryStringCollection.Add("q", lang);
client.QueryString = myQueryStringCollection;
Stream data = client.OpenRead(url);
...


URL: http://www.host.com/election.aspx?poll_id=4567
Link1: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=en">inglés<a>
Link2: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=es">español<a>

El programador no ha tenido en cuenta la posibilidad de que un atacante proporcione un lang como en&poll_id=1 y después pueda modificar el poll_id a su antojo.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.http_parameter_pollution
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

Solo puede obtener los datos del primer parámetro
Puede obtener los datos del último parámetro
Puede obtener los datos de todos los parámetros y concatenarlos juntos


Por ejemplo:
- ASP.NET/IIS utiliza todas las apariciones de los parámetros
- Apache Tomcat utiliza solo la primera aparición e ignora las demás.
- mod_perl/Apache convierte el valor en una matriz de valores

Ejemplo 1: según el servidor de aplicaciones y la lógica de la propia aplicación, la siguiente solicitud podría provocar confusión en el sistema de autenticación y permitir que un atacante suplante a otro usuario.
http://www.example.com/login.php?name=alice&name=hacker

Ejemplo 2: el siguiente código utiliza la entrada de una solicitud HTTP para representar dos hipervínculos.

...
String lang = request.getParameter("lang");
GetMethod get = new GetMethod("http://www.example.com");
get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
get.execute();
...


URL: http://www.example.com?poll_id=4567
Link1: <a href="001">English<a>
Link2: <a href="002">Español<a>

El programador no ha tenido en cuenta la posibilidad de que un atacante proporcione un lang como en&poll_id=1 y después modifique poll_id a su antojo.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.http_parameter_pollution
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

Solo puede obtener los datos del primer parámetro
Puede obtener los datos del último parámetro
Puede obtener los datos de todos los parámetros y concatenarlos juntos


Por ejemplo:
- ASP.NET/IIS utiliza todas las apariciones de los parámetros
- Apache Tomcat utiliza solo la primera aparición e ignora las demás.
- mod_perl/Apache convierte el valor en una matriz de valores

Ejemplo 1: según el servidor de aplicaciones y la lógica de la propia aplicación, la siguiente solicitud podría provocar confusión en el sistema de autenticación y permitir que un atacante suplante a otro usuario.
http://www.server.com/login.php?name=alice&name=hacker

Ejemplo 2: el siguiente código utiliza la entrada de una solicitud HTTP para representar dos hipervínculos.


<%
...
$id = $_GET["id"];
header("Location: http://www.host.com/election.php?poll_id=" . $id);
...
%>


URL: http://www.host.com/election.php?poll_id=4567
Link1: <a href="vote.php?poll_id=4567&candidate=white">Vote al Sr. Pérez<a>
Link2: <a href="vote.php?poll_id=4567&candidate=green">Vote a la Sra. González<a>

El programador no ha pensado en la posibilidad de que un usuario malintencionado proporcione un identificador de voto (poll_id) como "4567&candidato=gonzález" y, entonces, la página resultante contenga los siguientes vínculos insertados y, por tanto, la Sra. González reciba los votos en un servidor de aplicaciones que recopile el primer parámetro.
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">Vote al Sr. Pérez<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Vote a la Sra. González<a>
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.http_parameter_pollution
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

Solo puede obtener los datos del primer parámetro
Puede obtener los datos del último parámetro
Puede obtener los datos de todos los parámetros y concatenarlos juntos


Por ejemplo:
- ASP.NET/IIS utiliza todas las apariciones de los parámetros
- Apache Tomcat utiliza solo la primera aparición e ignora las demás.
- mod_perl/Apache convierte el valor en una matriz de valores

Ejemplo 1: según el servidor de aplicaciones y la lógica de la propia aplicación, la siguiente solicitud podría provocar confusión en el sistema de autenticación y permitir que un usuario malintencionado suplante a otro usuario.
http://www.server.com/login.php?name=alice&name=hacker

Como se muestra aquí, el usuario malintencionado ya ha especificado name=alice, pero ha agregado un name=alice& adicional, y si se utiliza en un servidor que tome la primera repetición, podría suplantar a alice para obtener más información sobre su cuenta.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.http_parameter_pollution
Abstract
Las restricciones de seguridad que especifican los verbos HTTP permiten a menudo más acceso del previsto.
Explanation
Los mecanismos de autenticación y autorización de una aplicación se pueden omitir con la manipulación del verbo HTTP cuando:
1) Se usa un control de seguridad que enumera los verbos HTTP.
2) El control de seguridad no bloquea los verbos que no figuran en la lista.
3) La aplicación actualiza su estado en función de las solicitudes GET u otros verbos HTTP arbitrarios.



La siguiente configuración es vulnerable a la manipulación de verbos HTTP:

<authorization>
<allow verbs="GET,POST" users="admin"/>
<deny verbs="GET,POST"users="*" />
</authorization>

Por defecto, el marco .NET admite todos los verbos HTTP, por lo que aunque esta configuración sí rechaza solicitudes GET y POST a todos los usuarios, no detiene solicitudes HEAD. Es posible que un atacante ejecute funciones administrativas sustituyendo las solicitudes GET o POST por solicitudes HEAD. En otras palabras, este código cumple las condiciones 1 y 2 anteriores. Todo lo que queda para que las solicitudes HEAD puedan ejecutar funciones administrativas es que la aplicación ejecute comandos en las solicitudes que contengan verbos distintos de POST.

En esencia, esta vulnerabilidad es el resultado de un intento de crear una lista de denegación, una directiva que especifica lo que los usuarios no pueden hacer. Las listas denegación rara vez logran el efecto deseado.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 288, CWE ID 302
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [25] CWE ID 306
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[13] Standards Mapping - OWASP API 2023 API5 Broken Function Level Authorization
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
[48] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.config.dotnet.http_verb_tampering
Abstract
Las restricciones de seguridad que especifican los verbos HTTP permiten a menudo más acceso del previsto.
Explanation
Los mecanismos de autenticación y autorización de una aplicación se pueden omitir con la manipulación del verbo HTTP cuando:
1) Se usa un control de seguridad que enumera los verbos HTTP.
2) El control de seguridad no bloquea los verbos que no figuran en la lista.
3) La aplicación actualiza su estado en función de las solicitudes GET u otros verbos HTTP arbitrarios.



La mayoría de las implementaciones de Java EE permiten métodos HTTP que no se enumeran explícitamente en la configuración. Por ejemplo, la siguiente restricción de seguridad se aplica al método HTTP GET pero no a otros verbos HTTP:


<security-constraint>
<display-name>Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>Admin Area</web-resource-name>
<url-pattern>/pages/index.jsp</url-pattern>
<url-pattern>/admin/*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>only admin</description>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>


Dado que los verbos como HEAD no se definen explícitamente en una etiqueta <http-method> en esta configuración, es posible ejercer la funcionalidad administrativa sustituyendo las solicitudes GET o POST por solicitudes HEAD. Para que las solicitudes HEAD ejerzan funcionalidad administrativa, se debe cumplir la condición 3: la aplicación debe ejecutar comandos basados en verbos distintos de POST. Algunos servidores web/de aplicaciones aceptarán verbos HTTP no estándar arbitrarios y responderán como si se les hubiera dado una solicitud GET. Si ese es el caso, un atacante podría ver páginas administrativas usando un verbo arbitrario en una solicitud.

Por ejemplo, las solicitudes GET de cliente normalmente son así:

GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com


En un ataque de manipulación de verbos HTTP, un atacante sustituiría GET por algo como FOO.

FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com


En esencia, esta vulnerabilidad es el resultado de un intento de crear una lista de denegación, una directiva que especifica lo que los usuarios no pueden hacer. Las listas denegación rara vez logran el efecto deseado.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 288, CWE ID 302
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [25] CWE ID 306
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[13] Standards Mapping - OWASP API 2023 API5 Broken Function Level Authorization
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
[48] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.config.java.http_verb_tampering
Abstract
La clase está anotada como inmutable, pero un campo está mutado.
Explanation
A esta clase se le ha dado la anotación de Inmutable, desde el paquete de anotaciones de JCIP. Sin embargo, uno de los campos mutables de la clase presenta un método de mutación al que se llama desde fuera del constructor y el destructor.

Ejemplo 1: el siguiente código para una clase final inmutable declara un Set como private y final y, a continuación, crea erróneamente un método que modifica el Set.


@Immutable
public final class ThreeStooges {
private final Set stooges = new HashSet>();
...

public void addStooge(String name) {
stooges.add(name);
}
...
}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] MUTABLE-1: Prefer immutability for value types Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 471
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_field_mutation
Abstract
La clase se ha anotado como inmutable, pero un campo no es final.
Explanation
A esta clase se le ha dado la anotación de Immutable, desde el paquete de anotaciones de JCIP. Un campo no final infringe la inmutabilidad de la clase al permitir la modificación del valor.

Ejemplo 1: el siguiente código de una clase inmutable declara de forma incorrecta un campo public y no final.


@Immutable
public class ImmutableInteger {
public int value;

}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] OBJ58-J. Limit the extensibility of classes and methods with invariants CERT
[4] MUTABLE-1: Prefer immutability for value types Oracle
[5] Standards Mapping - Common Weakness Enumeration CWE ID 471
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[18] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_non_final_fields
Abstract
La clase se ha anotado como inmutable, pero un campo se ha modificado.
Explanation
A esta clase se le ha dado la anotación de Inmutable, desde el paquete de anotaciones de JCIP. Un campo público de tipo mutable permite que el código externo a la clase modifique el contenido e infrinja la inmutabilidad de la clase.

Ejemplo 1: el código siguiente para una clase final inmutable declara erróneamente un Set como public y final.


@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] MUTABLE-1: Prefer immutability for value types Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 471
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_public_mutable_fields
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
DATA: r TYPE REF TO cl_abap_random,
var1 TYPE i,
var2 TYPE i,
var3 TYPE n.


GET TIME.
var1 = sy-uzeit.
r = cl_abap_random=>create( seed = var1 ).
r->int31( RECEIVING value = var2 ).
var3 = var2.
CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.


Este código utiliza la función CL_ABAP_RANDOM->INT31 para generar identificadores "únicos" para las páginas de recibos que crea. Como CL_ABAP_RANDOM es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 338
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[4] Standards Mapping - FIPS200 MP
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.abap.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


string GenerateReceiptURL(string baseUrl) {
Random Gen = new Random();
return (baseUrl + Gen.Next().toString() + ".html");
}


Este código utiliza la función Random.Next() para generar identificadores "únicos" para las páginas de recibos que crea. Como Random.Next() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] RandomNumberGenerator Class Microsoft
[2] System.Security.Cryptography Namespace Microsoft
[3] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[4] Standards Mapping - Common Weakness Enumeration CWE ID 338
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.dotnet.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


char* CreateReceiptURL() {
int num;
time_t t1;
char *URL = (char*) malloc(MAX_URL);
if (URL) {
(void) time(&t1);
srand48((long) t1); /* use time to set seed */
sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
}
return URL;
}


Este código utiliza la función lrand48() para generar identificadores "únicos" para las páginas de recibos que crea. Como lrand48() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también presenta errores, sería más seguro si utilizase un generador de números aleatorios que no crease identificadores de recepción predecibles.
References
[1] B. Schneier Yarrow: A secure pseudorandom number generator
[2] CryptLib
[3] Crypto++
[4] BeeCrypt
[5] OpenSSL
[6] CryptoAPI: CryptGenRandom() Microsoft
[7] RtlGenRandom() Microsoft
[8] .NET System.Security.Cryptography: Random Number Generation Microsoft
[9] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[10] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[11] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[12] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[13] Standards Mapping - Common Weakness Enumeration CWE ID 338
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[15] Standards Mapping - FIPS200 MP
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[21] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[22] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[24] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[25] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[26] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[27] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[40] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.cpp.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.


Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>


Este código utiliza la función Rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como Rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] ColdFusion Java CFX Reference Adobe
[2] Java Cryptography Architecture Oracle
[3] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[4] Standards Mapping - Common Weakness Enumeration CWE ID 338
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.cfml.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y, como tales, no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles. Sin embargo, su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una clave RSA.


import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)


Este código utiliza la función rand.New() a fin de generar aleatoridad para una clave RSA. Como rand.New() es un PRNG estadístico, es fácil que un atacante adivine los valores que genera.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 338
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[4] Standards Mapping - FIPS200 MP
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.golang.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


String GenerateReceiptURL(String baseUrl) {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return (baseUrl + ranGen.nextInt(400000000) + ".html");
}


Este código utiliza la función Random.nextInt() para generar identificadores "únicos" para las páginas de recibos que crea. Como Random.nextInt() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 338
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.java.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


function genReceiptURL (baseURL){
var randNum = Math.random();
var receiptURL = baseURL + randNum + ".html";
return receiptURL;
}


Este código utiliza la función Math.random() para generar identificadores "únicos" para las páginas de recibos que crea. Como Math.random() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Crypto | Node.js documentation The OpenJS Foundation and Node.js contributors
[3] Standards Mapping - Common Weakness Enumeration CWE ID 338
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[11] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[12] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.structural.javascript.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y, como tales, no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


fun GenerateReceiptURL(baseUrl: String): String {
val ranGen = Random(Date().getTime())
return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}


Este código utiliza la función Random.nextInt() para generar identificadores "únicos" para las páginas de recibos que cree. Como Random.nextInt() es un PRNG estadístico, es fácil que un atacante adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 338
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.kotlin.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


function genReceiptURL($baseURL) {
$randNum = rand();
$receiptURL = $baseURL . $randNum . ".html";
return $receiptURL;
}


Este código utiliza la función rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 338
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[4] Standards Mapping - FIPS200 MP
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.php.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
RETURN VARCHAR2
AS
rnum VARCHAR2(48);
time TIMESTAMP;
url VARCHAR2(MAX_URL)
BEGIN
time := SYSTIMESTAMP;
DBMS_RANDOM.SEED(time);
rnum := DBMS_RANDOM.STRING('x', 48);
url := 'http://test.com/' || rnum || '.html';
RETURN url;
END


Este código utiliza la función DBMS_RANDOM.SEED() para generar identificadores "únicos" para las páginas de recibos que crea. Como DBMS_RANDOM.SEED() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también presenta errores, sería más seguro si utilizase un generador de números aleatorios que no crease identificadores de recepción predecibles.
References
[1] Oracle Database Security Guide
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 338
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[11] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[12] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.sql.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


def genReceiptURL(self,baseURL):
randNum = random.random()
receiptURL = baseURL + randNum + ".html"
return receiptURL


Este código utiliza la función rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 338
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[4] Standards Mapping - FIPS200 MP
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.python.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


def generateReceiptURL(baseUrl) {
randNum = rand(400000000)
return ("#{baseUrl}#{randNum}.html");
}


Este código utiliza la función Kernel.rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como Kernel.rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 338
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[3] Standards Mapping - FIPS200 MP
[4] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[9] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[10] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[12] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[13] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.structural.ruby.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


def GenerateReceiptURL(baseUrl : String) : String {
val ranGen = new scala.util.Random()
ranGen.setSeed((new Date()).getTime())
return (baseUrl + ranGen.nextInt(400000000) + ".html")
}


Este código utiliza la función Random.nextInt() para generar identificadores "únicos" para las páginas de recibos que crea. Como Random.nextInt() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 338
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.scala.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y, como tales, no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El código siguiente usa un PRNG estadístico para crear un valor aleatorio que se usa como token de restablecimiento de contraseñas.


sqlite3_randomness(10, &reset_token)
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 338
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.swift.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...


Este código utiliza la función Rnd() para generar identificadores "únicos" para las páginas de recibos que crea. Como Rnd() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] CryptoAPI: CryptGenRandom() Microsoft
[3] Standards Mapping - Common Weakness Enumeration CWE ID 338
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[11] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[12] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.vb.insecure_randomness
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante.
Explanation
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (como la clase CL_ABAP_RANDOM o sus variantes) se inicializa con un valor constante específico, los valores devueltos por GET_NEXT, INT y métodos similares que devuelven o asignan valores son predecibles para un atacante que puede recopilar varios resultados de PRNG.

Ejemplo 1: En el siguiente extracto de código, los valores que produce el objeto random_gen2 son predecibles desde el objeto random_gen1.


DATA: random_gen1 TYPE REF TO cl_abap_random,
random_gen2 TYPE REF TO cl_abap_random,
var1 TYPE i,
var2 TYPE i.

random_gen1 = cl_abap_random=>create( seed = '1234' ).

DO 10 TIMES.
CALL METHOD random_gen1->int
RECEIVING
value = var1.

WRITE:/ var1.
ENDDO.

random_gen2 = cl_abap_random=>create( seed = '1234' ).

DO 10 TIMES.
CALL METHOD random_gen2->int
RECEIVING
value = var2.

WRITE:/ var2.
ENDDO.


En este ejemplo, los generadores de números pseudoaleatorios: random_gen1 y random_gen2 se inicializaron de forma idéntica, por lo que var1 = var2
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 336
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[4] Standards Mapping - FIPS200 MP
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[9] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[10] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[12] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[13] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.structural.abap.insecure_randomness_hardcoded_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante.
Explanation
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (como rand()) se inicializa con un valor específico (mediante una función como srand(unsigned int)), los valores devueltos por rand() y métodos similares que devuelven o asignan valores son predecibles para un usuario malintencionado que puede recopilar varios resultados de PRNG.

Ejemplo 1: Los valores que produce el generador de números pseudoaleatorios son predecibles en los dos primeros bloques porque ambos comienzan con el mismo valor de inicialización.


srand(2223333);
float randomNum = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum);
randomNum = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum);

srand(2223333);
float randomNum2 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum2);
randomNum2 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum2);

srand(1231234);
float randomNum3 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum3);
randomNum3 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum3);


En este ejemplo, los resultados de randomNum1 y randomNum2 se inicializan de manera idéntica, de modo que cada llamada a rand() después de la llamada que inicializa el generador de números pseudoaleatorios srand(2223333) producirá los mismos resultados en el mismo orden de llamada. Por ejemplo, la salida podría ser parecida a esta:


Random: 32.00
Random: 73.00
Random: 32.00
Random: 73.00
Random: 15.00
Random: 75.00


Estos resultados no son aleatorios en absoluto.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 336
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.cpp.insecure_randomness_hardcoded_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante.
Explanation
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (PRNG) se inicializa con un valor específico (usando funciones como math.Rand.New(Source)), los valores devueltos por math.Rand.Int() y otros métodos similares que devuelven o asignan valores son predecibles para un atacante que puede recopilar varios resultados de PRNG.

Ejemplo 1: Los valores que produce el generador de números pseudoaleatorios son predecibles en los dos primeros bloques porque ambos comienzan con el mismo valor de inicialización.


randomGen := rand.New(rand.NewSource(12345))
randomInt1 := randomGen.nextInt()

randomGen.Seed(12345)
randomInt2 := randomGen.nextInt()


En este ejemplo, los PRNG se inicializaron de forma idéntica, de modo que cada llamada a nextInt() después de la llamada que inicializó el generador de números pseudoaleatorios (randomGen.Seed(12345)), resulta en las mismas salidas y en el mismo orden.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] MSC02-J. Generate strong random numbers CERT
[3] MSC03-J. Never hard code sensitive information CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 336
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[11] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[12] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.golang.insecure_randomness_hardcoded_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante.
Explanation
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (como Random) se inicializa con un valor específico (usando una función como Random.setSeed()), los valores devueltos por Random.nextInt() y métodos similares que devuelven o asignan valores son predecibles para un atacante que puede recopilar varios resultados de PRNG.

Ejemplo 1: Los valores que produce el objeto RandomrandomGen2 son predecibles desde el objeto RandomrandomGen1.


Random randomGen1 = new Random();
randomGen1.setSeed(12345);
int randomInt1 = randomGen1.nextInt();
byte[] bytes1 = new byte[4];
randomGen1.nextBytes(bytes1);

Random randomGen2 = new Random();
randomGen2.setSeed(12345);
int randomInt2 = randomGen2.nextInt();
byte[] bytes2 = new byte[4];
randomGen2.nextBytes(bytes2);


En este ejemplo, los generadores de números pseudoaleatorios: randomGen1 y randomGen2 se inicializaron de forma idéntica, por lo que randomInt1 == randomInt2 y los valores correspondientes de las matrices bytes1[] y bytes2[] son iguales.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] MSC03-J. Never hard code sensitive information CERT
[5] Standards Mapping - Common Weakness Enumeration CWE ID 336
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.java.insecure_randomness_hardcoded_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante.
Explanation
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (como Random) se inicializa con un valor específico (usando una función como Random(Int)), los valores devueltos por Random.nextInt() y métodos similares que devuelven o asignan valores son predecibles para un atacante que puede recopilar varios resultados de PRNG.

Ejemplo 1: Los valores que produce el objeto RandomrandomGen2 son predecibles desde el objeto RandomrandomGen1.


val randomGen1 = Random(12345)
val randomInt1 = randomGen1.nextInt()
val byteArray1 = ByteArray(4)
randomGen1.nextBytes(byteArray1)

val randomGen2 = Random(12345)
val randomInt2 = randomGen2.nextInt()
val byteArray2 = ByteArray(4)
randomGen2.nextBytes(byteArray2)


En este ejemplo, los generadores de números pseudoaleatorios: randomGen1 y randomGen2 se inicializaron de forma idéntica, por lo que randomInt1 == randomInt2 y los valores correspondientes de las matrices byteArray1 y byteArray2 son iguales.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] MSC03-J. Never hard code sensitive information CERT
[5] Standards Mapping - Common Weakness Enumeration CWE ID 336
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.kotlin.insecure_randomness_hardcoded_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento de entero constante.
Explanation
A las funciones que generan valores pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento de entero constante. Si se inicializa un generador de números pseudoaleatorios con un valor específico, los valores devueltos son predecibles.

Ejemplo 1: Los valores que produce el generador de números pseudoaleatorios son predecibles en los dos primeros bloques porque ambos comienzan con el mismo valor de inicialización.


...
import random
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)

random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
...


En este ejemplo los PRNG se inicializaron de manera idéntica, de modo que cada llamada a randint() después de la llamada que inicializó el generador de números pseudoaleatorios (random.seed(123456)) generará los mismos resultados en la misma salida en el mismo orden. Por ejemplo, la salida podría ser parecida a esta:


Random: 81
Random: 80
Random: 3
Random: 81
Random: 80
Random: 3


Estos resultados no son aleatorios en absoluto.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 336
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.python.insecure_randomness_hardcoded_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante.
Explanation
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (como Random) se inicializa con un valor específico (usando una función como Random.setSeed()), los valores devueltos por Random.nextInt() y métodos similares que devuelven o asignan valores son predecibles para un atacante que puede recopilar varios resultados de PRNG.

Ejemplo 1: Los valores que produce el objeto RandomrandomGen2 son predecibles desde el objeto RandomrandomGen1.


val randomGen1 = new Random()
randomGen1.setSeed(12345)
val randomInt1 = randomGen1.nextInt()
val bytes1 = new byte[4]
randomGen1.nextBytes(bytes1)

val randomGen2 = new Random()
randomGen2.setSeed(12345)
val randomInt2 = randomGen2.nextInt()
val bytes2 = new byte[4]
randomGen2.nextBytes(bytes2)


En este ejemplo, los generadores de números pseudoaleatorios: randomGen1 y randomGen2 se inicializaron de forma idéntica, por lo que randomInt1 == randomInt2 y los valores correspondientes de las matrices bytes1[] y bytes2[] son iguales.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] MSC03-J. Never hard code sensitive information CERT
[5] Standards Mapping - Common Weakness Enumeration CWE ID 336
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.scala.insecure_randomness_hardcoded_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento contaminado.
Explanation
La clase CL_ABAP_RANDOM (o sus variantes) no deben inicializarse con un argumento contaminado. Al hacerlo, se permite que un usuario malintencionado controle el valor usado para inicializar el generador de números pseudoaleatorios y, por lo tanto, que pueda predecir la secuencia de valores producida por las llamadas a métodos como los siguientes: GET_NEXT, INT, FLOAT, PACKED.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 335
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.abap.insecure_randomness_user_controlled_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento contaminado.
Explanation
A las funciones que generan valores aleatorios o pseudoaleatorios (como rand()), a las que se pasa un valor de inicialización (como srand()), no se les debe llamar con un argumento contaminado. Al hacerlo, se permite que un usuario malintencionado controle el valor usado para inicializar el generador de números pseudoaleatorios y, por lo tanto, que pueda predecir la secuencia de valores (normalmente enteros) producida por las llamadas al generador de números pseudoaleatorios.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 335
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.cpp.insecure_randomness_user_controlled_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento contaminado.
Explanation
A las funciones que generan valores pseudoaleatorios, tales como ed25519.NewKeyFromSeed(), no se les debe llamar con un argumento contaminado. Si se hace, se permite que un usuario malintencionado controle el valor que se utiliza para inicializar el generador de números pseudoaleatorios, y así pueda predecir la secuencia de valores que producen las llamadas al generador de números pseudoaleatorios.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] MSC02-J. Generate strong random numbers CERT
[6] Standards Mapping - Common Weakness Enumeration CWE ID 335
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 MP
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.golang.insecure_randomness_user_controlled_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento de entero contaminado.
Explanation
Random.setSeed() no debe llamarse con un argumento de entero contaminado. Si se hace, se permite que un usuario malintencionado controle el valor que se utiliza para inicializar el generador de números pseudoaleatorios, y así pueda predecir la secuencia de valores (normalmente enteros) que producen las llamadas a Random.nextInt(), Random.nextShort(), Random.nextLong(), o que devuelve Random.nextBoolean() o que se establecen en Random.nextBytes(byte[]).
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[4] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[5] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[6] MSC02-J. Generate strong random numbers CERT
[7] Standards Mapping - Common Weakness Enumeration CWE ID 335
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 MP
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.java.insecure_randomness_user_controlled_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento de entero contaminado.
Explanation
Random.setSeed() no debe llamarse con un argumento de entero contaminado. Si se hace, se permite que un usuario malintencionado controle el valor que se utiliza para inicializar el generador de números pseudoaleatorios, y así pueda predecir la secuencia de valores (normalmente enteros) que producen las llamadas a Random.nextInt(), Random.nextLong(), Random.nextDouble(), o que devuelve Random.nextBoolean() o que se establecen en Random.nextBytes(ByteArray).
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[4] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[5] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[6] MSC02-J. Generate strong random numbers CERT
[7] Standards Mapping - Common Weakness Enumeration CWE ID 335
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 MP
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.kotlin.insecure_randomness_user_controlled_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento contaminado.
Explanation
Las funciones que generan valores pseudoaleatorios (como random.randint()) no se deben llamar con un argumento contaminado. Al hacerlo, se permite que un usuario malintencionado controle el valor usado para inicializar el generador de números pseudoaleatorios y, por lo tanto, que pueda predecir la secuencia de valores (normalmente enteros) producida por las llamadas al generador de números pseudoaleatorios.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 335
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.python.insecure_randomness_user_controlled_seed
Abstract
A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento de entero contaminado.
Explanation
Random.setSeed() no debe llamarse con un argumento de entero contaminado. Si se hace, se permite que un usuario malintencionado controle el valor que se utiliza para inicializar el generador de números pseudoaleatorios, y así pueda predecir la secuencia de valores (normalmente enteros) que producen las llamadas a Random.nextInt(), Random.nextShort(), Random.nextLong(), o que devuelve Random.nextBoolean() o que se establecen en Random.nextBytes(byte[]).
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[4] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[5] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[6] MSC02-J. Generate strong random numbers CERT
[7] Standards Mapping - Common Weakness Enumeration CWE ID 335
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 MP
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.scala.insecure_randomness_user_controlled_seed