Reino: Input Validation and Representation

Problemas de validação e representação da entrada são causados por metacaracteres, codificações alternativas e representações numéricas. Confiar na entrada resulta em problemas de segurança. Os problemas incluem: “Buffer Overflows”, ataques de “Cross-Site Scripting”, “SQL Injection”, entre outros.

175 itens encontrados
Vulnerabilidades
Abstract
Executar uma instrução LDAP que contém um valor controlado pelo usuário fora da cadeia de filtro pode permitir que um invasor altere o significado dessa instrução ou execute comandos LDAP arbitrários.
Explanation
Erros de manipulação de LDAP ocorrem quando:

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

2. Os dados são usados fora da cadeia de filtro em uma instrução LDAP dinâmica.
Exemplo 1: O código a seguir lê uma string ou de um campo oculto enviado por meio de uma solicitação HTTP e o utiliza para criar um novo DirectoryEntry.


...
de = new DirectoryEntry("LDAP://ad.example.com:389/ou="
+ hiddenOU.Text + ",dc=example,dc=com");
...


Como a string de conexão inclui uma entrada do usuário e é realizada com uma associação anônima, um invasor pode alterar os resultados dessa consulta especificando um valor ou inesperado. O problema é que o desenvolvedor não conseguiu tirar proveito dos mecanismos de controle de acesso apropriados necessários para permitir que consultas subsequentes acessem somente os registros de funcionários que o usuário atual tem permissão para ler.
desc.dataflow.dotnet.ldap_manipulation
Abstract
Executar uma instrução LDAP que contém um valor controlado pelo usuário fora da cadeia de filtro pode permitir que um invasor altere o significado dessa instrução ou execute comandos LDAP arbitrários.
Explanation
Erros de manipulação de LDAP ocorrem quando:

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

2. Os dados são usados fora da cadeia de filtro em uma instrução LDAP dinâmica.
Exemplo 1: O código a seguir lê uma cadeia de caracteres dn de um soquete e a utiliza para realizar uma consulta LDAP.


...
rc = ldap_simple_bind_s( ld, NULL, NULL );
if ( rc != LDAP_SUCCESS ) {
...
}
...

fgets(dn, sizeof(dn), socket);

if ( ( rc = ldap_search_ext_s( ld, dn, LDAP_SCOPE_BASE,
filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
LDAP_NO_LIMIT, &result ) ) != LDAP_SUCCESS ) {
...


Como o DN base provém de uma entrada do usuário e a consulta é realizada com uma associação anônima, um invasor pode alterar os resultados dessa consulta especificando uma string dn inesperada. O problema é que o desenvolvedor não conseguiu tirar proveito dos mecanismos de controle de acesso apropriados necessários para permitir que consultas subsequentes acessem somente os registros de funcionários que o usuário atual tem permissão para ler.
desc.dataflow.cpp.ldap_manipulation
Abstract
Executar uma instrução LDAP que contém um valor controlado pelo usuário fora da cadeia de filtro pode permitir que um invasor altere o significado dessa instrução ou execute comandos LDAP arbitrários.
Explanation
Erros de manipulação de LDAP ocorrem quando:

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

2. Os dados são usados fora da cadeia de filtro em uma instrução LDAP dinâmica.
Exemplo 1: O código a seguir lê um nome de usuário e uma senha de uma solicitação HTTP e utiliza esta última para realizar uma pesquisa LDAP.


env.put(Context.SECURITY_AUTHENTICATION, "none");
DirContext ctx = new InitialDirContext(env);

String empID = request.getParameter("empID");

try
{
BasicAttribute attr = new BasicAttribute("empID", empID);

NamingEnumeration employee =
ctx.search("ou=People,dc=example,dc=com",attr);
...


Como a consulta inclui a entrada do usuário e é realizada com uma associação anônima, ela retornará os detalhes de qualquer nome de usuário especificado, independentemente de este corresponder ou não à senha especificada. Um invasor pode usar o código a seguir efetivamente para consultar os detalhes de qualquer funcionário no sistema, o que representa uma séria violação de privacidade. O problema é que o desenvolvedor não conseguiu tirar proveito dos mecanismos de controle de acesso apropriados necessários para permitir que a consulta acesse somente os registros de funcionários que o usuário atual tem permissão para ler.
desc.dataflow.java.ldap_manipulation
Abstract
Executar uma instrução LDAP que contém um valor controlado pelo usuário fora da cadeia de filtro pode permitir que um invasor altere o significado dessa instrução ou execute comandos LDAP arbitrários.
Explanation
Erros de manipulação de LDAP ocorrem quando:

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

2. Os dados são usados fora da cadeia de filtro em uma instrução LDAP dinâmica.
Exemplo 1:O código a seguir lê uma string dn do usuário e a utiliza para realizar uma consulta LDAP.


$dn = $_POST['dn'];

if (ldap_bind($ds)) {
...

try {
$rs = ldap_search($ds, $dn, "ou=People,dc=example,dc=com", $attr);
...


Como o dn base provém de uma entrada do usuário e a consulta é realizada com uma associação anônima, um invasor pode alterar os resultados dessa consulta especificando uma string dn inesperada. O problema é que o desenvolvedor não conseguiu tirar proveito dos mecanismos de controle de acesso apropriados necessários para permitir que consultas subsequentes acessem somente os registros de funcionários que o usuário atual tem permissão para ler.
desc.dataflow.php.ldap_manipulation
Abstract
O método identificado carrega uma página em uma webview, mas não implementa nenhum controle para impedir ataques de discagem automática ao visitar sites mal-intencionados.
Explanation
A menos que o conteúdo da página esteja completamente sob seu controle, o usuário poderá clicar em links que poderiam ser usados por invasores mal-intencionados para iniciar chamadas telefônicas ou do FaceTime automáticas.

Como exemplo, seu aplicativo pode estar exibindo uma postagem de blog ou tweet que pode conter links. O autor da postagem ou do tweet que seu usuário está visitando poderá usar links arbitrários nas páginas dele. Se os usuários visitarem um site mal-intencionado e forem enganados ou forem direcionados automaticamente para clicar em um link, um invasor poderá iniciar chamadas telefônicas ou do FaceTime automáticas e bloquear o dispositivo por alguns segundos para impedir que o usuário cancele a chamada. Observe que, mesmo se você controlar a página de destino, o usuário poderá acabar navegando para sites diferentes e não confiáveis.

Exemplo 1: O seguinte trecho de código usa uma webview para carregar um site que pode conter links não confiáveis, mas ele não especifica um delegado capaz de validar as solicitações iniciadas nesta webview:


...
NSURL *webUrl = [[NSURL alloc] initWithString:@"https://some.site.com/"];
NSURLRequest *webRequest = [[NSURLRequest alloc] initWithURL:webUrl];
[_webView loadRequest:webRequest];
...
References
[1] Collin Mulliner iOS WebView auto dialer bug
[2] Apple UIWebViewDelegate
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 501
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001084, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1, MASVS-PLATFORM-2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002360 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.objc.link_injection_auto_dial
Abstract
O método identificado carrega uma página em uma webview, mas não implementa nenhum controle para impedir ataques de discagem automática ao visitar sites mal-intencionados.
Explanation
A menos que o conteúdo da página esteja completamente sob seu controle, o usuário poderá clicar em links que poderiam ser usados por invasores mal-intencionados para iniciar chamadas telefônicas ou do FaceTime automáticas.

Como exemplo, seu aplicativo pode estar exibindo uma postagem de blog ou tweet que pode conter links. O autor da postagem ou do tweet que seu usuário está visitando poderá usar links arbitrários nas páginas dele. Se os usuários visitarem um site mal-intencionado e forem enganados ou forem direcionados automaticamente para clicar em um link, um invasor poderá iniciar chamadas telefônicas ou do FaceTime automáticas e bloquear o dispositivo por alguns segundos para impedir que o usuário cancele a chamada. Observe que, mesmo se você controlar a página de destino, o usuário poderá acabar navegando para sites diferentes e não confiáveis.

Exemplo 1: O seguinte trecho de código usa uma webview para carregar um site que pode conter links não confiáveis, mas ele não especifica um delegado capaz de validar as solicitações iniciadas nesta webview:


...
let webUrl : NSURL = NSURL(string: "https://some.site.com/")!
let webRequest : NSURLRequest = NSURLRequest(URL: webUrl)
webView.loadRequest(webRequest)
...
References
[1] Collin Mulliner iOS WebView auto dialer bug
[2] Apple UIWebViewDelegate
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 501
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001084, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1, MASVS-PLATFORM-2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002360 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.swift.link_injection_auto_dial
Abstract
O método identificado carrega uma página em uma webview, mas não implementa nenhum controle para verificar e validar os links nos quais o usuário poderá clicar.
Explanation
A menos que o conteúdo da página esteja completamente sob seu controle, o usuário poderá clicar em links que podem ser usados por invasores mal-intencionados para iniciar ações indesejadas.

Como exemplo, seu aplicativo pode estar exibindo uma postagem de blog ou tweet que pode conter links. O autor da postagem ou do tweet que seu usuário está visitando poderá usar links arbitrários nas páginas dele. Se os usuários visitarem um site mal-intencionado ou forem enganados ou direcionados automaticamente para clicar em um link, um invasor poderá iniciar algumas ações potencialmente perigosas, como usar esquemas de URL especiais para iniciar chamadas telefônicas ou do FaceTime, enviar dados ou iniciar ações em aplicativos de terceiros etc. Observe que, mesmo se você controlar a página de destino, o usuário poderá acabar navegando para sites diferentes e não confiáveis.

Exemplo 1: O seguinte trecho de código usa uma webview para carregar um site que pode conter links não confiáveis, mas ele não especifica um delegado capaz de validar as solicitações iniciadas nesta webview:


...
NSURL *webUrl = [[NSURL alloc] initWithString:@"https://some.site.com/"];
NSURLRequest *webRequest = [[NSURLRequest alloc] initWithURL:webUrl];
[webView loadRequest: webRequest];
References
[1] Collin Mulliner iOS WebView auto dialer bug
[2] Apple UIWebViewDelegate
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 501
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001084, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1, MASVS-PLATFORM-2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002360 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.objc.link_injection_missing_validation
Abstract
O método identificado carrega uma página em uma webview, mas não implementa nenhum controle para verificar e validar os links nos quais o usuário poderá clicar.
Explanation
A menos que o conteúdo da página esteja completamente sob seu controle, o usuário poderá clicar em links que podem ser usados por invasores mal-intencionados para iniciar ações indesejadas.

Como exemplo, seu aplicativo pode estar exibindo uma postagem de blog ou tweet que pode conter links. O autor da postagem ou do tweet que seu usuário está visitando poderá usar links arbitrários nas páginas dele. Se os usuários visitarem um site mal-intencionado ou forem enganados ou direcionados automaticamente para clicar em um link, um invasor poderá iniciar algumas ações potencialmente perigosas, como usar esquemas de URL especiais para iniciar chamadas telefônicas ou do FaceTime, enviar dados ou iniciar ações em aplicativos de terceiros etc. Observe que, mesmo se você controlar a página de destino, o usuário poderá acabar navegando para sites diferentes e não confiáveis.

Exemplo 1: O seguinte trecho de código usa uma webview para carregar um site que pode conter links não confiáveis, mas ele não especifica um delegado capaz de validar as solicitações iniciadas nesta webview:


...
let webUrl = URL(string: "https://some.site.com/")!
let urlRequest = URLRequest(url: webUrl)
webView.load(webRequest)
...
References
[1] Collin Mulliner iOS WebView auto dialer bug
[2] Apple UIWebViewDelegate
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 501
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001084, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1, MASVS-PLATFORM-2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002360 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002360 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.swift.link_injection_missing_validation
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo: O seguinte código de aplicativo Web tenta ler um valor de um objeto de solicitação. O valor é registrado em seguida.


...
DATA log_msg TYPE bal_s_msg.

val = request->get_form_field( 'val' ).

log_msg-msgid = 'XY'.
log_msg-msgty = 'E'.
log_msg-msgno = '123'.
log_msg-msgv1 = 'VAL: '.
log_msg-msgv2 = val.

CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
I_S_MSG = log_msg
EXCEPTIONS
LOG_NOT_FOUND = 1
MSG_INCONSISTENT = 2
LOG_IS_FULL = 3
OTHERS = 4.
...


Se um usuário enviar a string "FOO" para val, a seguinte entrada será registrada:


XY E 123 VAL: FOO


No entanto, se um invasor enviar a string "FOO XY E 124 VAL: BAR", a seguinte entrada será registrada:


XY E 123 VAL: FOO XY E 124 VAL: BAR


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.abap.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var val:String = String(params["username"]);
var value:Number = parseInt(val);
if (value == Number.NaN) {
trace("Failed to parse val = " + val);
}


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


Failed to parse val=twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


Failed to parse val=twenty-one

User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.actionscript.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


...
string val = (string)Session["val"];
try {
int value = Int32.Parse(val);
}
catch (FormatException fe) {
log.Info("Failed to parse val= " + val);
}
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.dotnet.log_forging
Abstract
A gravação de entradas do usuário não validadas em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, arquivos de log podem ser analisados manualmente conforme necessário ou examinados automaticamente por ferramentas que pesquisam os logs em busca de importantes pontos de dados ou tendências.

O exame dos arquivos de log poderá ser impedido ou conclusões baseadas em dados de log poderão estar erradas se um invasor tiver permissão para fornecer ao aplicativo dados que posteriormente serão registrados de maneira literal. Um invasor pode inserir entradas falsas no arquivo de log, incluindo caracteres separadores de entradas de log em seus dados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor injeta código ou outros comandos no arquivo de log e tira proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo: O código a seguir de um script CGI aceita uma cadeia de caracteres enviada pelo usuário e tenta convertê-la no valor de inteiro longo que ela representa. Se não for possível analisar o valor como um inteiro, seu valor será registrado em log com uma mensagem de erro indicando o que aconteceu.


long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
syslog(LOG_INFO,"Illegal value = %s",val);
...



Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


Illegal value=twenty-one


No entanto, se um invasor enviar a string "twenty-one\n\nINFO: User logged out=evil", a seguinte entrada será registrada:


INFO: Illegal value=twenty-one

INFO: User logged out=evil


Claramente, o invasor pode usar esse mesmo mecanismo para inserir entradas de log arbitrárias. Para que esse tipo de ataque de falsificação de log seja eficaz, um invasor deve primeiro identificar formatos de entrada de log válidos, mas isso muitas vezes pode ser feito por vazamentos de informações do sistema no aplicativo de destino.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.cpp.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo: O seguinte código do aplicativo Web tenta ler um valor de um formulário HTML. O valor é registrado em seguida.


...
01 LOGAREA.
05 VALHEADER PIC X(50) VALUE 'VAL: '.
05 VAL PIC X(50).
...

EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(VAL)
...
END-EXEC.

EXEC DLI
LOG
FROM(LOGAREA)
LENGTH(50)
END-EXEC.
...


Se um usuário enviar a string "FOO" para VAL, a seguinte entrada será registrada:


VAL: FOO


No entanto, se um invasor enviar a string "FOO VAL: BAR", a seguinte entrada será registrada:


VAL: FOO VAL: BAR


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.cobol.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.


2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.


Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um formulário da Web. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


<cflog file="app_log" application="No" Thread="No"
text="Failed to parse val="#Form.val#">


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


"Information",,"02/28/01","14:50:37",,"Failed to parse val=twenty-one"


No entanto, se um invasor enviar a string "twenty-one%0a%0a%22Information%22%2C%2C%2202/28/01%22%2C%2214:53:40%22%2C%2C%22User%20logged%20out:%20badguy%22", a seguinte entrada será registrada:


"Information",,"02/28/01","14:50:37",,"Failed to parse val=twenty-one"

"Information",,"02/28/01","14:53:40",,"User logged out: badguy"


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.cfml.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para visualização posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
name := r.FormValue("name")
logout := r.FormValue("logout")
...
if (logout){
...
} else {
log.Printf("Attempt to log out: name: %s logout: %s", name, logout)
}
}


Se um usuário enviar a cadeia de caracteres "twenty-one" para logout e ele puder criar um usuário com o nome "admin", a seguinte entrada será armazenada em log:


Attempt to log out: name: admin logout: twenty-one


No entanto, se um invasor puder criar um nome de usuário "admin+logout:+1+++++++++++++++++++++++", a seguinte entrada será armazenada em log:


Attempt to log out: name: admin logout: 1 logout: twenty-one
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.golang.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException nfe) {
log.info("Failed to parse val = " + val);
}
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.

Algumas pessoas acham que, no mundo móvel, vulnerabilidades clássicas de aplicativos Web, como a falsificação de logs, não fazem sentido -- por que um usuário atacaria ele próprio? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos que são baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 2: O código a seguir adapta o Example 1 à plataforma Android.


...
String val = this.getIntent().getExtras().getString("val");
try {
int value = Integer.parseInt();
}
catch (NumberFormatException nfe) {
Log.e(TAG, "Failed to parse val = " + val);
}
...
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] IDS03-J. Do not log unsanitized user input CERT
desc.dataflow.java.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
var val = url.parse(request.url, true)['query']['val'];
if (isNaN(val)){
console.log("INFO: Failed to parse val = " + val);
}
...
}
...
http.createServer(listener).listen(8080);
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Failed to parse val = twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.javascript.log_forging
Abstract
A função identificada grava entradas de usuário inválidas no registro. Um invasor pode tirar vantagem desse comportamento para falsificar entradas de log ou injetar conteúdo mal-intencionado no log.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, arquivos de log podem ser analisados manualmente conforme necessário ou examinados automaticamente por ferramentas que pesquisam os logs em busca de importantes pontos de dados ou tendências.

O exame dos arquivos de log poderá ser impedido ou conclusões baseadas em dados de log poderão estar erradas se um invasor tiver permissão para fornecer ao aplicativo dados que posteriormente serão registrados de maneira literal. Um invasor pode inserir entradas falsas no arquivo de log, incluindo caracteres separadores de entradas de log em seus dados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor injeta código ou outros comandos no arquivo de log e tira proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O código a seguir de um script CGI aceita uma cadeia de caracteres enviada pelo usuário e tenta convertê-la no valor de inteiro longo que ela representa. Se não for possível analisar o valor como um inteiro, seu valor será registrado em log com uma mensagem de erro indicando o que aconteceu.


long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
NSLog("Illegal value = %s",val);
...



Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Illegal value=twenty-one


No entanto, se um invasor enviar a string "twenty-one\n\nINFO: User logged out=evil", a seguinte entrada será registrada:


INFO: Illegal value=twenty-one

INFO: User logged out=evil


Claramente, o invasor pode usar esse mesmo mecanismo para inserir entradas de log arbitrárias. Para que esse tipo de ataque de falsificação de log seja eficaz, um invasor deve primeiro identificar os formatos de entrada de log válidos, mas isso muitas vezes pode ser feito por meio de vazamentos de informações do sistema no aplicativo de destino.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.objc.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


<?php
$name =$_GET['name'];
...
$logout =$_GET['logout'];

if(is_numeric($logout))
{
...
}
else
{
trigger_error("Attempt to log out: name: $name logout: $val");
}
?>


Se um usuário enviar a cadeia de caracteres "twenty-one" para logout e ele puder criar um usuário com o nome "admin", a seguinte entrada será armazenada em log:


PHP Notice: Attempt to log out: name: admin logout: twenty-one


No entanto, se um invasor puder criar um nome de usuário "admin+logout:+1+++++++++++++++++++++++", a seguinte entrada será armazenada em log:


PHP Notice: Attempt to log out: name: admin logout: 1 logout: twenty-one
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.php.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


name = req.field('name')
...
logout = req.field('logout')

if (logout):
...
else:
logger.error("Attempt to log out: name: %s logout: %s" % (name,logout))


Se um usuário enviar a cadeia de caracteres "twenty-one" para logout e ele puder criar um usuário com o nome "admin", a seguinte entrada será armazenada em log:


Attempt to log out: name: admin logout: twenty-one


No entanto, se um invasor puder criar um nome de usuário "admin+logout:+1+++++++++++++++++++++++", a seguinte entrada será armazenada em log:


Attempt to log out: name: admin logout: 1 logout: twenty-one
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.python.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


...
val = req['val']
unless val.respond_to?(:to_int)
logger.info("Failed to parse val")
logger.info(val)
end
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Failed to parse val
INFO: twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


INFO: Failed to parse val
INFO: twenty-one

INFO: User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.ruby.log_forging
Abstract
A função identificada grava entradas de usuário inválidas no registro. Um invasor pode tirar vantagem desse comportamento para falsificar entradas de log ou injetar conteúdo mal-intencionado no log.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, arquivos de log podem ser analisados manualmente conforme necessário ou examinados automaticamente por ferramentas que pesquisam os logs em busca de importantes pontos de dados ou tendências.

O exame dos arquivos de log poderá ser impedido ou conclusões baseadas em dados de log poderão estar erradas se um invasor tiver permissão para fornecer ao aplicativo dados que posteriormente serão registrados de maneira literal. Um invasor pode inserir entradas falsas no arquivo de log, incluindo caracteres separadores de entradas de log em seus dados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor injeta código ou outros comandos no arquivo de log e tira proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O código a seguir aceita uma cadeia de caracteres enviada pelo usuário e tenta convertê-la no valor de inteiro que ela representa. Se não for possível analisar o valor como um inteiro, seu valor será registrado em log com uma mensagem de erro indicando o que aconteceu.


...
let num = Int(param)
if num == nil {
NSLog("Illegal value = %@", param)
}
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Illegal value = twenty-one


No entanto, se um invasor enviar a string "twenty-one\n\nINFO: User logged out=evil", a seguinte entrada será registrada:


INFO: Illegal value=twenty-one

INFO: User logged out=evil


Claramente, o invasor pode usar esse mesmo mecanismo para inserir entradas de log arbitrárias. Para que esse tipo de ataque de falsificação de log seja eficaz, um invasor deve primeiro identificar os formatos de entrada de log válidos, mas isso muitas vezes pode ser feito por meio de vazamentos de informações do sistema no aplicativo de destino.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.swift.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


...
Dim Val As Variant
Dim Value As Integer
Set Val = Request.Form("val")
If IsNumeric(Val) Then
Set Value = Val
Else
App.EventLog "Failed to parse val=" & Val, 1
End If
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


Failed to parse val=twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0a+User+logged+out%3dbadguy", a seguinte entrada será registrada:


Failed to parse val=twenty-one

User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.vb.log_forging
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.



2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.



Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor poderia injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O endpoint REST a seguir tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


@HttpGet
global static void doGet() {
RestRequest req = RestContext.request;
String val = req.params.get('val');
try {
Integer i = Integer.valueOf(val);
...
} catch (TypeException e) {
System.Debug(LoggingLevel.INFO, 'Failed to parse val: '+val);
}
}


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


Failed to parse val: twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aUser+logged+out%3dbadguy", a seguinte entrada será registrada:


Failed to parse val: twenty-one

User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.apex.log_forging__debug_
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation

Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


...
String val = request.Params["val"];
try {
int value = Int.Parse(val);
}
catch (FormatException fe) {
log.Info("Failed to parse val = " + val);
}
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.

Algumas pessoas acham que, no mundo móvel, vulnerabilidades clássicas de aplicativos Web, como a falsificação de logs, não fazem sentido -- por que um usuário atacaria ele próprio? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos que são baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 2: O código a seguir adapta o Example 1 à plataforma Android.


...
String val = this.Intent.Extras.GetString("val");
try {
int value = Int.Parse(val);
}
catch (FormatException fe) {
Log.E(TAG, "Failed to parse val = " + val);
}
...
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] IDS03-J. Do not log unsanitized user input CERT
desc.dataflow.dotnet.log_forging__debug_
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log poderia ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log poderia ser impedida ou equivocada se um invasor pode fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, um invasor pode usar arquivos de log corrompidos para apagar o rastro ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor poderia injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro para indicar o que aconteceu.


...
var idValue string

idValue = req.URL.Query().Get("id")
num, err := strconv.Atoi(idValue)

if err != nil {
sysLog.Debug("Failed to parse value: " + idValue)
}
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.

References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] IDS03-J. Do not log unsanitized user input CERT
desc.dataflow.golang.log_forging__debug
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException nfe) {
log.info("Failed to parse val = " + val);
}
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.

Algumas pessoas acham que, no mundo móvel, vulnerabilidades clássicas de aplicativos Web, como a falsificação de logs, não fazem sentido -- por que um usuário atacaria ele próprio? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos que são baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 2: O código a seguir adapta o Example 1 à plataforma Android.


...
String val = this.getIntent().getExtras().getString("val");
try {
int value = Integer.parseInt();
}
catch (NumberFormatException nfe) {
Log.e(TAG, "Failed to parse val = " + val);
}
...
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] IDS03-J. Do not log unsanitized user input CERT
desc.dataflow.java.log_forging__debug_
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
var val = url.parse(request.url, true)['query']['val'];
if (isNaN(val)){
console.error("INFO: Failed to parse val = " + val);
}
...
}
...
http.createServer(listener).listen(8080);
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.javascript.log_forging__debug_
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


...
val = request.GET["val"]
try:
int_value = int(val)
except:
logger.debug("Failed to parse val = " + val)
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.python.log_forging__debug_
Abstract
A gravação da entrada do usuário em arquivos de log pode permitir que um invasor falsifique entradas de log ou injete conteúdo mal-intencionado nos logs.
Explanation
Vulnerabilidades de falsificação de log ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são gravados em um arquivo de log de aplicativo ou sistema.

Em geral, aplicativos usam arquivos de log para armazenar um histórico de eventos ou transações para análise posterior, coleta de estatísticas ou depuração. Dependendo da natureza do aplicativo, a tarefa de analisar arquivos de log pode ser realizada manualmente conforme necessário ou automatizada com uma ferramenta que examina os logs automaticamente em busca de eventos importantes ou informações que possam definir tendências.

A interpretação dos arquivos de log pode ser impedida ou equivocada se um invasor puder fornecer dados ao aplicativo que mais tarde são registrados textualmente. No caso mais benigno, um invasor pode ser capaz de inserir entradas falsas no arquivo de log, fornecendo ao aplicativo uma entrada que inclui caracteres apropriados. Se o arquivo de log for processado automaticamente, o invasor poderá tornar o arquivo inutilizável, corrompendo seu formato ou injetando caracteres inesperados. Um ataque mais sutil pode envolver a distorção das estatísticas do arquivo de log. Falsificados ou não, os arquivos de log corrompidos podem ser usados para apagar o rastro do invasor ou até mesmo para implicar terceiros na prática de um ato mal-intencionado [1]. Na pior das hipóteses, um invasor pode injetar código ou outros comandos no arquivo de log e tirar proveito de uma vulnerabilidade no utilitário de processamento de log [2].

Exemplo 1: O seguinte código de aplicativo Web tenta ler um valor de número inteiro de um objeto de solicitação. Se não for possível analisar o valor como um número inteiro, a entrada será registrada em log com uma mensagem de erro indicando o que aconteceu.


...
val = req['val']
unless val.respond_to?(:to_int)
logger.debug("Failed to parse val")
logger.debug(val)
end
...


Se um usuário enviar a string "twenty-one" para val, a seguinte entrada será registrada:


DEBUG: Failed to parse val
DEBUG: twenty-one


No entanto, se um invasor enviar a string "twenty-one%0a%DEBUG:+User+logged+out%3dbadguy", a seguinte entrada será registrada:


DEBUG: Failed to parse val
DEBUG: twenty-one

DEBUG: User logged out=badguy


Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.ruby.log_forging__debug_
Abstract
A execução de comandos IMAP provenientes de uma fonte não confiável pode fazer com que o servidor IMAP execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comando IMAP ocorrem quando um invasor pode influenciar os comandos enviados a um servidor de e-mail IMAP.

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

2. Os dados são usados como uma string, ou parte de uma string, que representa um comando executado pelo aplicativo.

3. Ao executar o comando IMAP, o invasor é capaz de instruir o servidor a realizar ações mal-intencionadas, como o envio de spam.

Exemplo 1: O código a seguir usa um parâmetro de solicitação HTTP para elaborar um comando CREATE que é enviado ao servidor IMAP. Um invasor pode usar esse parâmetro para modificar o comando enviado ao servidor e injetar novos comandos usando caracteres CRLF.


...
final String foldername = request.getParameter("folder");
IMAPFolder folder = (IMAPFolder) store.getFolder("INBOX");
...
folder.doCommand(new IMAPFolder.ProtocolCommand() {
@Override
public Object doCommand(IMAPProtocol imapProtocol) throws ProtocolException {
try {
imapProtocol.simpleCommand("CREATE " + foldername, null);
} catch (Exception e) {
// Handle Exception
}
return null;
}
});
...
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - Common Weakness Enumeration CWE ID 88, CWE ID 93, CWE ID 147
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [25] CWE ID 077
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [17] CWE ID 077
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [16] CWE ID 077
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[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 SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[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 A03 Injection
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.3 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.2 Sanitization and Sandboxing Requirements (L1 L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[26] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[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.2
[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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Mail Command Injection (WASC-30)
desc.dataflow.java.mail_command_injection_imap
Abstract
A execução de comandos POP3 provenientes de uma fonte não confiável pode fazer com que o servidor POP3 execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comando POP3 ocorrem quando um invasor pode influenciar os comandos enviados a um servidor de e-mail POP3.

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

2. Os dados são usados como uma string, ou parte de uma string, que representa um comando executado pelo aplicativo.

3. Ao executar o comando POP3, o invasor é capaz de instruir o servidor a realizar ações mal-intencionadas, como o envio de spam.

Exemplo 1: O código a seguir usa um parâmetro de solicitação HTTP para elaborar um comando USER e PASS que é enviado ao servidor POP3. Um invasor pode usar esse parâmetro para modificar o comando enviado ao servidor e injetar novos comandos usando caracteres CRLF.


...
String username = request.getParameter("username");
String password = request.getParameter("password");
...
POP3SClient pop3 = new POP3SClient(proto, false);
pop3.login(username, password)
...
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - Common Weakness Enumeration CWE ID 88, CWE ID 93, CWE ID 147
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [25] CWE ID 077
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [17] CWE ID 077
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [16] CWE ID 077
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[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 SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[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 A03 Injection
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.3 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.2 Sanitization and Sandboxing Requirements (L1 L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[26] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[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.2
[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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Mail Command Injection (WASC-30)
desc.dataflow.java.mail_command_injection_pop3