Reino: API Abuse

Uma API é um contrato entre quem chama e o que se chama. As formas mais comuns de abuso de API ocorrem quando o responsável pela chamada não respeita sua parte do contrato. Por exemplo, se um programa não chama chdir() após chamar chroot(), ele viola o contrato que especifica como alterar o diretório raiz ativo de forma segura. Outro bom exemplo de abuso de biblioteca é esperar que o elemento chamado retorne informações confiáveis de DNS ao responsável pela chamada. Nesse caso, o responsável pela chamada abusa a API do elemento chamado ao fazer certas suposições sobre seu comportamento (isto é, que o valor de retorno pode ser usado para fins de autenticação). A outra parte também pode violar o contrato entre quem chama e o que se chama. Por exemplo, se um programador definir SecureRandom como subclasse e retornar um valor não aleatório, o contrato será violado.

81 itens encontrados
Vulnerabilidades
Abstract
Os invasores podem falsificar entradas de DNS. Não confie em nomes DNS para segurança.
Explanation
Muitos servidores DNS são suscetíveis a ataques de falsificação e, portanto, você deve partir do princípio de que algum dia o seu software será executado em um ambiente com um servidor DNS comprometido. Se os invasores tiverem permissão para fazer atualizações de DNS (processo às vezes chamado de envenenamento de cache de DNS), eles poderão rotear seu tráfego de rede através das máquinas deles ou causar a impressão de que os endereços IP deles fazem parte do seu domínio. Não baseie a segurança do seu sistema em nomes DNS.
Exemplo: A amostra de código a seguir usa uma pesquisa de DNS para decidir se uma solicitação de entrada é ou não proveniente de um host confiável. Se um invasor puder envenenar o cache de DNS, ele poderá obter um status confiável.


IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
if (hostInfo.HostName.EndsWith("trustme.com")) {
trusted = true;
}


Endereços IP são mais confiáveis que nomes DNS, mas também podem ser falsificados. Os invasores podem facilmente falsificar o endereço IP de origem dos pacotes que eles enviam, mas os pacotes de resposta retornarão ao endereço IP falsificado. Para ver os pacotes de resposta, o invasor precisa realizar o sniffing do tráfego entre a máquina da vítima e o endereço IP falsificado. Para realizar o sniffing necessário, os invasores normalmente tentam se localizar na mesma sub-rede que a máquina da vítima. Os invasores podem ser capazes de se esquivar dessa exigência usando o roteamento de origem, mas esse roteamento não está habilitado em uma grande extensão da Internet hoje em dia. Em resumo, a verificação de endereços IP pode ser uma parte útil de um esquema de autenticação, mas não deve ser o único fator necessário para a autenticação.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807
[7] Standards Mapping - FIPS200 IA
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-23 Session Authenticity (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-23 Session Authenticity
[11] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[15] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[16] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[17] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[18] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807
[32] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[41] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)
[42] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.semantic.dotnet.often_misused_authentication
Abstract
A função getlogin() é fácil de falsificar. Não confie no nome que ela retorna.
Explanation
A função getlogin() deve retornar uma string contendo o nome do usuário atualmente conectado ao terminal, mas um invasor pode fazer com que getlogin() retorne o nome de qualquer usuário conectado à máquina. Não confie no nome retornado por getlogin() ao tomar decisões de segurança.
Exemplo 1: O código a seguir se baseia em getlogin() para determinar se um usuário é ou não confiável. Isso é facilmente contestado.


pwd = getpwnam(getlogin());
if (isTrustedGroup(pwd->pw_gid)) {
allow();
} else {
deny();
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807
[7] Standards Mapping - FIPS200 IA
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-23 Session Authenticity (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-23 Session Authenticity
[11] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[15] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[16] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[17] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[18] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807
[32] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[41] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)
[42] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.semantic.cpp.often_misused_authentication.getlogin
Abstract
Os invasores podem falsificar entradas de DNS. Não confie em nomes DNS para segurança.
Explanation
Muitos servidores DNS são suscetíveis a ataques de falsificação e, portanto, você deve partir do princípio de que algum dia o seu software será executado em um ambiente com um servidor DNS comprometido. Se os invasores tiverem permissão para fazer atualizações de DNS (processo às vezes chamado de envenenamento de cache de DNS), eles poderão rotear seu tráfego de rede através das máquinas deles ou causar a impressão de que os endereços IP deles fazem parte do seu domínio. Não baseie a segurança do seu sistema em nomes DNS.
Exemplo: O código a seguir usa uma pesquisa de DNS para determinar se uma solicitação de entrada é proveniente de um host confiável. Se um invasor puder envenenar o cache de DNS, ele poderá obter um status confiável.


String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
if (addr.getCanonicalHostName().endsWith("trustme.com")) {
trusted = true;
}


Endereços IP são mais confiáveis que nomes DNS, mas também podem ser falsificados. Os invasores podem facilmente falsificar o endereço IP de origem dos pacotes que eles enviam, mas os pacotes de resposta retornarão ao endereço IP falsificado. Para ver os pacotes de resposta, o invasor precisa realizar o sniffing do tráfego entre a máquina da vítima e o endereço IP falsificado. Para realizar o sniffing necessário, os invasores normalmente tentam se localizar na mesma sub-rede que a máquina da vítima. Os invasores podem ser capazes de se esquivar dessa exigência usando o roteamento de origem, mas esse roteamento não está habilitado em uma grande extensão da Internet hoje em dia. Em resumo, a verificação de endereços IP pode ser uma parte útil de um esquema de autenticação, mas não deve ser o único fator necessário para a autenticação.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807
[7] Standards Mapping - FIPS200 IA
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-23 Session Authenticity (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-23 Session Authenticity
[11] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[15] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[16] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[17] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[18] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807
[32] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[41] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)
[42] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.semantic.java.often_misused_authentication
Abstract
O método Boolean.getBoolean() é muitas vezes confundido com chamadas de métodos Boolean.valueOf() ou Boolean.parseBoolean().
Explanation
Na maioria dos casos, uma chamada para Boolean.getBoolean() é muitas vezes má utilizada, pois presume-se que ela retorne o valor booliano representado pelo argumento de string especificado. No entanto, conforme indicado no Javadoc, o método Boolean.getBoolean(String) "retornará true se, e somente se, a propriedade do sistema nomeada pelo argumento existir e for igual à string 'true'".

Na maioria das vezes, o que o desenvolvedor pretendia usar era uma chamada para o método Boolean.valueOf(String) ou Boolean.parseBoolean(String).
Exemplo 1: O código a seguir não se comportará conforme esperado. Ele imprimirá "FALSE", pois Boolean.getBoolean(String) não converte uma primitiva de String. Ele apenas converte a propriedade do sistema.

...
String isValid = "true";
if ( Boolean.getBoolean(isValid) ) {
System.out.println("TRUE");
}
else {
System.out.println("FALSE");
}
...
References
[1] Class Boolean Oracle
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
desc.semantic.java.often_misused_boolean_getboolean
Abstract
A substituição indevida das classes no .NET Framework pode levar à execução de código arbitrário no servidor, abuso da lógica do aplicativo ou à negação de serviço.
Explanation
Independentemente da linguagem na qual um programa está escrito, os ataques mais devastadores muitas vezes envolvem a execução de código remoto, por meio da qual um invasor consegue executar código mal-intencionado com sucesso no contexto do programa. O método GetChars nas classes Decoder & Encoding, e o método GetBytes nas classes Encoder & Encoding no .NET Framework executam internamente a aritmética de ponteiro nas matrizes char e byte para converter o intervalo de caracteres em um intervalo de bytes e vice-versa.
Durante a execução de operações de aritmética de ponteiro, os desenvolvedores muitas vezes substituem os métodos precedentes de uma maneira ruim e introduzem vulnerabilidades, como execução de código arbitrário, abuso da lógica do aplicativo e negação de serviço.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 176
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.structural.dotnet.often_misused_encoding
Abstract
Esse método é difícil de usar corretamente.
Explanation
É fácil acreditar que esse método de codificação protegerá contra ataques de injeção, mas, se ele não for usado no contexto certo, poderá oferecer muito menos proteção do que anuncia.

Exemplo 1: A seguinte chamada de codificação proporciona a um invasor um pouco de latitude para inserir JavaScript mal-intencionado:

out.println("x = " + encoder.encodeForJavaScript(input) + ";");
References
[1] OWASP ESAPI Secure Coding Guideline
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 176
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.structural.java.often_misused_encoding
Abstract
A chamada identificada pode ajustar caracteres de uma forma melhor. Os caracteres não suportados passados para os métodos de API padrão podem ser mapeados com um melhor ajuste para caracteres perigosos.
Explanation
Quando conjuntos de caracteres são incompatíveis entre o sistema operacional e os aplicativos em execução no sistema operacional, os caracteres não suportados passados para os métodos de API padrão podem ser mapeados com um melhor ajuste para caracteres perigosos.

Exemplo 1: Em Objective-C, o seguinte exemplo converte um objeto NSString que contém um caractere UTF-8 em dados ASCII e depois o converte de volta:


...
unichar ellipsis = 0x2026;
NSString *myString = [NSString stringWithFormat:@"My Test String%C", ellipsis];
NSData *asciiData = [myString dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
NSString *asciiString = [[NSString alloc] initWithData:asciiData encoding:NSASCIIStringEncoding];
NSLog(@"Original: %@ (length %d)", myString, [myString length]);
NSLog(@"Best-fit-mapped: %@ (length %d)", asciiString, [asciiString length]);
// output:
// Original: My Test String... (length 15)
// Best-fit-mapped: My Test String... (length 17)
...


Se você observar a saída com cuidado, o caractere "..." foi traduzido para três pontos consecutivos. Se você tinha dimensionado o buffer de saída com base no buffer de entrada, o aplicativo poderia estar vulnerável a um buffer overflow. Outros caracteres podem ser mapeados de um caractere para dois. O caractere grego "fi" será mapeado como um "f" seguido por um "i". Ao fazer o carregamento frontal do buffer com esses caracteres, um invasor obtém o controle completo sobre o número de caracteres usados para estourar o buffer.
References
[1] Apple Secure Coding Guide Apple
[2] String Programming Guide Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 176
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.semantic.objc.method_may_best_fit_map_characters
Abstract
A chamada identificada pode ajustar caracteres de uma forma melhor. Os caracteres não suportados passados para os métodos de API padrão podem ser mapeados com um melhor ajuste para caracteres perigosos.
Explanation
Quando conjuntos de caracteres são incompatíveis entre o sistema operacional e os aplicativos em execução no sistema operacional, os caracteres não suportados passados para os métodos de API padrão podem ser mapeados com um melhor ajuste para caracteres perigosos.

Exemplo 1: Em Swift, o seguinte exemplo converte um objeto NSString que contém um caractere UTF-8 em dados ASCII e depois o converte de volta:


...
let ellipsis = 0x2026;
let myString = NSString(format:"My Test String %C", ellipsis)
let asciiData = myString.dataUsingEncoding(NSASCIIStringEncoding, allowLossyConversion:true)
let asciiString = NSString(data:asciiData!, encoding:NSASCIIStringEncoding)
NSLog("Original: %@ (length %d)", myString, myString.length)
NSLog("Best-fit-mapped: %@ (length %d)", asciiString!, asciiString!.length)

// output:
// Original: My Test String ... (length 16)
// Best-fit-mapped: My Test String ... (length 18)
...


Se você observar a saída com cuidado, o caractere "..." foi traduzido para três pontos consecutivos. Se você tinha dimensionado o buffer de saída com base no buffer de entrada, o aplicativo poderia estar vulnerável a um buffer overflow. Outros caracteres podem ser mapeados de um caractere para dois. O caractere grego "fi" será mapeado como um "f" seguido por um "i". Ao fazer o carregamento frontal do buffer com esses caracteres, um invasor obtém o controle completo sobre o número de caracteres usados para estourar o buffer.
References
[1] Apple Secure Coding Guide Apple
[2] String Programming Guide Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 176
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.semantic.swift.method_may_best_fit_map_characters
Abstract
A função _alloca() pode lançar uma exceção de estouro de pilha, possivelmente travando o programa.
Explanation
A função _alloca() aloca memória na pilha. Se uma solicitação de alocação for muito grande para o espaço de pilha disponível, _alloca() lançará uma exceção. Se essa exceção não for detectada, o programa travará, possivelmente permitindo um ataque de negação de serviço.

A função _alloca() tornou-se preterida a partir do Microsoft Visual Studio 2005(R). Ela foi substituída pela função _alloca_s() mais segura.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 248
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[12] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[13] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention, Control Objective B.3.2 - Terminal Software Attack Mitigation
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention, Control Objective B.3.2 - Terminal Software Attack Mitigation
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
desc.semantic.cpp.often_misused_exception_handling._alloca
Abstract
Transmitir um buffer de saída de tamanho inadequado para uma função de manipulação de caminho pode resultar em um buffer overflow.
Explanation
O Windows fornece um grande número de funções utilitárias que manipulam buffers contendo nomes de arquivo. Na maioria dos casos, o resultado é retornado em um buffer que é transmitido como entrada. (Em geral, o nome do arquivo é modificado no local.) A maioria das funções exige que o buffer tenha pelo menos MAX_PATH bytes de comprimento, mas você deve verificar a documentação para cada função individualmente. Se o buffer não for grande o suficiente para armazenar o resultado da manipulação, poderá ocorrer um buffer overflow.

Exemplo:

char *createOutputDirectory(char *name) {
char outputDirectoryName[128];
if (getCurrentDirectory(128, outputDirectoryName) == 0) {
return null;
}
if (!PathAppend(outputDirectoryName, "output")) {
return null;
}
if (!PathAppend(outputDirectoryName, name)) {
return null;
}
if (SHCreateDirectoryEx(NULL, outputDirectoryName, NULL)
!= ERROR_SUCCESS) {
return null;
}
return StrDup(outputDirectoryName);
}


Nesse exemplo, a função cria um diretório chamado "output\<name>" no diretório atual e retorna uma cópia de heap alocado do seu nome. Para a maioria dos valores do diretório atual e do parâmetro "name", essa função funcionará corretamente. No entanto, se o parâmetro name for particularmente longo, a segunda chamada para PathAppend() poderá causar um estouro do buffer de outputDirectoryName, que é menor que MAX_PATH bytes.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I
desc.semantic.cpp.often_misused_file_system.windows
Abstract
A máscara especificada pelo argumento umask() é muitas vezes confundida com o argumento para chmod().
Explanation
A página man umask() começa com a instrução falsa:

"umask define a máscara do usuário como a máscara & 0777"

Embora esse comportamento possa condizer melhor com o uso de chmod(), no qual o argumento fornecido pelo usuário especifica os bits a serem habilitados no arquivo especificado, o comportamento de umask() é, na verdade, o oposto: umask() define umask como ~mask & 0777.

A página man umask() continua e descreve o uso correto de umask():

"Umask é usado por open() para definir as permissões de arquivo iniciais em um arquivo recém-criado. Especificamente, as permissões em umask estão desativadas no argumento de modo para open(2) (e portanto, por exemplo, o valor padrão comum de umask 022 faz com que novos arquivos sejam criados com permissões 0666 & ~022 = 0644 = rw-r--r-- no caso usual em que o modo é especificado como 0666)."
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I
desc.semantic.java.often_misused_file_system
Abstract
A chamada identificada usa métodos que seguem links simbólicos.
Explanation
Certas funções identificadas são conhecidas por seguir links simbólicos cegamente. Quando isso acontece, o aplicativo abre, lê ou grava dados no arquivo que o link simbólico aponta em vez da representação do link simbólico. Um invasor pode enganar o aplicativo para que ele grave em arquivos essenciais do sistema ou em arquivos alternativos, ou pode fornecer dados comprometidos ao aplicativo.

Exemplo 1: Este código utiliza as funções que seguem links simbólicos:


...
struct stat output;
int ret = stat(aFilePath, &output);
// error handling omitted for this example
struct timespec accessTime = output.st_atime;
...
References
[1] Apple Secure Coding Guide Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I
desc.semantic.objc.methods_follow_sym_links
Abstract
A máscara especificada pelo argumento umask() é muitas vezes confundida com o argumento para chmod().
Explanation
A página man umask() começa com a instrução falsa:

"umask define a máscara do usuário como a máscara & 0777"

Embora esse comportamento possa condizer melhor com o uso de chmod(), no qual o argumento fornecido pelo usuário especifica os bits a serem habilitados no arquivo especificado, o comportamento de umask() é, na verdade, o oposto: umask() define umask como ~mask & 0777.

A página man umask() continua e descreve o uso correto de umask():

"A umask é usada para definir as permissões de arquivo iniciais em um arquivo recém-criado. Especificamente, as permissões na umask são desativadas a partir do argumento de modo (assim, por exemplo, o valor umask padrão comum de 022 resulta em novos arquivos que estão sendo criados com permissões 0666 & ~022 = 0644 = rw-r-r-- no caso habitual em que o modo é especificado como 0666)".
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I
desc.semantic.python.often_misused_file_system.umask
Abstract
A chamada utiliza métodos que gravam em arquivos temporários antes de gravar no arquivo pretendido.
Explanation
Muitas APIs minimizarão o risco de perda de dados mediante a gravação completa em um arquivo temporário e, em seguida, a cópia do arquivo inteiro para o destino pretendido. Certifique-se de que o método identificado não funcione em arquivos ou caminhos em diretórios públicos ou temporários, pois um invasor pode substituir o arquivo temporário logo antes que ele seja gravado no arquivo pretendido. Isso permite que o invasor controle o conteúdo dos arquivos utilizados pelo aplicativo em diretórios públicos.

Exemplo 1: O seguinte código grava a transactionId ativa em um arquivo temporário no diretório Documentos de aplicativo usando um método vulnerável:


...
//get the documents directory:
let documentsPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0]
//make a file name to write the data to using the documents directory:
let fileName = NSString(format:"%@/tmp_activeTrans.txt", documentsPath)
// write data to the file
let transactionId = "TransactionId=12341234"
transactionId.writeToFile(fileName, atomically:true)
...
References
[1] Apple Secure Coding Guide Apple
[2] Apple NSString Class Reference Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[22] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I
desc.semantic.swift.methods_unsafe_on_public_or_tmp_directories
Abstract
Permitir que os usuários carreguem arquivos pode permitir que os invasores injetem conteúdo perigoso ou código mal-intencionado para execução no servidor.
Explanation
Independentemente da linguagem na qual um programa está escrito, os ataques mais devastadores muitas vezes envolvem a execução de código remoto, por meio da qual um invasor consegue executar código mal-intencionado com sucesso no contexto do programa. Se os invasores puderem carregar arquivos em um diretório acessível na Web e fazer com que esses arquivos sejam transmitidos ao interpretador de código (por exemplo, JSP/ASPX/PHP), eles poderão fazer com que o código mal-intencionado contido nesses arquivos seja executado no servidor.

O código a seguir recebe um arquivo carregado e o atribui ao objeto posted. FileUpload é do tipo System.Web.UI.HtmlControls.HtmlInputFile.
Exemplo:

HttpPostedFile posted = FileUpload.PostedFile;

Mesmo que um programa armazene arquivos carregados em um diretório não acessível na Web, os invasores ainda podem ser capazes de se aproveitar da capacidade de introduzir conteúdo mal-intencionado no ambiente do servidor para preparar outros ataques. Se o programa for suscetível a vulnerabilidades de manipulação de caminho, injeção de comando ou inclusão de arquivos perigosos, um invasor poderá carregar um arquivo com conteúdo mal-intencionado e fazer com que este seja lido ou executado pelo programa ao explorar outra vulnerabilidade.
References
[1] Alla Bezroutchko Secure file upload in PHP web applications
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.semantic.dotnet.often_misused_file_upload
Abstract
Permitir que os usuários carreguem arquivos pode permitir aos invasores injetar conteúdo perigoso ou códigos mal-intencionados para serem executados no servidor.
Explanation
Independentemente da linguagem na qual um programa está escrito, os ataques mais devastadores muitas vezes envolvem a execução de código remoto, por meio da qual um invasor consegue executar código mal-intencionado com sucesso no contexto do programa. Se os invasores puderem carregar arquivos em um diretório acessível na Web e fazer com que esses arquivos sejam transmitidos ao interpretador de código (por exemplo, JSP/ASPX/PHP), eles poderão fazer com que o código mal-intencionado contido nesses arquivos seja executado no servidor.

Exemplo: A seguinte classe de controlador Spring MVC tem um parâmetro que pode ser usado para manipular arquivos carregados.

@Controller
public class MyFormController {
...
@RequestMapping("/test")
public String uploadFile (org.springframework.web.multipart.MultipartFile file) {
...
} ...
}


Mesmo que um programa armazene arquivos carregados em um diretório não acessível na Web, os invasores ainda podem ser capazes de se aproveitar da capacidade de introduzir conteúdo mal-intencionado no ambiente do servidor para preparar outros ataques. Se o programa for suscetível a vulnerabilidades de manipulação de caminho, injeção de comando ou inclusão de arquivos perigosos, um invasor poderá carregar um arquivo com conteúdo mal-intencionado e fazer com que este seja lido ou executado pelo programa ao explorar outra vulnerabilidade.
References
[1] Alla Bezroutchko Secure file upload in PHP web applications
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.java.often_misused_file_upload_spring
Abstract
Permitir que os usuários carreguem arquivos pode permitir que os invasores injetem conteúdo perigoso ou código mal-intencionado para execução no servidor.
Explanation
Independentemente da linguagem na qual um programa está escrito, os ataques mais devastadores muitas vezes envolvem a execução de código remoto, por meio da qual um invasor consegue executar código mal-intencionado com sucesso no contexto do programa. Se os invasores puderem carregar arquivos em um diretório acessível na Web e fazer com que esses arquivos sejam transmitidos ao interpretador PHP, eles poderão fazer com que o código mal-intencionado contido nesses arquivos sejam executados no servidor.

Exemplo 1: O código a seguir processa arquivos carregados e os move para um diretório na raiz da Web. Os invasores podem carregar arquivos de origem PHP mal-intencionados nesse programa e, posteriormente, solicitar esses arquivos ao servidor, o que fará com que eles sejam executados pelo intérprete PHP.


<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
echo "Valid upload received\n";
} else {
echo "Invalid upload rejected\n";
} ?>


Mesmo que um programa armazene arquivos carregados em um diretório não acessível na Web, os invasores ainda podem ser capazes de se aproveitar da capacidade de introduzir conteúdo mal-intencionado no ambiente do servidor para preparar outros ataques. Se o programa for suscetível a vulnerabilidades de manipulação de caminho, injeção de comando ou inclusão remota, um invasor poderá carregar um arquivo com conteúdo mal-intencionado e fazer com que este seja lido ou executado pelo programa ao explorar outra vulnerabilidade.
References
[1] M. Achour et al. PHP Manual
[2] PHP Security Consortium PhpSecInfo Test Information
[3] Alla Bezroutchko Secure file upload in PHP web applications
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - Common Weakness Enumeration CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[16] Standards Mapping - FIPS200 SI
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[20] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[22] Standards Mapping - OWASP Top 10 2010 A1 Injection
[23] Standards Mapping - OWASP Top 10 2013 A1 Injection
[24] Standards Mapping - OWASP Top 10 2017 A1 Injection
[25] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[27] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.semantic.php.often_misused_file_upload
Abstract
Permitir que os usuários carreguem arquivos pode permitir que os invasores injetem conteúdo perigoso ou código mal-intencionado para execução no servidor.
Explanation
Independentemente da linguagem na qual um programa está escrito, os ataques mais devastadores muitas vezes envolvem a execução de código remoto, por meio da qual um invasor consegue executar código mal-intencionado com sucesso no contexto do programa. Caso os atacantes consigam fazer o upload de arquivos a um diretório acessível por meio da Web e fazer com que esses arquivos sejam passados ao interpretador Python, eles poderão fazer com que o código malicioso contido nestes arquivos seja executado no servidor.

Exemplo 1: O código a seguir processa arquivos carregados e os move para um diretório na raiz da Web. Os invasores podem fazer o upload de arquivos mal-intencionados para esse programa e depois solicitá-los do servidor.


from django.core.files.storage import default_storage
from django.core.files.base import File
...
def handle_upload(request):
files = request.FILES
for f in files.values():
path = default_storage.save('upload/', File(f))
...


Mesmo que um programa armazene arquivos carregados em um diretório não acessível na Web, os invasores ainda podem ser capazes de se aproveitar da capacidade de introduzir conteúdo mal-intencionado no ambiente do servidor para preparar outros ataques. Se o programa for suscetível a vulnerabilidades de manipulação de caminho, injeção de comando ou inclusão remota, um invasor poderá carregar um arquivo com conteúdo mal-intencionado e fazer com que este seja lido ou executado pelo programa ao explorar outra vulnerabilidade.
References
[1] Django Foundation File Uploads
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.python.often_misused_file_upload
Abstract
Permitir que os usuários carreguem arquivos pode permitir que os invasores injetem conteúdo perigoso ou código mal-intencionado para execução no servidor.
Explanation
Independentemente da linguagem na qual um programa está escrito, os ataques mais devastadores muitas vezes envolvem a execução de código remoto, por meio da qual um invasor consegue executar código mal-intencionado com sucesso no contexto do programa. Se os invasores puderem carregar arquivos em um diretório publicamente executável, eles poderão fazer com que o código mal-intencionado contido nesses arquivos seja executado no servidor.

Mesmo que um programa armazene arquivos carregados em um diretório não acessível publicamente, os invasores ainda podem ser capazes de se aproveitar da capacidade de introduzir conteúdo mal-intencionado no ambiente do servidor para preparar outros ataques. Se o programa for suscetível a vulnerabilidades de manipulação de caminho, injeção de comando ou inclusão remota, um invasor poderá carregar um arquivo com conteúdo mal-intencionado e fazer com que este seja lido ou executado pelo programa ao explorar outra vulnerabilidade.
References
[1] Alla Bezroutchko Secure file upload in PHP web applications
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.ruby.often_misused_file_upload
Abstract
Permitir que os usuários carreguem arquivos pode permitir que os invasores injetem conteúdo perigoso ou código mal-intencionado para execução no servidor.
Explanation
Independentemente da linguagem na qual um programa está escrito, os ataques mais devastadores muitas vezes envolvem a execução de código remoto, por meio da qual um invasor consegue executar código mal-intencionado com sucesso no contexto do programa. Se os invasores puderem carregar arquivos em um diretório acessível na Web e fazer com que esses arquivos sejam transmitidos ao interpretador de código (por exemplo, JSP/ASPX/PHP), eles poderão fazer com que o código mal-intencionado contido nesses arquivos seja executado no servidor.
Mesmo que um programa armazene arquivos carregados em um diretório não acessível na Web, os invasores ainda podem ser capazes de se aproveitar da capacidade de introduzir conteúdo mal-intencionado no ambiente do servidor para preparar outros ataques. Se o programa for suscetível a vulnerabilidades de manipulação de caminho, injeção de comando ou inclusão de arquivos perigosos, um invasor poderá carregar um arquivo com conteúdo mal-intencionado e fazer com que este seja lido ou executado pelo programa ao explorar outra vulnerabilidade.

Uma tag <input> do tipo file indica que o programa aceita uploads de arquivos.
Exemplo:

<input type="file">
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 434
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[23] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.content.html.often_misused_file_upload
Abstract
As linguagens de modelo não devem ser misturadas para evitar a necessidade de trabalhar com proteções de cross-site scripting.
Explanation
Quando você combina mecanismos de modelo, significa que as proteções que foram implementadas anteriormente para um deles podem ter deixado de funcionar ou ser válidas. Na versão mais benigna, isso pode fazer com que a funcionalidade não opere conforme esperado, mas também pode permitir que usuários mal-intencionados contornem as proteções no mecanismo, resultando em vulnerabilidades de execução de scripts entre sites.

Exemplo 1: No seguinte código, um módulo AngularJS está configurado para usar "[[" e "]]" para delimitadores de expressão no lugar do padrão.


myModule.config(function($interpolateProvider){
$interpolateProvider.startSymbol("[[");
$interpolateProvider.endSymbol("]]");
});


Isso pode fazer com que o outro mecanismo de modelo realize a validação para escapar as expressões, o que pode não ser compatível com expressões AngularJS, possivelmente permitindo que os usuários contornem a validação regular e executem seu próprio código no navegador.
References
[1] AngularJS $interpolateProvider documentation Google
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
desc.structural.javascript.often_misused_mixing_template_languages