6 elementos encontrados
Debilidades
Abstract
El programa infringe la especificación de Enterprise JavaBeans al emplear AWT/Swing.
Explanation
La especificación de Enterprise JavaBeans exige que todos los proveedores de bean sigan una serie de instrucciones de programación diseñadas para garantizar que el bean sea portátil y se comporte de forma coherente en cualquier contenedor EJB [1].

En este caso, el programa infringe la siguiente instrucción EJB:

"Un enterprise bean no debe usar la funcionalidad AWT para tratar de mostrar información en una pantalla, o para introducir información desde un teclado".

Se trata de un requisito que la especificación justifica de la siguiente forma:

"La mayoría de los servidores no permiten la interacción directa entre un programa de aplicación y un teclado o una pantalla conectados al sistema del servidor".
References
[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems
[2] Standards Mapping - Common Weakness Enumeration CWE ID 575
desc.structural.java.ejb_bad_practices_use_of_awt_swing
Abstract
El programa infringe la especificación de Enterprise JavaBeans al emplear el cargador de clases.
Explanation
La especificación de Enterprise JavaBeans exige que todos los proveedores de bean sigan una serie de instrucciones de programación diseñadas para garantizar que el bean sea portátil y se comporte de forma coherente en cualquier contenedor EJB [1].

En este caso, el programa infringe la siguiente instrucción EJB:

"Enterprise bean no debe intentar crear un cargador de clases, obtener el cargador de clases actual, establecer el cargador de clases de contexto, establecer el administrador de seguridad, crear un nuevo administrador de seguridad, detener el JVM ni cambiar los flujos de entrada, salida y error".

Se trata de un requisito que la especificación justifica de la siguiente forma:

"Estas funciones se reservan para el contenedor EJB. Permitir a enterprise bean usar estas funciones podría comprometer la seguridad y reducir la capacidad del contenedor de administrar adecuadamente el entorno de tiempo de ejecución".
References
[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems
[2] Standards Mapping - Common Weakness Enumeration CWE ID 578
desc.structural.java.ejb_bad_practices_use_of_classloader
Abstract
El programa infringe la especificación de Enterprise JavaBeans al emplear el paquete java.io.
Explanation
La especificación de Enterprise JavaBeans exige que todos los proveedores de bean sigan una serie de instrucciones de programación diseñadas para garantizar que el bean sea portátil y se comporte de forma coherente en cualquier contenedor EJB [1].

En este caso, el programa infringe la siguiente instrucción EJB:

"Un enterprise bean no debe usar el paquete java.io para tratar de acceder a archivos y directorios del sistema de archivos".

Se trata de un requisito que la especificación justifica de la siguiente forma:

"Las API del sistema de archivos no son adecuadas para que los componentes de negocio accedan a los datos. Los componentes de negocio deben usar una API de administrador de recursos, como JDBC, para almacenar los datos".
References
[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems
[2] Standards Mapping - Common Weakness Enumeration CWE ID 576
desc.structural.java.ejb_bad_practices_use_of_java_io
Abstract
El programa infringe la especificación de Enterprise JavaBeans al emplear sockets.
Explanation
La especificación de Enterprise JavaBeans exige que todos los proveedores de bean sigan una serie de instrucciones de programación diseñadas para garantizar que el bean sea portátil y se comporte de forma coherente en cualquier contenedor EJB [1].

En este caso, el programa infringe la siguiente instrucción EJB:

"Un enterprise bean no debe intentar escuchar en un socket, aceptar conexiones en un socket ni utilizar un socket para multidifusión".

Se trata de un requisito que la especificación justifica de la siguiente forma:

"La arquitectura EJB permite a una instancia de enterprise bean ser un cliente de socket de red, pero no le permite ser un servidor de red. Permitir que la instancia se convierta en un servidor de red podría hacer que entrara en conflicto con la función básica de enterprise bean para servir a los clientes EJB".
References
[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems
[2] Standards Mapping - Common Weakness Enumeration CWE ID 577
desc.structural.java.ejb_bad_practices_use_of_sockets
Abstract
El programa infringe la especificación de Enterprise JavaBeans al usar primitivos de sincronización de subprocesos.
Explanation
La especificación de Enterprise JavaBeans exige que todos los proveedores de bean sigan una serie de instrucciones de programación diseñadas para garantizar que el bean sea portátil y se comporte de forma coherente en cualquier contenedor EJB [1].

En este caso, el programa infringe la siguiente instrucción EJB:

"Un enterprise bean no debe usar primitivos de sincronización de subprocesos para sincronizar la ejecución de varias instancias".

Se trata de un requisito que la especificación justifica de la siguiente forma:

"Esta regla es necesaria para garantizar una semántica de tiempo de ejecución coherente, porque mientras algunos contenedores EJB pueden usar un solo JVM para ejecutar todas las instancias de enterprise bean, otros podrían distribuir las instancias entre varios JVM".
References
[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems
[2] THI01-J. Do not invoke ThreadGroup methods CERT
[3] Standards Mapping - Common Weakness Enumeration CWE ID 574
desc.structural.java.ejb_bad_practices_use_of_synchronization_primitives
Abstract
El método escribe una entrada sin validar en JSON. Esta llamada puede permitir a un atacante insertar elementos o atributos de forma arbitraria en la entidad JSON.
Explanation
La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.

Ejemplo 1: el siguiente código C# utiliza JSON.NET para serializar la información de autenticación de las cuentas de usuario para los usuarios sin privilegios (aquellos con un rol "predeterminado" a diferencia de los usuarios con privilegios con un rol de "admin") a partir de las variables de entrada controladas por el usuario username y password al archivo JSON ubicado en C:\user_info.json:


...

StringBuilder sb = new StringBuilder();
StringWriter sw = new StringWriter(sb);

using (JsonWriter writer = new JsonTextWriter(sw))
{
writer.Formatting = Formatting.Indented;

writer.WriteStartObject();

writer.WritePropertyName("role");
writer.WriteRawValue("\"default\"");

writer.WritePropertyName("username");
writer.WriteRawValue("\"" + username + "\"");

writer.WritePropertyName("password");
writer.WriteRawValue("\"" + password + "\"");

writer.WriteEndObject();
}

File.WriteAllText(@"C:\user_info.json", sb.ToString());


Aun así, dado que la serialización de JSON se realiza mediante el uso de JsonWriter.WriteRawValue(), los datos que no son de confianza de username y password no se validarán para omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory con la contraseña Evil123! fuese a agregar ","role":"admin a su nombre de usuario al introducirlo en la solicitud que establece el valor de la variable username, el JSON resultante guardado en C:\user_info.json sería:


{
"role":"default",
"username":"mallory",
"role":"admin",
"password":"Evil123!"
}


Si el archivo JSON serializado se fuese a deserializar en un objeto Dictionary con JsonConvert.DeserializeObject() de este modo:


String jsonString = File.ReadAllText(@"C:\user_info.json");

Dictionary<string, string> userInfo = JsonConvert.DeserializeObject<Dictionary<string, strin>>(jsonString);


Los valores resultantes para las claves de username, password y role del objeto Dictionary serían mallory, Evil123! y admin, respectivamente. Sin más comprobaciones de que los valores JSON deserializados son válidos, la aplicación asignará de forma incorrecta privilegios de "admin" al usuario mallory.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 91
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.json_injection
Abstract
El método escribe una entrada sin validar en JSON. Un atacante puede insertar elementos o atributos arbitrarios en la entidad JSON.
Explanation
La inyección JSON se produce cuando sucede lo siguiente:

1. Los datos se introducen en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y puede contener información confidencial. Cuando se usa para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y puede transmitir información confidencial, como las credenciales de autenticación.

Los atacantes pueden alterar la semántica de mensajes y documentos JSON si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede insertar elementos extraños y hacer que una aplicación genere una excepción mientras se están analizando un documento o una solicitud JSON. En casos más graves, como aquellos que impliquen la inyección JSON, un atacante puede insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En ocasiones, la inyección JSON puede dar lugar a scripts de sitios o una evaluación de código dinámico.

Ejemplo 1: El siguiente código serializa la información de autenticación de las cuentas de usuario para los usuarios sin privilegios (aquellos con un rol "predeterminado" a diferencia de los usuarios con privilegios con un rol de "admin") a partir de variables de entrada controladas por el usuario username y password al archivo JSON ubicado en ~/user_info.json:


...
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
username := r.FormValue("username")
password := r.FormValue("password")
...
jsonString := `{
"username":"` + username + `",
"role":"default"
"password":"` + password + `",
}`
...
f, err := os.Create("~/user_info.json")
defer f.Close()

jsonEncoder := json.NewEncoder(f)
jsonEncoder.Encode(jsonString)
}


Debido a que el código realiza la serialización de JSON mediante el uso de la concatenación de cadenas, los datos que no son de confianza en username y password no se validan a fin de omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, lo cual posiblemente pueda cambiar la estructura del archivo JSON serializado. En este ejemplo, si el usuario sin privilegios mallory con la contraseña Evil123! anexó ","role":"admin cuando ingresó su nombre de usuario, el archivo JSON resultante guardado en ~/user_info.json sería el siguiente:


{
"username":"mallory",
"role":"default",
"password":"Evil123!",
"role":"admin"
}

Sin más comprobaciones de que los valores JSON deserializados son válidos, la aplicación asigna de forma accidental al usuario mallory privilegios de "admin".
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 91
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.json_injection
Abstract
El método escribe una entrada sin validar en JSON. Esta llamada puede permitir a un atacante insertar elementos o atributos de forma arbitraria en la entidad JSON.
Explanation
La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.

Ejemplo 1: el siguiente código Java utiliza Jackson para serializar la información de autenticación de las cuentas de usuario para los usuarios sin privilegios (aquellos con un rol "predeterminado" a diferencia de los usuarios con privilegios con un rol de "admin") a partir de variables de entrada controladas por el usuario username y password al archivo JSON ubicado en ~/user_info.json:


...

JsonFactory jfactory = new JsonFactory();

JsonGenerator jGenerator = jfactory.createJsonGenerator(new File("~/user_info.json"), JsonEncoding.UTF8);

jGenerator.writeStartObject();

jGenerator.writeFieldName("username");
jGenerator.writeRawValue("\"" + username + "\"");

jGenerator.writeFieldName("password");
jGenerator.writeRawValue("\"" + password + "\"");

jGenerator.writeFieldName("role");
jGenerator.writeRawValue("\"default\"");

jGenerator.writeEndObject();

jGenerator.close();


Aun así, dado que la serialización de JSON se realiza mediante el uso de JsonGenerator.writeRawValue(), los datos que no son de confianza de username y password no se validarán para omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory con la contraseña Evil123! fuese a agregar ","role":"admin a su nombre de usuario al introducirlo en la solicitud que establece el valor de la variable username, el JSON resultante guardado en ~/user_info.json sería:


{
"username":"mallory",
"role":"admin",
"password":"Evil123!",
"role":"default"
}


Si el archivo JSON serializado se fuese a deserializar en un objeto HashMap con JsonParser de Jackson de este modo:


JsonParser jParser = jfactory.createJsonParser(new File("~/user_info.json"));

while (jParser.nextToken() != JsonToken.END_OBJECT) {

String fieldname = jParser.getCurrentName();

if ("username".equals(fieldname)) {
jParser.nextToken();
userInfo.put(fieldname, jParser.getText());
}

if ("password".equals(fieldname)) {
jParser.nextToken();
userInfo.put(fieldname, jParser.getText());
}

if ("role".equals(fieldname)) {
jParser.nextToken();
userInfo.put(fieldname, jParser.getText());
}

if (userInfo.size() == 3)
break;
}

jParser.close();


Los valores resultantes para las claves de username, password y role del objeto HashMap serían mallory, Evil123! y admin, respectivamente. Sin más comprobaciones de que los valores JSON deserializados son válidos, la aplicación asignará de forma incorrecta privilegios de "admin" al usuario mallory.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 91
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.json_injection
Abstract
El método escribe una entrada sin validar en JSON. Esta llamada puede permitir a un atacante insertar elementos o atributos de forma arbitraria en la entidad JSON.
Explanation
La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.

Ejemplo 1: el siguiente código JavaScript utiliza jQuery para analizar JSON, donde un valor procede de una dirección URL:


var str = document.URL;
var url_check = str.indexOf('name=');
var name = null;
if (url_check > -1) {
name = decodeURIComponent(str.substring((url_check+5), str.length));
}

$(document).ready(function(){
if (name !== null){
var obj = jQuery.parseJSON('{"role": "user", "name" : "' + name + '"}');
...
}
...
});


Aquí, los datos que no son de confianza en name no se validarán para omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory fuese a agregar ","role":"admin al parámetro de nombre en la dirección URL, el JSON resultante sería:


{
"role":"user",
"username":"mallory",
"role":"admin"
}


Esto es analizado por jQuery.parseJSON() y establecido como objeto simple, lo que significa que obj.role devolverá "admin" en lugar de "user".
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 91
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.json_injection
Abstract
El método escribe una entrada sin validar en JSON. Esta llamada puede permitir a un atacante insertar elementos o atributos de forma arbitraria en la entidad JSON.
Explanation
La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.

Ejemplo 1: el siguiente código Objective-C serializa la información de la autenticación de cuenta de usuario para usuarios sin privilegios (aquellos con un rol "predeterminado" a diferencia de los usuarios con un rol de "admin") a JSON de los campos controlables por el usuario _usernameField y _passwordField:


...

NSString * const jsonString = [NSString stringWithFormat: @"{\"username\":\"%@\",\"password\":\"%@\",\"role\":\"default\"}" _usernameField.text, _passwordField.text];


Aun así, dado que la serialización de JSON se realiza mediante el uso de NSString.stringWithFormat:, los datos que no son de confianza de _usernameField y _passwordField no se validarán para omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory con la contraseña Evil123! fuese a agregar ","role":"admin a su nombre de usuario al introducirla en el campo _usernameField, el JSON resultante sería:


{
"username":"mallory",
"role":"admin",
"password":"Evil123!",
"role":"default"
}


Si esta cadena JSON serializada se fuese a deserializar en un objeto NSDictionary con NSJSONSerialization.JSONObjectWithData: de este modo:


NSError *error;
NSDictionary *jsonData = [NSJSONSerialization JSONObjectWithData:[jsonString dataUsingEncoding:NSUTF8StringEncoding] options:NSJSONReadingAllowFragments error:&error];


Los valores resultantes para username, password y role en el objeto NSDictionary serían mallory, Evil123! y admin respectivamente. Sin más comprobaciones de que los valores JSON deserializados son válidos, la aplicación asignará de forma incorrecta privilegios de "admin" al usuario mallory.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 91
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.objc.json_injection
Abstract
El método escribe una entrada sin validar en JSON. Esta llamada puede permitir a un atacante insertar elementos o atributos de forma arbitraria en la entidad JSON.
Explanation
La inyección JSON se produce cuando sucede lo siguiente:

1. Los datos se introducen en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en caché y puede contener información confidencial. Cuando se usa para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y puede transmitir información confidencial, como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada no validada. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación genere una excepción mientras se están analizando un documento o una solicitud JSON. En casos más graves, como aquellos que implican una inyección JSON, un atacante puede insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección de código JSON puede dar lugar a secuencias de comandos en sitios cruzados (Cross-Site Scripting) o a la evaluación de código dinámico.

Ejemplo: El siguiente código de Python actualiza un archivo json con un valor que no es fiable y proviene de una URL:


import json
import requests
from urllib.parse import urlparse
from urllib.parse import parse_qs

url = 'https://www.example.com/some_path?name=some_value'
parsed_url = urlparse(url)
untrusted_values = parse_qs(parsed_url.query)['name'][0]

with open('data.json', 'r') as json_File:
data = json.load(json_File)

data['name']= untrusted_values

with open('data.json', 'w') as json_File:
json.dump(data, json_File)

...


Aquí, los datos que no son fiables en name no se validarán para escapar de los caracteres especiales relacionados con JSON. Esto permite que un usuario inserte arbitrariamente claves JSON, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory agregara ","role":"admin al parámetro de nombre en la URL, el JSON se convertiría en:


{
"role":"user",
"username":"mallory",
"role":"admin"
}

El archivo JSON ahora está manipulado con datos maliciosos y el usuario tiene un acceso privilegiado de "administrador" en lugar de "usuario".
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 91
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.json_injection
Abstract
El método escribe una entrada sin validar en JSON. Esta llamada puede permitir a un atacante insertar elementos o atributos de forma arbitraria en la entidad JSON.
Explanation
La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 91
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.scala.json_injection
Abstract
El método escribe una entrada sin validar en JSON. Esta llamada puede permitir a un atacante insertar elementos o atributos de forma arbitraria en la entidad JSON.
Explanation
La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.

Ejemplo 1: El siguiente código Swift serializa la información de la autenticación de cuenta de usuario para usuarios sin privilegios (aquellos con un rol "predeterminado" a diferencia de los usuarios con un rol de "admin") a JSON de los campos controlables por el usuario usernameField y passwordField:


...
let jsonString : String = "{\"username\":\"\(usernameField.text)\",\"password\":\"\(passwordField.text)\",\"role\":\"default\"}"


Aún así, dado que la serialización de JSON se realiza mediante el uso de la interpolación de cadenas, los datos que no son de confianza en usernameField y passwordField no se validarán para omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory con la contraseña Evil123! fuese a agregar ","role":"admin a su nombre de usuario al introducirla en el campo usernameField, el JSON resultante sería:


{
"username":"mallory",
"role":"admin",
"password":"Evil123!",
"role":"default"
}


Si esta cadena JSON serializada se fuese a deserializar en un objeto NSDictionary con NSJSONSerialization.JSONObjectWithData: de este modo:


var error: NSError?
var jsonData : NSDictionary = NSJSONSerialization.JSONObjectWithData(jsonString.dataUsingEncoding(NSUTF8StringEncoding), options: NSJSONReadingOptions.MutableContainers, error: &error) as NSDictionary


Los valores resultantes para username, password y role en el objeto NSDictionary serían mallory, Evil123! y admin respectivamente. Sin más comprobaciones de que los valores JSON deserializados son válidos, la aplicación asignará de forma incorrecta privilegios de "admin" al usuario mallory.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 91
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.swift.json_injection