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.
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 um objeto de solicitação. O valor é registrado em seguida.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
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.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a cadeia de caracteres "
No entanto, se um invasor puder criar um nome de usuário "
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
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
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
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - Common Weakness Enumeration CWE ID 117
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 AU, SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[14] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[17] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[23] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[25] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[26] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
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.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a cadeia de caracteres "
No entanto, se um invasor puder criar um nome de usuário "
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a cadeia de caracteres "
No entanto, se um invasor puder criar um nome de usuário "
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
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.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
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.
Se um usuário enviar a string "
No entanto, se um invasor enviar a string "
Claramente, os invasores podem usar esse mesmo mecanismo para inserir entradas de log arbitrárias.
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
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.vb.log_forging