Reino: Input Validation and Representation

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

175 itens encontrados
Vulnerabilidades

Buffer Overflow: Format String (%f/%F)

Abstract
O programa usa uma cadeia de formato indevidamente limitada que inclui um especificador de ponto flutuante %f ou %F. Valores de ponto flutuante inesperadamente grandes podem fazer com que o programa grave dados fora dos limites da memória alocada, o que pode corromper dados, fazer com que o programa trave ou provocar a execução de código mal-intencionado.
Explanation
O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa grave além dos limites da memória alocada.

Exemplo: O código a seguir estoura buf porque, dependendo do tamanho de f, o especificador de cadeia de formato "%d %.1f ... " pode exceder a quantidade de memória alocada.


void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 787
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [12] CWE ID 787
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [2] CWE ID 787
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[40] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[41] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_format_string_%f_%F

Buffer Overflow: Off-by-One

Abstract
O programa grava além dos limites da memória alocada, o que pode corromper dados, fazer com que o programa trave ou provocar a execução de código mal-intencionado.
Explanation
O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de erro "off-by-one" ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e de pilha, entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Exemplo: O código a seguir contém um estouro de buffer "off-by-one", que ocorre quando recv retorna os bytes máximos permitidos de sizeof(buf) que foram lidos. Nesse caso, a desreferência subsequente de buf[nbytes] gravará o byte null fora dos limites da memória alocada.


void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 129, CWE ID 131, CWE ID 193, CWE ID 787, CWE ID 805
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [3] CWE ID 020, [12] CWE ID 787
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [3] CWE ID 020, [2] CWE ID 787
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787, [4] CWE ID 020, [17] CWE ID 119
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787, [4] CWE ID 020, [19] CWE ID 119
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787, [6] CWE ID 020, [17] CWE ID 119
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1, Rule 18-0-5
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[27] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[28] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[41] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[42] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 805, Risky Resource Management - CWE ID 129, Risky Resource Management - CWE ID 131
[43] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 131
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3590.1 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3590.1 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3590.1 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[66] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_off_by_one

Buffer Overflow: Signed Comparison

Abstract
O programa usa uma comparação com sinal para verificar um valor que posteriormente é tratado como sem sinal. Isso pode fazer com que o programa grave fora dos limites da memória alocada, o que pode corromper dados, fazer com que o programa trave ou provocar a execução de código mal-intencionado.
Explanation
O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Exemplo: O código a seguir tenta evitar um buffer overflow de leitura "off-by-one", verificando que o valor não confiável lido de getInputLength() é menor que o tamanho do buffer de destino output. No entanto, como a comparação entre len e MAX tem sinal, se len for negativo, ele se tornará um número positivo muito grande quando for convertido em um argumento sem sinal para memcpy().


void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 195, CWE ID 805
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [17] CWE ID 119
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [19] CWE ID 119
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [17] CWE ID 119
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[40] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 805
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3550 CAT I, APP3590.1 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3550 CAT I, APP3590.1 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3550 CAT I, APP3590.1 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3550 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3550 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3550 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3550 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_signed_comparison

Client-Side Template Injection

Abstract
Os dados controlados pelo usuário são usados como um modelo do mecanismo de modelo, que permite que invasores acessem o contexto do modelo e, em alguns casos, injetem e executem código mal-intencionado no navegador.
Explanation
Mecanismos de modelo são usados para renderizar conteúdo usando dados dinâmicos. Esses dados de contexto normalmente são controlados pelo usuário e formatados pelo modelo para gerar páginas da Web, e-mails, entre outros. Os mecanismos de modelo permitem que expressões de linguagem poderosas sejam usadas em modelos para renderizar conteúdo dinâmico, processando os dados de contexto com construções de código como condicionais, loops etc. Se um invasor puder controlar o modelo a ser renderizado, poderá injetar expressões que exponham dados de contexto e executem código mal-intencionado no navegador.

Exemplo 1: O exemplo a seguir mostra como um modelo é recuperado de uma URL e renderiza informações com AngularJS.

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}


Nesse caso, $stateParams.expression obterá possivelmente dados controlados pelo usuário e os avaliará como um modelo a ser usado com um contexto especificado. Por sua vez, isso pode permitir que um usuário mal-intencionado execute qualquer código que ele desejar no navegador, recuperando informações sobre o contexto com base no qual ele é executado, encontrando informações adicionais sobre como o aplicativo é criado ou transformando isso em um completo ataque de XSS.
References
[1] AngularJS Security Guide Google
desc.dataflow.javascript.client_side_template_injection

ColdFusion Bad Practices: Unauthorized Include

Abstract
Permitir que entradas de usuário não validadas especifiquem o caminho de um arquivo incluído na página pode permitir que invasores injetem código mal-intencionado ou visualizem arquivos confidenciais no servidor.
Explanation
Vulnerabilidades de inclusão não autorizada ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação da Web.

2. Os dados fazem parte da string que especifica o atributo template de uma tag <cfinclude>.
Exemplo: O código a seguir usa a entrada de um formulário da Web para construir o caminho para um arquivo especial utilizado para formatar a página inicial do usuário. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo mal-intencionado, como "../../users/wileyh/malicious", que fará com que o aplicativo inclua e execute o conteúdo de um arquivo no diretório base do invasor. 


<cfinclude template =  
              "C:\\custom\\templates\\#Form.username#.cfm">


Se um invasor tiver permissão para especificar o arquivo incluído pela tag <cfinclude>, ele poderá fazer com que o aplicativo inclua na página atual o conteúdo de quase qualquer arquivo do sistema de arquivos do servidor. Essa capacidade pode ser aproveitada de pelo menos duas maneiras significativas. Se um invasor puder gravar em uma localização no sistema de arquivos do servidor, como o diretório base do usuário ou um diretório de upload comum, ele pode fazer com que o aplicativo inclua um arquivo elaborado de maneira mal-intencionada na página, que em seguida será executado pelo servidor. Mesmo sem acesso de gravação ao sistema de arquivos do servidor, um invasor pode muitas vezes obter acesso a informações confidenciais ou privadas especificando o caminho de um arquivo no servidor.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 94
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cfml.unauthorized_include

Command Injection

Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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

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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema usa a chave do registro APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.


...
CALL FUNCTION 'REGISTRY_GET'
  EXPORTING
     KEY   = 'APPHOME'
  IMPORTING
     VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a entrada do registro APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do registo, se um invasor puder controlar o valor da chave do registro APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.


...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
  EXPORTING
    commandname                   = cmd_exe
    long_params                   = cmd_string
  EXCEPTIONS
    no_permission                 = 1
    command_not_found             = 2
    parameters_too_long           = 3
    security_risk                 = 4
    OTHERS                        = 5.
...


O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função SXPG_COMMAND_EXECUTE_LONG não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para CALL 'SYSTEM'. Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.


...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para CALL 'SYSTEM'. Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.
References
[1] SAP OSS notes 677435, 686765, 866732, 854060, 1336776, 1520462, 1530983 and related notes.
desc.dataflow.abap.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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

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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir usa uma entrada de arquivo de configuração para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.


        ...
        var fs:FileStream = new FileStream();
        fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
        home = String(fs.readObject(home));
        var cmd:String = home + INITCMD;
        fscommand("exec", cmd);
        ...


O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando o conteúdo do arquivo de configuração configStream de forma que ele aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do arquivo, se um invasor puder controlar esse valor, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.


        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var btype:String = String(params["backuptype"]);
        var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
        fscommand("exec", cmd);
        ...


O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função fscommand() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para fscommnd(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.


        ...
        fscommand("exec", "make");
        ...


O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para fscommand(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.
desc.dataflow.actionscript.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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

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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.


...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...


O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.


...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
              + btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...


O problema aqui é que o programa não realiza validações em BackupTypeField. Em geral, a função Process.Start() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para Process.Start(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que dá aos usuários acesso a uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas nesse ambiente de rede é executar um comando update.exe, da seguinte forma:


...
Process.Start("update.exe");
...


O problema aqui é que o programa não especifica um caminho absoluto e não consegue limpar o respectivo ambiente antes de executar a chamada de Process.start(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado update.exe e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o update.exe do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.
desc.dataflow.dotnet.command_injection
Abstract
A execução de comandos que incluem entradas do usuário não validadas pode fazer com que um aplicativo atue em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, no qual um invasor controla explicitamente o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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


2. Os dados fazem parte de uma string que é executada como um comando pelo aplicativo.


3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O seguinte programa simples aceita um nome de arquivo como um argumento de linha de comando e exibe o conteúdo desse arquivo de volta para o usuário. O programa é instalado em setuid root porque se destina para uso como uma ferramenta de aprendizagem, para permitir que administradores de sistema em treinamento inspecionem arquivos de sistema com privilégios sem lhes dar a capacidade de modificá-los ou danificar o sistema.


int main(char* argc, char** argv) {
	char cmd[CMD_MAX] = "/usr/bin/cat ";
	strcat(cmd, argv[1]);
	system(cmd);
}


Como o programa é executado com privilégios de root, a chamada para system() também é executada com privilégios de root. Se um usuário especificar um nome de arquivo padrão, a chamada funcionará conforme esperado. No entanto, se um invasor transmitir uma string de caracteres no formato ";rm -rf /", a chamada para system() não conseguirá executar cat devido a uma falta de argumentos e, em seguida, abrirá caminho para excluir recursivamente o conteúdo da partição root.

Exemplo 2: O seguinte código de um programa privilegiado usa a variável de ambiente $APPHOME para determinar o diretório de instalação do aplicativo e, em seguida, executa um script de inicialização nesse diretório.


	...
	char* home=getenv("APPHOME");
	char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
	if (cmd) {
		strcpy(cmd,home);
		strcat(cmd,INITCMD);
		execl(cmd, NULL);
	}
	...


Como no Example 1, o código no exemplo permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo. Nesse exemplo, o invasor pode modificar a variável de ambiente $APPHOME para especificar um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, ao controlar a variável de ambiente, o invasor pode enganar o aplicativo, fazendo com que este execute um código mal-intencionado.

O invasor está usando a variável de ambiente para controlar o comando que o programa invoca e, portanto, o efeito do ambiente é explícito nesse exemplo. Vamos agora voltar nossa atenção para o que pode acontecer quando o invasor consegue mudar a maneira como o comando é interpretado.

Exemplo 3: O código a seguir é proveniente de um utilitário CGI baseado na Web que permite aos usuários alterar suas senhas. O processo de atualização de senha no NIS inclui a execução de make no diretório /var/yp. Observe que, como o programa atualiza registros de senha, ele foi instalado em setuid root.

O programa invoca make da seguinte maneira:


system("cd /var/yp && make &> /dev/null");


Diferentemente dos exemplos anteriores, o comando nesse exemplo está inserido em código fixo para que um invasor não possa controlar o argumento transmitido para system(). No entanto, como o programa não especifica um caminho absoluto para make e não limpa as respectivas variáveis de ambiente antes de invocar o comando, o invasor pode modificar a respectiva variável $PATH de forma que ela aponte para um binário mal-intencionado denominado make e execute o script CGI de um prompt de shell. E, como o programa foi instalado em setuid root, a versão do invasor de make agora é executada com privilégios de root.

No Windows, existem riscos adicionais presentes.

Exemplo 4: Ao invocar CreateProcess() diretamente ou através de uma chamada para uma das funções na família _spawn(), é necessário ter cautela quando existe um espaço em um executável ou caminho.


...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...


Devido à maneira como CreateProcess() analisa espaços, o primeiro executável que o sistema operacional tentará executar é Program.exe, e não MyApplication.exe. Portanto, se um invasor for capaz de instalar um aplicativo mal-intencionado denominado Program.exe no sistema, qualquer programa que chamar CreateProcess() incorretamente usando o diretório Program Files executará esse aplicativo em vez daquele pretendido.

O ambiente desempenha um papel poderoso na execução de comandos do sistema dentro de programas. Funções como system(), exec() e CreateProcess() usam o ambiente do programa que as chama e, portanto, os invasores têm uma oportunidade potencial para influenciar o comportamento dessas chamadas.
desc.dataflow.cpp.command_injection
Abstract
Executar comandos sem especificar um caminho absoluto pode permitir que um invasor use o programa para executar um binário mal-intencionado alterando $PATH ou outros aspectos do ambiente de execução do programa.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando que o programa executa: o invasor controla explicitamente o comando.

- Um invasor pode controlar os parâmetros do programa.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o segundo cenário, no qual um invasor pode modificar o significado do comando alterando uma variável de ambiente ou inserindo um executável mal-intencionado no início do caminho de pesquisa. Vulnerabilidades de Command injection desse tipo ocorrem quando:

1. Um invasor modifica o ambiente de um aplicativo.

2. O aplicativo executa um comando sem especificar um caminho absoluto ou verificar o binário que está sendo executado.



3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: Esse exemplo demonstra o que pode acontecer quando o invasor consegue alterar a forma como um comando é interpretado. O código é proveniente de um utilitário CGI baseado na Web que permite aos usuários alterar suas senhas. O processo de atualização de senha no NIS inclui a execução de make no diretório /var/yp. Observe que, como o programa atualiza registros de senha, ele foi instalado em setuid root.

O programa invoca make da seguinte maneira:


MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
                               length of command-line
                               run-unit-id
                               stack-size
                               flags


O comando nesse exemplo é hardcoded. Portanto, um invasor não pode controlar o argumento passado para CBL_EXEC_RUN_UNIT. No entanto, como o programa não especifica um caminho absoluto para make e não limpa suas variáveis de ambiente antes de invocar o comando, o invasor pode modificar sua variável $PATH para apontar para um binário mal-intencionado chamado make e executar o script CGI por meio de um prompt de shell. Além disso, como o programa foi instalado com setuid root, a versão do invasor de make agora é executada com privilégios de root.

Exemplo 2: O código a seguir usa uma variável de ambiente para determinar o diretório temporário que contém o arquivo a ser impresso com o comando pdfprint.


DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
             ws-temp-dir DELIMITED SPACE
             "/" DELIMITED SIZE
             ws-pdf-filename DELIMITED SPACE
             x"00" DELIMITED SIZE
             INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer


De maneira semelhante ao exemplo anterior, o comando é hardcoded. No entanto, como o programa não especifica um caminho absoluto para pdfprint, o invasor pode modificar a variável $PATH para apontar para um binário mal-intencionado. Além disso, embora as frases DELIMITED SPACE evitem espaços embutidos em ws-temp-dir e ws-pdf-filename, pode haver metacaracteres de shell (como &&) embutidos em qualquer um deles.
desc.semantic.cobol.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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

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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir permite que um invasor especifique comandos arbitrários através do parâmetro de solicitação cmd.


    ...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
    arguments = "/c #var#"
    timeout = "1"
    variable="mycmd">
</cfexecute>
    ...
desc.dataflow.cfml.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando que o programa executa: o invasor controla explicitamente qual é o comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, a possibilidade de um invasor controlar o comando executado. Vulnerabilidades de Command injection desse tipo ocorrem quando:

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

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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo do diretório especificado.


	...
	final cmd = String.fromEnvironment('APPHOME');
    await Process.run(cmd);
	...


O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.
desc.dataflow.dart.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando que o programa executa: o invasor controla explicitamente o comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, a possibilidade de um invasor controlar o comando executado. Vulnerabilidades de Command injection desse tipo ocorrem quando:

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


2. Os dados são usados como parte de uma cadeia de caracteres que representa um comando que o aplicativo executa.

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo: O código a seguir executa um comando controlado pelo usuário.


  cmdName := request.FormValue("Command")
  c := exec.Command(cmdName)
  c.Run()
desc.dataflow.golang.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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

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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.


	...
	String home = System.getProperty("APPHOME");
	String cmd = home + INITCMD;
	java.lang.Runtime.getRuntime().exec(cmd);
	...


O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.


...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...


O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função Runtime.exec() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para Runtime.exec(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.


...
System.Runtime.getRuntime().exec("make");
...


O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para Runtime.exec(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Algumas pessoas acham que, no mundo móvel, vulnerabilidades clássicas, como injeção de comandos, 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 4: O código a seguir lê comandos a serem executados a partir de uma intenção do Android.


...
        String[] cmds = this.getIntent().getStringArrayExtra("commands");
	Process p = Runtime.getRuntime().exec("su");
        DataOutputStream os = new DataOutputStream(p.getOutputStream());
        for (String cmd : cmds) {
        	os.writeBytes(cmd+"\n");
        }
        os.writeBytes("exit\n");
        os.flush();
...


Em um dispositivo root, um aplicativo mal-intencionado pode forçar o aplicativo de uma vítima a executar comandos arbitrários com privilégios de superusuário.
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.java.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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


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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: Este código de um utilitário do sistema usa a variável de ambiente APPHOME para determinar o diretório no qual será instalado e executa um script de inicialização com base em um caminho relativo do diretório especificado.


var cp = require('child_process');
  ...
  var home = process.env('APPHOME');
  var cmd = home + INITCMD;
  child = cp.exec(cmd, function(error, stdout, stderr){
    ...
  });
  ...


O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Uma vez que o programa não valida o valor lido a partir do ambiente, se um invasor puder controlar o valor da propriedade do sistemaAPPHOME, poderá enganar o aplicativo para que execute o código malicioso e assumir o controle do sistema.

Exemplo 2: Este código é de um aplicativo da Web administrativo projetado para permitir os usuários a iniciar o backup de um banco de dados Oracle usando um wrapper de arquivo em lote no utilitário rman. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.


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

function listener(request, response){
  var btype = url.parse(request.url, true)['query']['backuptype'];
  if (btype !== undefined){
    cmd = "c:\\util\\rmanDB.bat" + btype;
    cp.exec(cmd, function(error, stdout, stderr){
      ...
    });
  }
  ...
}
...
http.createServer(listener).listen(8080);


O problema aqui é que o programa não faz qualquer validação na leitura do parâmetro backuptype a partir do usuário além de verificar a sua existência. Depois que o shell é invocado, ele poderá permitir a execução de vários comandos e, devido à natureza do aplicativo, ele será executado com os privilégios necessários para interagir com o banco de dados: isso significa que, seja lá o que o invasor injetar, será executado com os mesmos privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.


...
require('child_process').exec("make", function(error, stdout, stderr){
  ...
});
...


O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada de child_process.exec(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.
desc.dataflow.javascript.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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

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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.


	...
	$home = $_ENV['APPHOME'];
	$cmd = $home . $INITCMD;
	system(cmd);
	...


O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.


...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...


O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função Runtime.exec() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para Runtime.exec(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.


...
$result = shell_exec("make");
...


O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para Runtime.exec(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.
desc.dataflow.php.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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

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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo: O código a seguir define um procedimento armazenado T-SQL que, ao ser chamado com dados não confiáveis, executará um comando do sistema controlado por um invasor.


...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...
References
[1] xp_cmdshell
desc.dataflow.sql.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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

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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.


	...
	home = os.getenv('APPHOME')
	cmd = home.join(INITCMD)
	os.system(cmd);
	...


O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.


...
	btype = req.field('backuptype')
	cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
	os.system(cmd);
...


O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função Runtime.exec() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para Runtime.exec(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.


...
result = os.system("make");
...


O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para os.system(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.
desc.dataflow.python.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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


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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.


...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...


O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.


...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...


O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Depois que o shell é invocado via Kernel.spawn, ele permitirá a execução de vários comandos separados por dois sinais tipográficos &. Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.


...
system("make")
...


O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para Kernel.system(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.
desc.dataflow.ruby.command_injection
Abstract
A execução de comandos que incluem entradas do usuário não validadas pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o segundo cenário, com a possibilidade de que um invasor seja capaz de modificar o significado do comando alterando uma variável de ambiente ou colocando um executável mal-intencionado no início do caminho de pesquisa. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

1. Um invasor modifica o ambiente de um aplicativo.

2. O aplicativo executa um comando sem especificar um caminho absoluto ou sem verificar o binário que está sendo executado.

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. 


def changePassword(username: String, password: String) = Action { request =>
    ...
    s'echo "${password}" | passwd ${username} --stdin'.!
    ...
}
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.scala.command_injection
Abstract
A execução de comandos de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.
Explanation
Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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

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

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.


	...
	Dim cmd
	Dim home

	home = Environ$("AppHome")
	cmd = home & initCmd
	Shell cmd, vbNormalFocus
	...


O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.


...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...


O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.


...
$result = shell_exec("make");
...


O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para Runtime.exec(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.
desc.dataflow.vb.command_injection

Command Injection: GitHub Actions

Abstract
A referência direta de expressões específicas do GitHub Action em um script de execução do GitHub Actions deixa o sistema vulnerável à injeção de comando.
Explanation
Referências diretas a expressões do GitHub Action em um script de execução são geradas dinamicamente. Isso permite que qualquer pessoa com controle da entrada comprometa o sistema usando injeção de comando.

Exemplo 1: O código a seguir de um GitHub Action faz referência direta a uma expressão em um script de execução que deixa o sistema aberto para injeção de comando.


    ...
    steps:
      - run: echo "${{  github.event.pull_request.title  }}"
    ...


Quando a ação é executada, o script de shell é executado dinamicamente, incluindo qualquer código que o valor github.event.pull_request.title represente. Se o github.event.pull_request.title contiver código executável malicioso, a ação executará o código malicioso, o que resultará na injeção de comando.

References
[1] Security Hardening for GitHub Actions - Good Practices for Mitigating Script Injection Attacks
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[16] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2010 A1 Injection
[22] Standards Mapping - OWASP Top 10 2013 A1 Injection
[23] Standards Mapping - OWASP Top 10 2017 A1 Injection
[24] Standards Mapping - OWASP Top 10 2021 A03 Injection
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.2 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.3 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.8 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.2 File Execution Requirements (L1 L2 L3), 12.3.5 File Execution Requirements (L1 L2 L3)
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M2 Inadequate Supply Chain Security
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[40] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[41] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
desc.structural.yaml.command_injection_github_actions