45 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: 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 - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.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 3.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 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.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 3.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 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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: 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 - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.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 3.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 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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: 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 - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.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 3.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 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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: 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 - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[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 - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.2 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 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 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 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 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.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 3.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 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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: 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 - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.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 3.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 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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: 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 - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.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 3.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 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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: 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 - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.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 3.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 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.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 3.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 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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: 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 - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.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 3.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 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation_cookies
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: La configuración siguiente muestra el uso de un carácter comodín para especificar los dominios con los que la aplicación se puede comunicar.


<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>


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 - CIS Azure Kubernetes Service Benchmark 2
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - Common Weakness Enumeration CWE ID 942
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[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 - OWASP API 2023 API8 Security Misconfiguration
[20] 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)
[21] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[22] Standards Mapping - OWASP Mobile 2024 M8 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 2.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] 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
[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 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.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 - CIS Azure Kubernetes Service Benchmark 2
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - Common Weakness Enumeration CWE ID 942
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[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 - OWASP API 2023 API8 Security Misconfiguration
[20] 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)
[21] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[22] Standards Mapping - OWASP Mobile 2024 M8 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 2.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] 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
[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 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[47] 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 - CIS Azure Kubernetes Service Benchmark 2
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - Common Weakness Enumeration CWE ID 942
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[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 - OWASP API 2023 API8 Security Misconfiguration
[20] 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)
[21] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[22] Standards Mapping - OWASP Mobile 2024 M8 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 2.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] 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
[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 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[47] 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 - CIS Azure Kubernetes Service Benchmark 2
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - Common Weakness Enumeration CWE ID 942
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[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 - OWASP API 2023 API8 Security Misconfiguration
[20] 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)
[21] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[22] Standards Mapping - OWASP Mobile 2024 M8 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 2.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] 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
[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 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[47] 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 - CIS Azure Kubernetes Service Benchmark 2
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - Common Weakness Enumeration CWE ID 942
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[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 - OWASP API 2023 API8 Security Misconfiguration
[20] 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)
[21] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[22] Standards Mapping - OWASP Mobile 2024 M8 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 2.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] 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
[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 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[47] 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 - CIS Azure Kubernetes Service Benchmark 2
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - Common Weakness Enumeration CWE ID 942
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[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 - OWASP API 2023 API8 Security Misconfiguration
[20] 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)
[21] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[22] Standards Mapping - OWASP Mobile 2024 M8 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 2.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] 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
[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 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.vb.html5_overly_permissive_cors_policy
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: 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
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: 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
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: 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
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: 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
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: 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
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 muy 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: El siguiente archivo de configuración de Spring Boot utiliza un PRNG estadístico para crear un token sensible a la seguridad.


my.secret=${random.value}


Este código utiliza la función Random.next() para generar identificadores "únicos" para las páginas de recibos que cree. Como Random.next() 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
desc.config.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: 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] JavaScript crypto: window.crypto.random() Mozilla
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: 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
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: 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
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: 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
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: 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
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: 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.
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: 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
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: 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
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: 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
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 - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 336
[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 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 - 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)
[18] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[19] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[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.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 3.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 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.1 APSC-DV-002010 CAT II, APSC-DV-002050 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 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
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 - CIS Azure Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 336
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[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 - 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)
[21] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[22] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[33] 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
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 336
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[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 - 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)
[20] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[21] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 336
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[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 - 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)
[21] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[22] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[33] 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
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 336
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[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 - 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)
[21] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[22] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[33] 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
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 336
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[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 - 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)
[21] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[22] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[33] 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
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 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: 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 - CIS Azure Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 336
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[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 - 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)
[21] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[22] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[33] 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
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 335
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[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 - 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)
[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 - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[33] 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
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 335
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[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 - 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)
[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 - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[33] 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
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 335
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[13] Standards Mapping - FIPS200 MP
[14] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[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 - 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)
[22] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[23] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[34] 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
[35] 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
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[11] Standards Mapping - CIS Kubernetes Benchmark partial
[12] Standards Mapping - Common Weakness Enumeration CWE ID 335
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] 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)
[23] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[24] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 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 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[35] 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
[36] 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
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[11] Standards Mapping - CIS Kubernetes Benchmark partial
[12] Standards Mapping - Common Weakness Enumeration CWE ID 335
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] 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)
[23] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[24] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 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 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[35] 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
[36] 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
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 335
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[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 - 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)
[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 - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[33] 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
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 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 - CIS Azure Kubernetes Service Benchmark 1
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[11] Standards Mapping - CIS Kubernetes Benchmark partial
[12] Standards Mapping - Common Weakness Enumeration CWE ID 335
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] 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)
[23] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[24] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 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 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[35] 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
[36] 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
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.scala.insecure_randomness_user_controlled_seed
Abstract
La llamada utiliza un protocolo inseguro para comunicarse con el servidor.
Explanation
Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi. En estos casos, se debe utilizar un protocolo cifrado (seguro).

Ejemplo 1: En el siguiente ejemplo se envían datos mediante el protocolo HTTP (en lugar de usar HTTPS).


...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...


Es posible que el objeto de entrada HttpResponse, res, se haya visto comprometido, ya que se proporciona a través de un canal no cifrado ni autenticado.
References
[1] Designing for Security Android
[2] S. Fahl, M. Harbach, T. Muders, M. Smith, L. Baumgartner, B. Friesleben Why Eve and Mallory Love Android:An Analysis of Android SSL (In)Security
desc.structural.apex.insecure_transport
Abstract
La llamada utiliza un protocolo inseguro para comunicarse con el servidor.
Explanation
Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a ataques "man-in-the-middle" cuando los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: El siguiente código utiliza protocolo HTTP inseguro (en lugar de utilizar HTTPS):

var account = new CloudStorageAccount(storageCredentials, false);
desc.semantic.dotnet.insecure_transport
Abstract
La llamada utiliza un protocolo inseguro en vez de un protocolo seguro para comunicarse con el servidor.
Explanation
Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: En el siguiente ejemplo se leen datos mediante el protocolo HTTP (en lugar de usar HTTPS).


...
String url = 'http://10.0.2.2:11005/v1/key';
Response response = await get(url, headers: headers);
...


Es posible que la respuesta de entrada, response, se haya visto comprometida, ya que se proporciona a través de un canal no cifrado ni autenticado.
desc.dataflow.dart.insecure_transport
Abstract
La llamada utiliza un protocolo inseguro en vez de un protocolo seguro para comunicarse con el servidor.
Explanation
Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están expuestas a riesgos, especialmente en entornos donde los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras.

Ejemplo 1: El siguiente ejemplo configura un servidor web mediante el protocolo HTTP (en lugar de HTTPS).


helloHandler := func(w http.ResponseWriter, req *http.Request) {
io.WriteString(w, "Hello, world!\n")
}

http.HandleFunc("/hello", helloHandler)
log.Fatal(http.ListenAndServe(":8080", nil))
desc.semantic.golang.insecure_transport
Abstract
La aplicación usa un protocolo inseguro en vez de un protocolo seguro para comunicarse con el servidor.
Explanation
Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: El siguiente archivo de configuración de Spring Boot deshabilita el protocolo TLS y, por lo tanto, usa el protocolo HTTP.


server.ssl.enabled=false
Ejemplo 2: El siguiente archivo de configuración de Spring requiere el uso del protocolo HTTP.


<intercept-url pattern="/member/**" access="ROLE_USER" requires-channel="http"/>
References
[1] Designing for Security Android
[2] S. Fahl, M. Harbach, T. Muders, M. Smith, L. Baumgartner, B. Friesleben Why Eve and Mallory Love Android:An Analysis of Android SSL (In)Security
[3] OWASP Mobile Security Testing Guide OWASP
[4] MSC00-J. Use SSLSocket rather than Socket for secure data exchange CERT
desc.config.java.insecure_transport
Abstract
La llamada utiliza un protocolo inseguro en vez de un protocolo seguro para comunicarse con el servidor.
Explanation
Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: En el siguiente ejemplo, se leen datos mediante el protocolo HTTP (en lugar de usar HTTPS).


var http = require('http');
...
http.request(options, function(res){
...
});
...


Es posible que el objeto de entrada http.IncomingMessage, res, se haya visto comprometido debido que se proporciona a través de un canal sin cifrar ni autenticar.
References
[1] Designing for Security Android
[2] S. Fahl, M. Harbach, T. Muders, M. Smith, L. Baumgartner, B. Friesleben Why Eve and Mallory Love Android:An Analysis of Android SSL (In)Security
desc.structural.javascript.insecure_transport
Abstract
La llamada utiliza el protocolo HTTP en vez de HTTPS para enviar datos al servidor.
Explanation
Todos los datos enviados a través de HTTP se envían en texto sin cifrar y expuestos a peligros.

Ejemplo 1: en el siguiente ejemplo se envían datos a través del protocolo HTTP (en lugar de HTTPS).


NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];
References
[1] Apple Secure Coding Guide Apple
desc.dataflow.objc.insecure_transport
Abstract
La llamada utiliza un protocolo inseguro en vez de un protocolo seguro para comunicarse con el servidor.
Explanation
Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están expuestas a riesgos, especialmente en entornos donde los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras.

Ejemplo 1: El siguiente ejemplo deshabilita el cifrado en un socket.


...
stream_socket_enable_crypto($fp, false);
...
desc.semantic.php.insecure_transport
Abstract
El código utiliza un método no seguro para la comunicación.
Explanation
Toda la comunicación enviada con un protocolo de texto no seguro sin formato o sin cifrar puede estar en peligro.
desc.semantic.python.insecure_transport
Abstract
La llamada utiliza una conexión no cifrada en lugar de una conexión cifrada para comunicarse con el servidor.
Explanation
Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, está sujeto a compromiso.

Ejemplo 1: En el siguiente ejemplo, se leen datos mediante el protocolo HTTP (en lugar de usar HTTPS).


require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...


Es posible que la secuencia de entrada, in, se haya visto comprometida, ya que se proporciona a través de un canal no cifrado ni autenticado.
desc.structural.ruby.insecure_transport
Abstract
La llamada utiliza un protocolo inseguro en vez de un protocolo seguro para comunicarse con el servidor.
Explanation
Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: En el siguiente ejemplo se leen datos mediante el protocolo HTTP (en lugar de usar HTTPS).


val url = Uri.from(scheme = "http", host = "192.0.2.16", port = 80, path = "/")
val responseFuture: Future[HttpResponse] = Http().singleRequest(HttpRequest(uri = url))


Es posible que la respuesta de entrada, responseFuture, se haya visto comprometida, ya que se proporciona a través de un canal no cifrado ni autenticado.
References
[1] Designing for Security Android
[2] S. Fahl, M. Harbach, T. Muders, M. Smith, L. Baumgartner, B. Friesleben Why Eve and Mallory Love Android:An Analysis of Android SSL (In)Security
[3] MSC00-J. Use SSLSocket rather than Socket for secure data exchange CERT
desc.semantic.scala.insecure_transport
Abstract
La llamada utiliza el protocolo HTTP en vez de HTTPS para enviar datos al servidor.
Explanation
Todos los datos enviados a través de HTTP se envían en texto sin cifrar y expuestos a peligros.

Ejemplo 1: en el siguiente ejemplo se envían datos a través del protocolo HTTP (en lugar de HTTPS).


let USER_URL = "http://localhost:8080/igoat/user"
let request : NSMutableURLRequest = NSMutableURLRequest(URL:NSURL(string:USER_URL))
let conn : NSURLConnection = NSURLConnection(request:request, delegate:self)
References
[1] Apple Secure Coding Guide Apple
desc.dataflow.swift.insecure_transport
Abstract
JSONP es una técnica de comunicación insegura que solo debería utilizarse cuando no haya datos personales ni confidenciales implicados e inmunizando la función de devolución de llamada.
Explanation
Debido a su diseño, JSONP permite realizar solicitudes entre dominios pero carece de todo mecanismo para restringir o verificar el origen de las solicitudes. Un sitio malintencionado puede realizar fácilmente una solicitud JSONP en nombre del usuario y procesar la respuesta JSON. Por este motivo, se recomienda encarecidamente evitar esta técnica de comunicación cuando se envíen datos confidenciales o información personalmente identificable.
Debido a su diseño, JSONP es un ataque XSS autoinfligido, ya que para un procesamiento JSON adecuado es necesario que el nombre de la función de devolución de llamada se refleje en el sitio solicitante. Es obligatorio validar e inmunizar el nombre de la función de devolución de llamada para evitar la inyección de JavaScript. Con el fin de inmunizar el nombre de la función de devolución de llamada, considere la posibilidad de crear una lista de caracteres permitidos, cuando sea posible, o admita únicamente caracteres alfanuméricos.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 346
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.javascript_hijacking_jsonp
Abstract
JSONP es una técnica de comunicación insegura que solo debería utilizarse cuando no haya datos personales ni confidenciales implicados.
Explanation
Debido a su diseño, JSONP permite realizar solicitudes entre dominios pero carece de todo mecanismo para restringir y verificar el origen de las solicitudes. Un sitio malintencionado puede realizar fácilmente una solicitud JSONP en nombre del usuario y procesar la respuesta JSON. Por este motivo, se recomienda encarecidamente evitar esta técnica de comunicación cuando se envíen datos confidenciales o información de identificación personal.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 346
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.scala.javascript_hijacking_jsonp