Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用依赖于整数的语句构建和执行 SQL 查询，因此不易受到 SQL injection 漏洞攻击。该 SQL 查询指令可以搜索与指定标识符 [1] 相匹配的清单。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

DATA: id TYPE i.
...
id = request->get_form_field( 'invoiceID' ).

CONCATENATE `INVOICEID = '` id `'` INTO cl_where.
SELECT *
    FROM invoices
    INTO CORRESPONDING FIELDS OF TABLE itab_invoices
    WHERE (cl_where).
ENDSELECT.
...

问题在于开发者没有考虑到所有可能出现的 ID 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var id:int = int(Number(params["invoiceID"]));
        var query:String = "SELECT * FROM invoices WHERE id = :id";

        stmt.sqlConnection = conn;
        stmt.text = query;
        stmt.parameters[":id"] = id;
        stmt.execute();
        ...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SOQL/SOSL 查询中主键的值。
示例 1：在以下代码示例中，inputID 值来源于预定义列表，绑定变量有助于避免 SOQL/SOSL injection。

...
result = [SELECT Name, Phone FROM Contact WHERE (IsDeleted = false AND Id=:inputID)];
...

前一示例的问题是，使用预定义的 ID 列表不足以阻止用户修改 inputID 的值。如果攻击者能够绕过该接口并使用不同值发送请求，他将可以访问其他联系人信息。由于此例中的代码没有执行检查以确保用户有权访问请求的联系人，所以代码会显示所有联系人，即使该用户无权查看。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。

2. 这个数据用来指定 LINQ 查询中主键的值。
示例 1：以下代码执行 LINQ 查询，该查询可以搜索与指定标识符 [1] 相匹配的清单。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

...

int16 id = System.Convert.ToInt16(invoiceID.Text);
var invoice = OrderSystem.getInvoices()
	.Where(new Invoice { invoiceID = id });
...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

...
CMyRecordset rs(&dbms);
rs.PrepareSQL("SELECT * FROM invoices WHERE id = ?");
rs.SetParam_int(0,atoi(r.Lookup("invoiceID").c_str()));
rs.SafeExecuteSQL();
...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
例 1：以下代码用到一个参数化指令，这个指令转义了元字符，以防止 SQL injection 漏洞，并构建和执行一个 SQL 查询。该 SQL 查询指令可以搜索与指定标识符 [1] 相匹配的清单。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

...
ACCEPT ID.
EXEC SQL
    DECLARE C1 CURSOR FOR
    SELECT INVNO, INVDATE, INVTOTAL
    FROM INVOICES
    WHERE INVOICEID = :ID
END-EXEC.
...

问题在于开发者没有考虑到所有可能出现的 ID 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

数据库 Access Control 错误在以下情况下发生：

1. 数据从一个不可信数据源进入程序。


2. 数据用来指定数据库名称的值。

数据库 Access Control 错误在以下情况下发生：

1.数据从一个不可信数据源进入程序。


2.数据用来指定 SQL 查询中主键的值。
示例 1：以下代码将使用参数化语句，该语句会转义元字符，以防止 SQL Injection 漏洞，并构建和执行一个 SQL 查询。该 SQL 查询可以搜索与指定标识符 [1] 相匹配的清单。您可以从与当前授权用户关联的所有清单中选择该标识符。

...
id := request.FormValue("invoiceID")
query := "SELECT * FROM invoices WHERE id = ?";
rows, err := db.Query(query, id)
...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

...
id = Integer.decode(request.getParameter("invoiceID"));
String query = "SELECT * FROM invoices WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
ResultSet results = stmt.execute();
...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

有些人认为在移动世界中，典型的 Web 应用程序漏洞（如 Database access control 错误）是无意义的 -- 为什么用户要攻击自己？但是，谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高，它们会强制扩展移动应用程序的攻击面（包括跨进程通信）。

示例 2：以下代码会调整Example 1 以适应 Android 平台。

...
        String id = this.getIntent().getExtras().getString("invoiceID");
        String query = "SELECT * FROM invoices WHERE id = ?";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, new Object[]{id});
...

许多现代 Web 框架都会提供对用户输入执行验证的机制（包括 Struts 和 Struts 2）。为了突出显示未经验证的输入源，Fortify 安全编码规则包会对 Fortify Static Code Analyzer（Fortify 静态代码分析器）报告的问题动态重新调整优先级，即在采用框架验证机制时降低这些问题被利用的几率并提供指向相应证据的指针。我们将这种功能称之为上下文敏感排序。为了进一步帮助 Fortify 用户执行审计过程，Fortify 软件安全研究团队开发了 Data Validation（数据验证）项目模板，该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

	...
	var id = document.form.invoiceID.value;
	var query = "SELECT * FROM invoices WHERE id = ?";
	db.transaction(function (tx) {
		tx.executeSql(query,[id]);
		}
	)
	...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不受信任的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL injection 漏洞的参数化语句，以构建和执行用于搜索与指定标识符相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

...

        NSManagedObjectContext *context = [appDelegate managedObjectContext];
        NSEntityDescription *entityDesc = [NSEntityDescription entityForName:@"Invoices" inManagedObjectContext:context];
        NSFetchRequest *request = [[NSFetchRequest alloc] init];
        [request setEntity:entityDesc];
        NSPredicate *pred = [NSPredicate predicateWithFormat:@"(id = %@)", invoiceId.text];
        [request setPredicate:pred];

        NSManagedObject *matches = nil;
        NSError *error;
        NSArray *objects = [context executeFetchRequest:request error:&error];

        if ([objects count] == 0) {
                 status.text = @"No records found.";
        } else {
                matches = [objects objectAtIndex:0];
                invoiceReferenceNumber.text = [matches valueForKey:@"invRefNum"];
                orderNumber.text = [matches valueForKey:@"orderNumber"];
                status.text = [NSString stringWithFormat:@"%d records found", [objects count]];
        }
        [request release];
...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
例 1：以下代码用到一个参数化指令，这个指令转义了元字符，以防止 SQL injection 漏洞，并构建和执行一个 SQL 查询。该 SQL 查询指令可以搜索与指定标识符 [1] 相匹配的清单。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

        ...
	$id = $_POST['id'];
	$query = "SELECT * FROM invoices WHERE id = ?";
	$stmt = $mysqli->prepare($query);
	$stmt->bind_param('ss',$id);
	$stmt->execute();
        ...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

许多现代 Web 框架都会提供对用户输入执行验证的机制（包括 Struts 和 Struts 2）。为了突出显示未经验证的输入源，Fortify 安全编码规则包会对 Fortify Static Code Analyzer（Fortify 静态代码分析器）报告的问题动态重新调整优先级，即在采用框架验证机制时降低这些问题被利用的几率并提供指向相应证据的指针。我们将这种功能称之为上下文敏感排序。为了进一步帮助 Fortify 用户执行审计过程，Fortify 软件安全研究团队开发了 Data Validation（数据验证）项目模板，该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。

2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

procedure get_item (
itm_cv IN OUT ItmCurTyp,
id in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'invoiceID = :invid' ||
     	using id;
end get_item;

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

...
id = request.POST['id']
c = db.cursor()
stmt = c.execute("SELECT * FROM invoices WHERE id = %s", (id,))
...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

...
id = req['invoiceID'].respond_to(:to_int)
query = "SELECT * FROM invoices WHERE id=?"
stmt = conn.prepare(query)
stmt.execute(id)
...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不受信任的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL injection 漏洞的参数化语句，以构建和执行用于搜索与指定标识符相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

...
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Invoices", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
let pred : NSPredicate = NSPredicate(format:"(id = %@)", invoiceId.text)
fetchRequest.setPredicate = pred
do {
    let results = try managedContext.executeFetchRequest(fetchRequest)
    let result : NSManagedObject = results.first!
    invoiceReferenceNumber.text = result.valueForKey("invRefNum")
    orderNumber.text = result.valueForKey("orderNumber")
    status.text = "\(results.count) records found"
} catch let error as NSError {
    print("Error \(error)")
}
...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

	...
	id = Request.Form("invoiceID")
	strSQL = "SELECT * FROM invoices WHERE id = ?"
	objADOCommand.CommandText = strSQL
	objADOCommand.CommandType = adCmdText
	set objADOParameter = objADOCommand.CreateParameter("id" , adString, adParamInput, 0, 0)
	objADOCommand.Parameters("id") = id
	...

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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，从而可能导致攻击者完全控制系统。

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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，从而可能导致攻击者完全控制系统。

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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，从而可能导致攻击者完全控制系统。

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，既攻击者显式地控制了所执行的命令。这种类型的 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() 之类的函数利用调用这些函数的程序的环境，因此攻击者有可能影响这些调用行为。

Command Injection 漏洞主要表现为以下两种形式：

- 攻击者能够篡改程序执行的命令：攻击者直接控制命令。

- 攻击者能够控制程序的参数。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第二种情形，即攻击者能够通过篡改一个环境变量或预先在搜索路径中输入可执行的恶意内容，进而更改命令所代表的原始含义。这种形式的 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 元字符（例如 &&）嵌入在这两者之一。

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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>
    ...

Command Injection 漏洞主要表现为以下两种形式：

- 攻击者能够篡改程序执行的命令：攻击者直接控制命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者控制所执行命令的可能性。这种形式的 Command Injection 漏洞在以下情况下发生：

1.数据从不可信赖的数据源进入应用程序。

2.数据作为代表应用程序所执行命令的一个字符串或部分字符串使用。

3.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例 1：系统实用程序中的以下代码使用系统属性 APPHOME 来确定其安装目录，然后根据指定目录的相对路径执行初始化脚本。

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

Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。

Command Injection 漏洞主要表现为以下两种形式：

- 攻击者能够篡改程序执行的命令：攻击者直接控制命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者控制命令的可能性。这种形式的 Command Injection 漏洞在以下情况下发生：

1.数据从不可信赖的数据源进入应用程序。


2.数据作为代表应用程序所执行命令的一个字符串或部分字符串使用。

3.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例：以下代码会运行用户控制的命令。

  cmdName := request.FormValue("Command")
  c := exec.Command(cmdName)
  c.Run()

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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 的设备上，恶意应用程序会强迫受攻击应用程序使用超级用户权限执行任意命令。

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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，从而可能导致攻击者完全控制系统。

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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，从而可能导致攻击者完全控制系统。

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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
...

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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，从而可能导致攻击者完全控制系统。

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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，从而可能导致攻击者完全控制系统。

Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制所执行命令。这种类型的 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，从而可能导致攻击者完全控制系统。

现今的 Web 浏览器支持每个 Cookie 都具有 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该安全标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。

示例 1：在以下示例中，创建了 Cookie，但未将 isSecure 参数设置为 true。

...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 isSecure 参数，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接探查网络流量对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。

现今的 Web 浏览器支持每个 cookie 的 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。

示例：在下面的示例中，在未设置 Secure 属性的情况下，为响应添加了一个 Cookie。

...
 HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);
...

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接截取网络信息流对攻击者而言十分简单，因此通过 HTTP 发送 cookie（特别是具有会话 ID 的 cookie）可能会危及应用程序安全。

现今的 Web 浏览器支持每个 Cookie 都具有 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或会话标识符，或带有 CSRF 标记，那么该标记尤其重要。
示例 1：以下代码会在未设置 Secure 标记的情况下将 cookie 添加到响应中。

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
http.SetCookie(response, &cookie)
...

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。

现今的 Web 浏览器支持每个 Cookie 都具有 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。

示例 1：在下列示例中，use-secure-cookie 属性允许 remember-me Cookie 通过未加密的传输发送出去。

	<http auto-config="true">
        ...
        <remember-me use-secure-cookie="false"/>
	</http>

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接监听网络通信对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。

现今的 Web 浏览器支持每个 cookie 的 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。
示例 1：在下面的示例中，在未将 Secure 属性设置为 true 的情况下，为响应添加了一个 Cookie。

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接截取网络信息流对攻击者而言十分简单，因此通过 HTTP 发送 cookie（特别是具有会话 ID 的 cookie）可能会危及应用程序安全。

现今的 Web 浏览器支持每个 cookie 的 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。
示例 1：在下面的示例中，在未设置 Secure 标记的情况下，为响应添加了一个 Cookie。

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接截取网络信息流对攻击者而言十分简单，因此通过 HTTP 发送 cookie（特别是具有会话 ID 的 cookie）可能会危及应用程序安全。

现今的 Web 浏览器支持每个 cookie 的 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。
示例 1：以下代码会在未设置 Secure 标记的情况下将 cookie 添加到响应中。

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。

现今的 Web 浏览器支持每个 cookie 的 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或会话标识符，或带有 CSRF 标记，那么该标记尤其重要。
示例 1：以下代码会在未设置 Secure 标记的情况下将 cookie 添加到响应中。

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。

现今的 Web 浏览器支持每个 Cookie 都具有 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。
示例 1：在下面的示例中，在未设置 Secure 标记的情况下，为响应添加了一个 Cookie。

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接监听网络通信对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。

所有主要浏览器均支持 HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证令牌。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。
示例 1：以下代码会在未设置 HttpOnly 属性的情况下创建一个 Cookie。

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);

浏览器支持 HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证标记。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。
示例 1：以下代码会在未设置 HttpOnly 属性的情况下创建一个 Cookie。

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
...

所有主要浏览器均支持 HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证令牌。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。
示例 1：以下代码会在未设置 HttpOnly 属性的情况下创建一个 Cookie。

javax.servlet.http.Cookie cookie = new javax.servlet.http.Cookie("emailCookie", email);
// Missing a call to: cookie.setHttpOnly(true);

所有主要浏览器均支持 HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证令牌。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。
示例 1：以下代码会在未设置 httpOnly 属性的情况下创建一个 Cookie。

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});

所有主要浏览器均支持 HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证令牌。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。
示例 1：以下代码会在未设置 HttpOnly 属性的情况下创建一个 Cookie。

setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE);  //Missing 7th parameter to set HttpOnly

浏览器支持 HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证令牌。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。
示例 1：以下代码会在未设置 HttpOnly 属性的情况下创建一个 Cookie。

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

开发人员通常将 Cookie 设置为在类似“.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

示例：
假设您在 http://secure.example.com/ 上部署了一个安全应用程序，当用户登录时，该应用程序将使用域“.example.com”设置会话 ID Cookie。

例如：

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Domain = ".example.com";

假设您在 http://insecure.example.com/ 上部署了另一个不太安全的应用程序，并且它存在 Cross-Site Scripting 漏洞。 任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户都面临着暴露来自 http://secure.example.com 的会话 Cookie 的风险。

除了读取 Cookie 之外，攻击者还可能使用 insecure.example.com 来创建自己范围过大的 Cookie，以覆盖来自 secure.example.com 的 Cookie，从而执行 Cookie Poisoning 攻击。

开发人员通常将 Cookie 设置为在类似“.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

示例 1：假设您的一个安全应用程序部署在 http://secure.example.com/ 上，当用户登录时，该应用程序将使用域“.example.com”设置会话 ID Cookie。

例如：

cookie := http.Cookie{
  Name:       "sessionID",
  Value:      getSessionID(),
  Domain:     ".example.com",
}
...

假设您在 http://insecure.example.com/ 上部署了另一个不太安全的应用程序，并且它存在 Cross-Site Scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户都面临着暴露来自 http://secure.example.com 的会话 Cookie 的风险。

除了读取 Cookie 外，攻击者还可能使用 insecure.example.com 进行“Cookie Poisoning 攻击”，创建自己范围过大的 Cookie，并覆盖 Secure.example.com 中的 Cookie。

开发人员通常将 Cookie 设置为在类似“.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

例 1：
假设您有一个安全应用程序并将其部署在 http://secure.example.com/ 上，当用户登录时，该应用程序将使用域“.example.com”设置会话 ID cookie。

例如：

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setDomain(".example.com");

假设您在 http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。

除了读取 cookie 外，攻击者还可能使用 insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。

开发人员通常将 Cookie 设置为在类似“.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

示例 1：
假设您有一个安全应用程序并将其部署在 http://secure.example.com/ 上，当用户登录时，该应用程序将使用域“.example.com”设置会话 ID cookie。

例如：

  cookie_options = {};
  cookie_options.domain = '.example.com';
  ...
  res.cookie('important_cookie', info, cookie_options);

假设您在 http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。

除了读取 cookie 外，攻击者还可能使用 insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。

开发人员通常将 Cookie 设置为在类似“.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

例 1：
假设您有一个安全应用程序并将其部署在 http://secure.example.com/ 上，当用户登录时，该应用程序将使用域“.example.com”设置会话 ID cookie。

例如：

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

假设您在 http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。

除了读取 cookie 外，攻击者还可能使用 insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。

开发人员通常将 Cookie 设置为在类似“.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

例 1：
假设您有一个安全应用程序并将其部署在 http://secure.example.com/ 上，当用户登录时，该应用程序将使用域“.example.com”设置会话 cookie。

例如：

setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);

假设您在 http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。

除了读取 cookie 外，攻击者还可能使用 insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。

开发人员通常将 Cookie 设置为在类似“.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

例 1：假设您有一个安全应用程序并将其部署在 http://secure.example.com/ 上，当用户登录时，该应用程序将使用域“.example.com”设置会话 ID cookie。

例如：

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
  return res
...

假设您在 http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。

除了读取 cookie 外，攻击者还可能使用 insecure.example.com 进行“Cookie 篡改攻击”，创建自己范围过大的 cookie，并覆盖 secure.example.com 中的 cookie。

开发人员通常将 Cookie 设置为在类似“.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

例 1：
假设您有一个安全应用程序并将其部署在 http://secure.example.com/ 上，当用户登录时，该应用程序将使用域“.example.com”设置会话 ID cookie。

例如：

...
let properties = [
    NSHTTPCookieDomain: ".example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

假设您在 http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。

除了读取 cookie 外，攻击者还可能使用 insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。

开发人员通常将 Cookie 设置为可从根上下文路径（“/”）进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

示例 1：
假设您在 http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID Cookie。例如：

...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...

假设攻击者在 http://communitypages.example.com/EvilSite 上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。

除了读取 Cookie 之外，攻击者还可能使用 /EvilSite 来创建自己范围过大的 Cookie，以覆盖来自 /MyForum 的 Cookie，从而执行 Cookie Poisoning 攻击。

开发人员通常将 Cookie 设置为根上下文路径“/”，然而，这样做会使 Cookie 暴露在域名相同的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

示例：
假设您有一个论坛应用程序并将其部署在 http://communitypages.example.com/MyForum 上，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID cookie。

例如：

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Path = "/";

假设攻击者在 http://communitypages.example.com/EvilSite上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。

除了读取 cookie 外，攻击者还可能使用 /EvilSite 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。

开发人员通常将 Cookie 设置为可从根上下文路径“/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

示例 1：
假设您在 http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径 "/" 设置会话 ID Cookie。

例如：

cookie := http.Cookie{
  Name:    "sessionID",
  Value:   sID,
  Expires: time.Now().AddDate(0, 0, 1),
  Path:    "/",
}
...

假设攻击者在 http://communitypages.example.com/EvilSite 上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。

除了读取 Cookie 外，攻击者还可能使用 /EvilSite 进行“Cookie Poisoning 攻击”，创建自己范围过大的 Cookie，并覆盖 /MyForum 中的 Cookie。

开发人员通常将 Cookie 设置为可从根上下文路径“/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。

例 1：
假设您有一个论坛应用程序并将其部署在 http://communitypages.example.com/MyForum 上，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID cookie。

例如：

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setPath("/");

假设攻击者在 http://communitypages.example.com/EvilSite上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。

除了读取 cookie 外，攻击者还可能使用 /EvilSite 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。