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.
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
O código no
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
O problema aqui é que o programa não realiza validações no parâmetro
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
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
- 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.
[2] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[7] Standards Mapping - FIPS200 SI
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] 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)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - 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
[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.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 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 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[61] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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.
O código no
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
O problema aqui é que o programa não realiza validações no parâmetro
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
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
- 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.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
O código no
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
O problema aqui é que o programa não realiza validações em
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
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
- 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.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
Como o programa é executado com privilégios de
Exemplo 2: O seguinte código de um programa privilegiado usa a variável de ambiente
Como no
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
O programa invoca
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
No Windows, existem riscos adicionais presentes.
Exemplo 4: Ao invocar
Devido à maneira como
O ambiente desempenha um papel poderoso na execução de comandos do sistema dentro de programas. Funções como
- 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.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
O programa invoca
O comando nesse exemplo é hardcoded. Portanto, um invasor não pode controlar o argumento passado para
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
De maneira semelhante ao exemplo anterior, o comando é hardcoded. No entanto, como o programa não especifica um caminho absoluto para
- 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.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
- 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>
...
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
O código no
- 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.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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.
- 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()
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
O código no
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
O problema aqui é que o programa não realiza validações no parâmetro
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
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
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.
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.
- 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
[2] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[7] Standards Mapping - FIPS200 SI
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] 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)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - 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
[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.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 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 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[61] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
O código no
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
O problema aqui é que o programa não faz qualquer validação na leitura do parâmetro
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
O problema aqui é que o programa não especifica um caminho absoluto para
- 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.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
O código no
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
O problema aqui é que o programa não realiza validações no parâmetro
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
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
- 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.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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.
- 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
[2] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[7] Standards Mapping - FIPS200 SI
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] 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)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - 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
[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.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 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 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[61] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
O código no
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
O problema aqui é que o programa não realiza validações no parâmetro
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
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
- 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.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
O código no
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
O problema aqui é que o programa não realiza validações no parâmetro
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
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
- 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.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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.
- 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
[2] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[7] Standards Mapping - FIPS200 SI
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] 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)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - 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
[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.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 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 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[61] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
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
O código no
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
O problema aqui é que o programa não realiza validações no parâmetro
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
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
- 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.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.21
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP 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)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
desc.dataflow.vb.command_injection