6 itens encontrados
Vulnerabilidades
Abstract
O programa viola a especificação Enterprise JavaBeans usando AWT/Swing.
Explanation
A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"Um enterprise bean não deve usar a funcionalidade AWT para tentar a saída de informações em um monitor ou para inserir informações usando um teclado."

Uma exigência que a especificação justifica da seguinte maneira:

"Os servidores não permitem interação direta entre um programa de aplicativo e um teclado/tela conectado ao sistema do servidor."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 575
desc.structural.java.ejb_bad_practices_use_of_awt_swing
Abstract
O programa viola a especificação Enterprise JavaBeans usando o carregador de classe.
Explanation
A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"O enterprise bean não deve tentar criar um carregador de classes; definir o carregador de classes de contexto; definir o gerenciador de segurança; criar um novo gerenciador de segurança; parar a JVM; ou alterar os fluxos de entrada, saída e erro."

Uma exigência que a especificação justifica da seguinte maneira:

"Essas funções são reservadas para o contêiner do Enterprise Beans. Permitir que o enterprise bean use essas funções pode comprometer a segurança e diminuir a capacidade do contêiner de gerenciar adequadamente o ambiente de tempo de execução."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 578
desc.structural.java.ejb_bad_practices_use_of_classloader
Abstract
O programa viola a especificação Enterprise JavaBeans usando o pacote java.io.
Explanation
A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"Um enterprise bean deve ter cuidado ao usar o pacote Java I/O para tentar acessar arquivos e diretórios no sistema de arquivos."

Uma exigência que a especificação justifica da seguinte maneira:

"As APIs do sistema de arquivos não são adequadas para que componentes de negócios acessem dados. Os arquivos podem não estar acessíveis em todas as instâncias, ou seu conteúdo pode ser diferente em instâncias diferentes, e coordenar as atualizações do arquivo pode ser difícil. Os componentes de negócios devem usar uma API de gerenciador de recursos, como JDBC, para armazenar dados."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 576
desc.structural.java.ejb_bad_practices_use_of_java_io
Abstract
O programa viola a especificação Enterprise JavaBeans usando soquetes.
Explanation
A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"Um enterprise bean não deve tentar escutar em um soquete, aceitar conexões em um soquete ou usar um soquete para multitransmissão."

Uma exigência que a especificação justifica da seguinte maneira:

"A arquitetura do Enterprise Beans permite que uma instância de enterprise bean seja um cliente de soquete de rede, mas não permite que ela seja um servidor de rede. Permitir que a instância se torne um servidor de rede entraria em conflito com a função básica do enterprise bean: atender aos clientes do Enterprise Beans."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 577
desc.structural.java.ejb_bad_practices_use_of_sockets
Abstract
O programa viola a especificação Enterprise JavaBeans usando primitivos de sincronização de threads.
Explanation
A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"Um enterprise bean não deve usar primitivas de sincronização de threads para sincronizar a execução de várias instâncias, a menos que seja um singleton session bean com simultaneidade gerenciada por bean."

Uma exigência que a especificação justifica da seguinte maneira:

"Essa regra é necessária para garantir uma semântica em tempo de execução consistente, pois, embora alguns contêineres do Enterprise Beans possam usar uma única JVM para executar todas as instâncias do enterprise bean, outros podem distribuir essas instâncias entre várias JVMs."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[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
O método grava uma entrada não validada no JSON. Essa chamada pode permitir que um invasor injete elementos ou atributos arbitrários na entidade JSON.
Explanation
Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: O seguinte código C# usa JSON.NET para serializar informações de autenticação de conta de usuário para usuários não privilegiados (com a função "default", em oposição a usuários privilegiados com a função "admin") a partir das variáveis de entrada controladas pelo usuário username e password para o arquivo JSON localizado em 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());


Ainda assim, como serialização JSON é realizada com o uso de JsonWriter.WriteRawValue(), os dados não confiáveis em username e password não serão validados para o escape de caracteres especiais relacionados ao JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente mudando a estrutura do JSON serializado. Neste exemplo, se o usuário não privilegiado mallory com a senha Evil123! fosse acrescentar ","role":"admin ao seu nome de usuário ao inseri-lo no prompt que define o valor da variável username, o JSON salvo em C:\user_info.json seria:


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


Se esse arquivo JSON serializado fosse então desserializado em um objeto Dictionary com JsonConvert.DeserializeObject(), da seguinte maneira:


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

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


Os valores resultantes para as chaves username, password e role no objeto Dictionary seriam mallory, Evil123! e admin, respectivamente. Sem a verificação adicional de que os valores JSON desserializados são válidos, o aplicativo atribuirá incorretamente os privilégios "admin" ao usuário 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.json_injection
Abstract
O método grava uma entrada não validada para o JSON. Um invasor pode injetar elementos ou atributos arbitrários na entidade JSON.
Explanation
Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando destinado a enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode transmitir informações confidenciais, como credenciais de autenticação.

Invasores podem alterar a semântica de documentos e mensagens JSON se um aplicativo JSON for construído a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em casos mais graves, como aqueles que envolvem uma injeção de JSON, um invasor pode inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Às vezes, a injeção de JSON pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1: O seguinte código serializa as informações de autenticação da conta de usuário para usuários não privilegiados (aqueles com uma função de "default", em oposição aos usuários privilegiados com uma função de "admin") de variáveis de entrada controladas por usuário username e password para o arquivo JSON localizado em ~/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)
}


Como o código executa a serialização JSON usando concatenação, os dados não confiáveis em username e password não serão validados para realizar escape de caracteres especiais relacionados a JSON. Isso permite que um usuário insira chaves JSON arbitrárias, podendo modificar a estrutura serializada JSON. Neste exemplo, se o usuário não privilegiado mallory com a senha Evil123! anexou ","role":"admin quando ela inseriu seu nome de usuário, o JSON resultante salvo para ~/user_info.json seria:


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

Sem a verificação adicional de que os valores JSON desserializados são válidos, o aplicativo atribuirá involuntariamente os privilégios "admin" ao usuário 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.json_injection
Abstract
O método grava uma entrada não validada no JSON. Essa chamada pode permitir que um invasor injete elementos ou atributos arbitrários na entidade JSON.
Explanation
Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: O seguinte código Java usa o Jackson para serializar as informações de autenticação da conta de usuário para usuários não privilegiados (aqueles com uma função de "default", em oposição aos usuários privilegiados com uma função de "admin") de variáveis de entrada controladas por usuário username e password para o arquivo JSON localizado em ~/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();


Ainda assim, como serialização JSON é realizada com o uso de JsonGenerator.writeRawValue(), os dados não confiáveis em username e password não serão validados para o escape de caracteres especiais relacionados ao JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente mudando a estrutura do JSON serializado. Neste exemplo, se o usuário não privilegiado mallory com a senha Evil123! fosse acrescentar ","role":"admin ao seu nome de usuário ao inseri-lo no prompt que define o valor da variável username, o JSON salvo em ~/user_info.json seria:


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


Se esse arquivo JSON serializado fosse então desserializado em um objeto HashMap com JsonParser do Jackson, da seguinte maneira:


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();


Os valores resultantes para as chaves username, password e role no objeto HashMap seriam mallory, Evil123! e admin, respectivamente. Sem a verificação adicional de que os valores JSON desserializados são válidos, o aplicativo atribuirá incorretamente os privilégios "admin" ao usuário 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.json_injection
Abstract
O método grava uma entrada não validada no JSON. Essa chamada pode permitir que um invasor injete elementos ou atributos arbitrários na entidade JSON.
Explanation
Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: O código JavaScript a seguir usa jQuery para analisar o JSON no qual um valor vem de uma 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 + '"}');
...
}
...
});


Aqui os dados não confiáveis em name não serão validados para escapar dos caracteres especiais relacionadas com o JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente mudando a estrutura do JSON serializado. Neste exemplo, se o usuário não privilegiado mallory acrescentasse ","role":"admin ao parâmetro nome na URL, o JSON se tornaria:


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


Ele é analisado pelo jQuery.parseJSON() e definido como um objeto simples, o que significa que obj.role retornaria agora "admin" em vez 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.json_injection
Abstract
O método grava uma entrada não validada no JSON. Essa chamada pode permitir que um invasor injete elementos ou atributos arbitrários na entidade JSON.
Explanation
Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: Este código Objective-C serializa as informações de autenticação de conta para usuários não privilegiados (aqueles com uma função "padrão" em vez dos usuários privilegiados, com uma função de "admin") em JSON a partir dos campos controlados pelo usuário _usernameField e _passwordField:


...

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


Ainda assim, como serialização JSON é realizada com o uso de NSString.stringWithFormat:, os dados não confiáveis em _usernameField e _passwordField não serão validados para o escape de caracteres especiais relacionados ao JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente mudando a estrutura do JSON serializado. Nesse exemplo, se o usuário não privilegiado mallory com a senha Evil123! anexasse ","role":"admin ao nome de usuário dele ao digitá-lo no campo _usernameField, o JSON resultante seria:


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


Se essa cadeia JSON serializada fosse então desserializada para um objetoNSDictionary com NSJSONSerialization.JSONObjectWithData: desta maneira:


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


Os valores resultantes de username, password, e role no objeto NSDictionary seriam mallory, Evil123!, e admin respectivamente. Sem a verificação adicional de que os valores JSON desserializados são válidos, o aplicativo atribuirá incorretamente os privilégios "admin" ao usuário 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.objc.json_injection
Abstract
O método grava uma entrada não validada no JSON. Essa chamada pode permitir que um invasor injete elementos ou atributos arbitrários na entidade JSON.
Explanation
Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode potencialmente conter informações confidenciais. Quando destinado a enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço RESTful e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON poderá ser alterada se um aplicativo construir JSON com base em uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou solicitação JSON. Em um caso mais graves, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em um documento ou solicitação JSON. Em alguns casos, a injeção de JSON pode até mesmo provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: O seguinte código python atualiza um arquivo json com um valor não confiável originário de uma 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)

...


Aqui, os dados não confiáveis em name não serão validados para aplicar o escape de caracteres especiais relacionados a JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente alterando a estrutura do JSON serializado. Nesse exemplo, se o usuário não privilegiado mallory anexasse ","role":"admin ao parâmetro name na URL, o JSON se tornaria:


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

O arquivo JSON agora é adulterado com dados mal-intencionados e o usuário tem acesso privilegiado de "admin" em vez 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.json_injection
Abstract
O método grava uma entrada não validada no JSON. Essa chamada pode permitir que um invasor injete elementos ou atributos arbitrários na entidade JSON.
Explanation
Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.scala.json_injection
Abstract
O método grava uma entrada não validada no JSON. Essa chamada pode permitir que um invasor injete elementos ou atributos arbitrários na entidade JSON.
Explanation
Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: O seguinte código Swift serializa as informações de autenticação de conta dos usuários não privilegiados (aqueles com uma função “padrão”, em vez dos usuários privilegiados com uma função “admin”) para o JSON a partir dos campos controlados pelo usuário usernameField e passwordField:


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


Ainda assim, como a serialização JSON é realizada usando interpolação, os dados não confiáveis em usernameField e passwordField não serão validados para realizar escape dos caracteres especiais relacionados a JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente mudando a estrutura do JSON serializado. Nesse exemplo, se o usuário não privilegiado mallory com a senha Evil123! anexasse ","role":"admin ao nome de usuário dele ao digitá-lo no campo usernameField, o JSON resultante seria:


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


Se essa cadeia JSON serializada fosse então desserializada para um objetoNSDictionary com NSJSONSerialization.JSONObjectWithData: desta maneira:


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


Os valores resultantes de username, password, e role no objeto NSDictionary seriam mallory, Evil123!, e admin respectivamente. Sem a verificação adicional de que os valores JSON desserializados são válidos, o aplicativo atribuirá incorretamente os privilégios "admin" ao usuário 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.swift.json_injection