界: Input Validation and Representation
输入验证与表示问题是由元字符、交替编码和数字表示引起的。安全问题源于信任输入。这些问题包括：“Buffer Overflows”、“Cross-Site Scripting”攻击、“SQL Injection”等其他问题。
Command Injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据注册表项
例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
这里的问题是：程序没有对读取自用户的
示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据注册表项
APPHOME 来决定其安装目录，然后根据指定目录的相对路径执行初始化脚本。
...
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[].
...
Example 1 中的代码可以使攻击者通过修改注册表项 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从注册表中读取的值，因此如果攻击者能够控制注册表项 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
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.
...
这里的问题是：程序没有对读取自用户的
backuptype参数进行任何验证。通常情况下 SXPG_COMMAND_EXECUTE_LONG 函数模块不会执行多条命令，但在这种情况下，程序会首先运行 cmd.exe shell，从而可以通过调用一次 CALL 'SYSTEM' 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串，那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性，运行该应用程序需要具备与数据库进行交互所需的权限，这就意味着攻击者注入的任何命令都将通过这些权限得以运行。示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
/var/yp 目录中运行 make 命令。
...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
CALL 'SYSTEM' 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量，把它指向名为 make 恶意二进制代码，程序就会在其指定的环境下执行，然后加载该恶意二进制代码，而非原本期望的代码。由于应用程序自身的特性，运行该应用程序需要具备执行系统操作所需的权限，这意味着攻击者会利用这些权限执行自己的 make，从而可能导致攻击者完全控制系统。References
[1] SAP OSS notes 677435, 686765, 866732, 854060, 1336776, 1520462, 1530983 and related notes.
desc.dataflow.abap.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段代码根据配置文件的输入来决定其安装目录，然后根据指定目录的相对路径执行初始化脚本。
例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
这里的问题是：程序没有对读取自用户的
示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段代码根据配置文件的输入来决定其安装目录，然后根据指定目录的相对路径执行初始化脚本。
...
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);
...
Example 1 中的代码可以使攻击者通过修改配置文件 configStream 的内容以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从该文件读取的值，因此如果攻击者可以控制这些值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
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);
...
这里的问题是：程序没有对读取自用户的
backuptype参数进行任何验证。通常情况下 fscommand() 函数不会执行多条命令，但在这种情况下，程序会首先运行 cmd.exe shell，从而可以通过调用一次 fscommnd() 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串，那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性，运行该应用程序需要具备与数据库进行交互所需的权限，这就意味着攻击者注入的任何命令都将通过这些权限得以运行。示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
/var/yp 目录中运行 make 命令。
...
fscommand("exec", "make");
...
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
fscommand() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量，把它指向名为 make 恶意二进制代码，程序就会在其指定的环境下执行，然后加载该恶意二进制代码，而非原本期望的代码。由于应用程序自身的特性，运行该应用程序需要具备执行系统操作所需的权限，这意味着攻击者会利用这些权限执行自己的 make，从而可能导致攻击者完全控制系统。desc.dataflow.actionscript.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
这里的问题是：程序没有对
示例 3：以下代码来自一个 Web 应用程序，该应用程序可以使用户访问一个界面以更新其在系统中的密码。在此网络环境中更新密码时，其中一个步骤就是运行
这里的问题在于，程序没有指定一个绝对的路径，并且在执行
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
APPHOME 来决定其安装目录，然后根据指定目录的相对路径执行一个初始化脚本。
...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
+ btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...
这里的问题是：程序没有对
BackupTypeField进行任何验证。通常情况下 Process.Start() 函数不会执行多条命令，但在这种情况下，程序会首先运行 cmd.exe shell，从而可以通过调用一次 Process.Start() 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串，那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性，运行该应用程序需要具备与数据库进行交互所需的权限，这就意味着攻击者注入的任何命令都将通过这些权限得以运行。示例 3：以下代码来自一个 Web 应用程序，该应用程序可以使用户访问一个界面以更新其在系统中的密码。在此网络环境中更新密码时，其中一个步骤就是运行
update.exe 命令，如下所示：
...
Process.Start("update.exe");
...
这里的问题在于，程序没有指定一个绝对的路径，并且在执行
Process.start() 调用之前未清除其环境变量。如果攻击者能够修改 $PATH 变量，把它指向名为 update.exe 恶意二进制代码，程序就会在其指定的环境下执行，然后加载该恶意二进制代码，而非原本期望的代码。由于应用程序自身的特性，运行该应用程序需要具备执行系统操作所需的权限，这意味着攻击者会利用这些权限执行自己的 update.exe，从而可能导致攻击者完全控制系统。desc.dataflow.dotnet.command_injection
Abstract
执行包含无效用户输入的命令，会导致应用程序以攻击者的名义执行操作。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，既攻击者显式地控制了所执行的命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据是字符串的一部分，应用程序将该字符串作为命令加以执行。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例 1：以下这个简单的程序将文件名作为命令行参数加以接受，并将文件的内容回显给用户。该程序是按照
因为程序是利用
示例 2：以下代码来自于一个特权程序，该程序使用环境变量
如
因为攻击者使用环境变量来控制程序调用的命令，所以在本例中，环境的影响是不言而喻的。现在，我们转移一下注意力，看看如果攻击者能够改变命令的解析方式，会发生什么情况。
示例 3：以下代码来自一个基于 Web 的 CGI 实用程序，用户可以利用此实用程序修改其密码。通过 NIS 执行的密码更新过程包括在
程序会调用
与上一个示例不同，因为本例中的命令采用硬编码形式，所以攻击者不能控制传输到
在 Windows 中，还存在其他风险。
示例 4：直接或通过调用
环境在程序的系统命令执行中扮演了一个十分重要的角色。由于诸如
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，既攻击者显式地控制了所执行的命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据是字符串的一部分，应用程序将该字符串作为命令加以执行。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例 1：以下这个简单的程序将文件名作为命令行参数加以接受，并将文件的内容回显给用户。该程序是按照
setuid root 安装的，因为其最初的用途是一种学习工具，以便让那些仍在正在接受培训的系统管理员查看特权系统文件，而不授予其篡改权限或损坏系统的权力。
int main(char* argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}
因为程序是利用
root 权限运行的，所以也会以 root 权限来调用 system()。如果用户指定了标准的文件名，那么调用就可按照您期望的方式进行。然而，如果攻击者传递了一个 ";rm -rf /" 形式的字符串，由于缺少参数，对 system() 的调用无法成功地执行 cat，然后程序会逐层删除根分区中的内容。示例 2：以下代码来自于一个特权程序，该程序使用环境变量
$APPHOME 来确定应用程序的安装目录，然后在该目录中执行一个初始化脚本。
...
char* home=getenv("APPHOME");
char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
if (cmd) {
strcpy(cmd,home);
strcat(cmd,INITCMD);
execl(cmd, NULL);
}
...
如
Example 1 中所示，该示例中的代码允许攻击者使用更高的应用程序权限来执行任意命令。在此示例中，攻击者可以篡改环境变量 $APPHOME 以指定包含恶意版本 INITCMD 的其他路径。由于程序不会验证从环境中读取的值，因此攻击者可通过控制该环境变量来诱骗应用程序去运行恶意代码。因为攻击者使用环境变量来控制程序调用的命令，所以在本例中，环境的影响是不言而喻的。现在，我们转移一下注意力，看看如果攻击者能够改变命令的解析方式，会发生什么情况。
示例 3：以下代码来自一个基于 Web 的 CGI 实用程序，用户可以利用此实用程序修改其密码。通过 NIS 执行的密码更新过程包括在
/var/yp 目录中运行 make。请注意，由于程序更新了密码记录，因此它已按照 setuid root 安装。程序会调用
make，如下所示：
system("cd /var/yp && make &> /dev/null");
与上一个示例不同，因为本例中的命令采用硬编码形式，所以攻击者不能控制传输到
system() 的参数。但是，因为程序没有指定 make 的绝对路径，而且没有在调用命令之前清除任何环境变量，所以攻击者就能够篡改它们的 $PATH 变量，以便指向一个名为 make 的恶意二进制代码，并在 shell 提示符中执行 CGI 脚本。而且，因为程序已按照 setuid root 安装，所以攻击者的 make 目前会在 root 的权限下执行。在 Windows 中，还存在其他风险。
示例 4：直接或通过调用
_spawn() 家族中的某项函数调用 CreateProcess() 时，如果可执行文件或路径中存在空格，必须谨慎操作。
...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...
CreateProcess() 解析空格时，操作系统尝试执行的第一个可执行文件将是 Program.exe，而不是 MyApplication.exe。因此，如果攻击者能够在系统上安装名称为 Program.exe 的恶意应用程序，任何使用 Program Files 目录错误调用 CreateProcess() 的程序将运行此恶意应用程序，而非原本期望的应用程序。环境在程序的系统命令执行中扮演了一个十分重要的角色。由于诸如
system()、exec() 和 CreateProcess() 之类的函数利用调用这些函数的程序的环境，因此攻击者有可能影响这些调用行为。desc.dataflow.cpp.command_injection
Abstract
在不指定绝对路径的情况下执行命令，使攻击者能够通过更改
$PATH 或程序执行环境的其他方面使用该程序执行恶意二进制代码。Explanation
Command Injection 漏洞主要表现为以下两种形式：
- 攻击者能够篡改程序执行的命令：攻击者直接控制命令。
- 攻击者能够控制程序的参数。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第二种情形，即攻击者能够通过篡改一个环境变量或预先在搜索路径中输入可执行的恶意内容，进而更改命令所代表的原始含义。这种形式的 Command Injection 漏洞在以下情况下发生：
1.攻击者修改应用程序的环境。
2.应用程序在不指定绝对路径或验证正在执行二进制代码的情况下执行命令。
3.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例 1：此示例演示了攻击者更改命令解释方式时将会发生什么。以下代码来自一个基于 Web 的 CGI 实用程序，用户可以利用此实用程序更改其密码。通过 NIS 执行的密码更新过程包括在
程序会调用
此示例中的命令采用硬编码，因此攻击者无法控制传递到
示例 2：以下代码使用环境变量确定包含要通过
与之前的示例类似，该命令采用硬编码。然而由于程序无法指定
- 攻击者能够篡改程序执行的命令：攻击者直接控制命令。
- 攻击者能够控制程序的参数。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第二种情形，即攻击者能够通过篡改一个环境变量或预先在搜索路径中输入可执行的恶意内容，进而更改命令所代表的原始含义。这种形式的 Command Injection 漏洞在以下情况下发生：
1.攻击者修改应用程序的环境。
2.应用程序在不指定绝对路径或验证正在执行二进制代码的情况下执行命令。
3.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例 1：此示例演示了攻击者更改命令解释方式时将会发生什么。以下代码来自一个基于 Web 的 CGI 实用程序，用户可以利用此实用程序更改其密码。通过 NIS 执行的密码更新过程包括在
/var/yp 目录中运行 make。请注意，由于程序更新了密码记录，因此它已按照 setuid root 安装。程序会调用
make，如下所示：
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
此示例中的命令采用硬编码，因此攻击者无法控制传递到
CBL_EXEC_RUN_UNIT 的参数。然而，由于程序无法指定 make 的绝对路径，并且无法在调用命令之前擦除其环境变量，攻击者能够修改其 $PATH 变量以指向名为 make 的恶意二进制代码并通过 Shell 提示符执行 CGI 脚本。此外，由于程序已安装 setuid root，因此攻击者版本的 make 现在以 root 权限运行。示例 2：以下代码使用环境变量确定包含要通过
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
与之前的示例类似，该命令采用硬编码。然而由于程序无法指定
pdfprint 的绝对路径，因此攻击者能够修改其指向恶意二进制代码的 $PATH 变量。此外，尽管 DELIMITED SPACE 短语能够阻止 ws-temp-dir 和 ws-pdf-filename 中的嵌入空间，仍然可能有 Shell 元字符（例如 &&）嵌入在这两者之一。desc.semantic.cobol.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：攻击者可以利用下列代码通过
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：攻击者可以利用下列代码通过
cmd 请求参数指定任意指令。
...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
arguments = "/c #var#"
timeout = "1"
variable="mycmd">
</cfexecute>
...
desc.dataflow.cfml.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
- 攻击者能够篡改程序执行的命令：攻击者直接控制命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者控制所执行命令的可能性。这种形式的 Command Injection 漏洞在以下情况下发生：
1.数据从不可信赖的数据源进入应用程序。
2.数据作为代表应用程序所执行命令的一个字符串或部分字符串使用。
3.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例 1：系统实用程序中的以下代码使用系统属性
- 攻击者能够篡改程序执行的命令：攻击者直接控制命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者控制所执行命令的可能性。这种形式的 Command Injection 漏洞在以下情况下发生：
1.数据从不可信赖的数据源进入应用程序。
2.数据作为代表应用程序所执行命令的一个字符串或部分字符串使用。
3.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例 1：系统实用程序中的以下代码使用系统属性
APPHOME 来确定其安装目录，然后根据指定目录的相对路径执行初始化脚本。
...
final cmd = String.fromEnvironment('APPHOME');
await Process.run(cmd);
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。desc.dataflow.dart.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
- 攻击者能够篡改程序执行的命令：攻击者直接控制命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者控制命令的可能性。这种形式的 Command Injection 漏洞在以下情况下发生：
1.数据从不可信赖的数据源进入应用程序。
2.数据作为代表应用程序所执行命令的一个字符串或部分字符串使用。
3.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例：以下代码会运行用户控制的命令。
- 攻击者能够篡改程序执行的命令：攻击者直接控制命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者控制命令的可能性。这种形式的 Command Injection 漏洞在以下情况下发生：
1.数据从不可信赖的数据源进入应用程序。
2.数据作为代表应用程序所执行命令的一个字符串或部分字符串使用。
3.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例：以下代码会运行用户控制的命令。
cmdName := request.FormValue("Command")
c := exec.Command(cmdName)
c.Run()
desc.dataflow.golang.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
这里的问题是：程序没有对读取自用户的
示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
有些人认为在移动世界中，典型的漏洞（如 Command Injection）是无意义的 -- 为什么用户要攻击自己？但是，谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高，它们会强制扩展移动应用程序的攻击面（包括跨进程通信）。
例 4：以下代码可从 Android Intent 中读取要执行的命令。
在经过 root 的设备上，恶意应用程序会强迫受攻击应用程序使用超级用户权限执行任意命令。
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
APPHOME 来决定其安装目录，然后根据指定目录的相对路径执行一个初始化脚本。
...
String home = System.getProperty("APPHOME");
String cmd = home + INITCMD;
java.lang.Runtime.getRuntime().exec(cmd);
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
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);
...
这里的问题是：程序没有对读取自用户的
backuptype参数进行任何验证。通常情况下 Runtime.exec() 函数不会执行多条命令，但在这种情况下，程序会首先运行 cmd.exe shell，从而可以通过调用一次 Runtime.exec() 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串，那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性，运行该应用程序需要具备与数据库进行交互所需的权限，这就意味着攻击者注入的任何命令都将通过这些权限得以运行。示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
/var/yp 目录中运行 make 命令。
...
System.Runtime.getRuntime().exec("make");
...
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
Runtime.exec() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量，把它指向名为 make 恶意二进制代码，程序就会在其指定的环境下执行，然后加载该恶意二进制代码，而非原本期望的代码。由于应用程序自身的特性，运行该应用程序需要具备执行系统操作所需的权限，这意味着攻击者会利用这些权限执行自己的 make，从而可能导致攻击者完全控制系统。有些人认为在移动世界中，典型的漏洞（如 Command Injection）是无意义的 -- 为什么用户要攻击自己？但是，谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高，它们会强制扩展移动应用程序的攻击面（包括跨进程通信）。
例 4：以下代码可从 Android Intent 中读取要执行的命令。
...
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();
...
在经过 root 的设备上，恶意应用程序会强迫受攻击应用程序使用超级用户权限执行任意命令。
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.java.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例 1：以下来自系统实用程序的代码根据环境变量
示例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
这里的问题是：程序除了验证读取自用户的
示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
这里的问题在于，程序没有指定
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例 1：以下来自系统实用程序的代码根据环境变量
APPHOME 来决定其安装目录，然后根据指定目录的相对路径来执行初始化脚本。
var cp = require('child_process');
...
var home = process.env('APPHOME');
var cmd = home + INITCMD;
child = cp.exec(cmd, function(error, stdout, stderr){
...
});
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。示例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
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);
这里的问题是：程序除了验证读取自用户的
backuptype参数是否存在之外，没有对其进行任何验证。在调用该 shell 之后，就可能允许执行多个命令，并且由于该应用程序的特性，该应用程序将会使用与数据库进行交互的必要权限来运行，这就意味着攻击者注入的任何命令都会通过这些权限来运行。示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
/var/yp 目录中运行 make 命令。
...
require('child_process').exec("make", function(error, stdout, stderr){
...
});
...
这里的问题在于，程序没有指定
make 的绝对路径，因此没能在执行 child_process.exec() 调用前清理其环境。如果攻击者能够修改 $PATH 变量，把它指向名为 make 恶意二进制代码，程序就会在其指定的环境下执行，然后加载该恶意二进制代码，而非原本期望的代码。由于应用程序自身的特性，运行该应用程序需要具备执行系统操作所需的权限，这意味着攻击者会利用这些权限执行自己的 make，从而可能导致攻击者完全控制系统。desc.dataflow.javascript.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
这里的问题是：程序没有对读取自用户的
示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
APPHOME 来决定其安装目录，然后根据指定目录的相对路径执行一个初始化脚本。
...
$home = $_ENV['APPHOME'];
$cmd = $home . $INITCMD;
system(cmd);
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...
这里的问题是：程序没有对读取自用户的
backuptype参数进行任何验证。通常情况下 Runtime.exec() 函数不会执行多条命令，但在这种情况下，程序会首先运行 cmd.exe shell，从而可以通过调用一次 Runtime.exec() 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串，那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性，运行该应用程序需要具备与数据库进行交互所需的权限，这就意味着攻击者注入的任何命令都将通过这些权限得以运行。示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
/var/yp 目录中运行 make 命令。
...
$result = shell_exec("make");
...
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
Runtime.exec() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量，把它指向名为 make 恶意二进制代码，程序就会在其指定的环境下执行，然后加载该恶意二进制代码，而非原本期望的代码。由于应用程序自身的特性，运行该应用程序需要具备执行系统操作所需的权限，这意味着攻击者会利用这些权限执行自己的 make，从而可能导致攻击者完全控制系统。desc.dataflow.php.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例：以下代码定义了一个 T-SQL 存储过程，当使用不可信的数据调用该过程时，将执行攻击者控制的系统命令。
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例：以下代码定义了一个 T-SQL 存储过程，当使用不可信的数据调用该过程时，将执行攻击者控制的系统命令。
...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS
DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path
exec xp_cmdshell @cmd
GO
...
References
[1] xp_cmdshell
desc.dataflow.sql.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
这里的问题是：程序没有对读取自用户的
示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
APPHOME 来决定其安装目录，然后根据指定目录的相对路径执行一个初始化脚本。
...
home = os.getenv('APPHOME')
cmd = home.join(INITCMD)
os.system(cmd);
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
btype = req.field('backuptype')
cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
os.system(cmd);
...
这里的问题是：程序没有对读取自用户的
backuptype参数进行任何验证。通常情况下 Runtime.exec() 函数不会执行多条命令，但在这种情况下，程序会首先运行 cmd.exe shell，从而可以通过调用一次 Runtime.exec() 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串，那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性，运行该应用程序需要具备与数据库进行交互所需的权限，这就意味着攻击者注入的任何命令都将通过这些权限得以运行。示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
/var/yp 目录中运行 make 命令。
...
result = os.system("make");
...
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
os.system() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量，把它指向名为 make 恶意二进制代码，程序就会在其指定的环境下执行，然后加载该恶意二进制代码，而非原本期望的代码。由于应用程序自身的特性，运行该应用程序需要具备执行系统操作所需的权限，这意味着攻击者会利用这些权限执行自己的 make，从而可能导致攻击者完全控制系统。desc.dataflow.python.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
这里的问题是：程序没有对读取自用户的
示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
APPHOME 来决定其安装目录，然后根据指定目录的相对路径执行一个初始化脚本。
...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...
这里的问题是：程序没有对读取自用户的
backuptype参数进行任何验证。在通过 Kernel.spawn 调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串，那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性，运行该应用程序需要具备与数据库进行交互所需的权限，这就意味着攻击者注入的任何命令都将通过这些权限得以运行。示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
/var/yp 目录中运行 make 命令。
...
system("make")
...
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
Kernel.system() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量，把它指向名为 make 恶意二进制代码，程序就会在其指定的环境下执行，然后加载该恶意二进制代码，而非原本期望的代码。由于应用程序自身的特性，运行该应用程序需要具备执行系统操作所需的权限，这意味着攻击者会利用这些权限执行自己的 make，从而可能导致攻击者完全控制系统。desc.dataflow.ruby.command_injection
Abstract
执行包含无效用户输入的命令，会导致应用程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第二种情况，即攻击者有可能通过篡改一个环境变量或预先在搜索路径中输入可执行的恶意内容，进而更改命令所代表的原始含义。这种类型的 Command Injection 漏洞会在以下情况下出现：
1.攻击者篡改某一应用程序的环境。
2.应用程序在没有指明绝对路径，或者没有检验所执行的二进制代码的情况下就执行命令。
3.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第二种情况，即攻击者有可能通过篡改一个环境变量或预先在搜索路径中输入可执行的恶意内容，进而更改命令所代表的原始含义。这种类型的 Command Injection 漏洞会在以下情况下出现：
1.攻击者篡改某一应用程序的环境。
2.应用程序在没有指明绝对路径，或者没有检验所执行的二进制代码的情况下就执行命令。
3.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
示例：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。
def changePassword(username: String, password: String) = Action { request =>
...
s'echo "${password}" | passwd ${username} --stdin'.!
...
}
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.scala.command_injection
Abstract
执行不可信赖资源中的命令，或在不可信赖的环境中执行命令，都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式：
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
这里的问题是：程序没有对读取自用户的
示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。
－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。
在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现：
1. 数据从不可信赖的数据源进入应用程序。
2. 数据被用作代表应用程序所执行命令的字符串，或字符串的一部分。
3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。
例 1：下面这段来自系统实用程序的代码根据系统属性
APPHOME 来决定其安装目录，然后根据指定目录的相对路径执行一个初始化脚本。
...
Dim cmd
Dim home
home = Environ$("AppHome")
cmd = home & initCmd
Shell cmd, vbNormalFocus
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。例 2：下面的代码来自一个管理 Web 应用程序，旨在使用户能够使用一个围绕
rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...
这里的问题是：程序没有对读取自用户的
backuptype参数进行任何验证。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串，那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性，运行该应用程序需要具备与数据库进行交互所需的权限，这就意味着攻击者注入的任何命令都将通过这些权限得以运行。示例 3：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时，其中的一个步骤就是在
/var/yp 目录中运行 make 命令。
...
$result = shell_exec("make");
...
这里的问题在于程序没有在它的构造中指定一个绝对路径，并且没能在执行
Runtime.exec() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量，把它指向名为 make 恶意二进制代码，程序就会在其指定的环境下执行，然后加载该恶意二进制代码，而非原本期望的代码。由于应用程序自身的特性，运行该应用程序需要具备执行系统操作所需的权限，这意味着攻击者会利用这些权限执行自己的 make，从而可能导致攻击者完全控制系统。desc.dataflow.vb.command_injection