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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

数据库 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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

数据库访问控制错误在以下情况下发生：

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


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

  def searchInvoice(value:String) = Action.async { implicit request =>
    val result: Future[Seq[Invoice]] = db.run {
      sql"select * from invoices where id=$value".as[Invoice]
    }
    ...
  }

问题在于开发者没有考虑到所有可能出现的 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：攻击者可以利用下列代码通过 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.通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。

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

  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. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例 1：以下代码定义了一个 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：下面的代码来自一个 Web 应用程序，用户可通过该应用程序提供的界面在系统上更新他们的密码。

def changePassword(username: String, password: String) = Action { request =>
    ...
    s'echo "${password}" | passwd ${username} --stdin'.!
    ...
}

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，从而可能导致攻击者完全控制系统。

Cross-Site Scripting (XSS) 漏洞在以下情况下发生：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Persistent（也称为 Stored）XSS，不可信赖的数据源通常为数据库或其他后端数据存储，而对于 Reflected XSS，该数据源通常为 Web 请求。


2.未经验证但包含在动态内容中的数据将传送给 Web 用户。

传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式，但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。

例 1：下面的 ABAP 代码片段会根据一个特定的雇员 ID 来查询数据库，并显示出相应的雇员姓名。

...
DATA: BEGIN OF itab_employees,
        eid   TYPE employees-itm,
        name  TYPE employees-name,
      END OF itab_employees,
      itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.

SELECT *
  FROM employees
  INTO CORRESPONDING FIELDS OF TABLE itab_employees
  FOR ALL ENTRIES IN itab
  WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...

如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。

例 2：下面的 ABAP 代码片段可从 HTTP 请求中读取雇员 ID eid，并将其显示给用户。

...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...

如Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。

起初，这个例子似乎是不会轻易遭受攻击的。毕竟，有谁会输入导致恶意代码在自己电脑上运行的 URL 呢？真正的危险在于攻击者会创建恶意的 URL，然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时，他们不知不觉地通过易受攻击的网络应用程序，将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。

正如例子中所显示的，XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种：

- 如Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。

- 如Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。

— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中，随后这些危险数据被当作可信赖的数据回写到应用程序中，并储存在动态内容中。

Cross-Site Scripting (XSS) 漏洞在以下情况下发生：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Persistent（也称为 Stored）XSS，不可信赖的数据源通常为数据库或其他后端数据存储，而对于 Reflected XSS，该数据源通常为 Web 请求。


2.未经验证但包含在动态内容中的数据将传送给 Web 用户。

传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式，但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。

例 1：以下 ActionScript 代码片段会根据一个特定的雇员 ID 来查询数据库，并显示出相应的雇员姓名。

  stmt.sqlConnection = conn;
  stmt.text = "select * from emp where id="+eid;
  stmt.execute();
  var rs:SQLResult = stmt.getResult();
  if (null != rs) {
    var name:String = String(rs.data[0]);
    var display:TextField = new TextField();
    display.htmlText = "Employee Name: " + name;
  }

如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。

例 2：以下 ActionScript 代码片段可从 HTTP 请求中读取雇员 ID eid，并将其显示给用户。

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...

如Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。

起初，这个例子似乎是不会轻易遭受攻击的。毕竟，有谁会输入导致恶意代码在自己电脑上运行的 URL 呢？真正的危险在于攻击者会创建恶意的 URL，然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时，他们不知不觉地通过易受攻击的网络应用程序，将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。

正如例子中所显示的，XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种：

- 如Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。

- 如Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。

— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中，随后这些危险数据被当作可信赖的数据回写到应用程序中，并储存在动态内容中。

Cross-Site Scripting (XSS) 漏洞在以下情况下发生：

1.数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Persistent XSS，不可信赖的数据源大多数情况下为数据库查询的结果；而对于 Reflected XSS，该数据源通常为 Web 请求。

2.未经验证但包含在动态内容中的数据将传送给 Web 用户。

恶意内容通常为 JavaScript 代码片段，但也可以是 HTML、Flash 或其他任何可以被浏览器执行的活动内容。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。

示例 1：以下 Apex 代码片段在数据库中查询具有给定 ID 的联系人姓名，并返回相应的员工姓名，以便稍后通过 Visualforce 代码进行打印。

...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...

<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>

如果 name 的值定义明确（如仅包含字母数字字符），该代码就能正常运行，但不会执行与检查恶意数据有关的任何任务。即使从数据库中读取，也应对值进行适当的验证，因为数据库的内容可以源自用户提供的数据。这样，攻击者就可以在用户的 Web 浏览器中执行恶意命令，而无需像在 Reflected XSS 中那样与受害者进行交互。这种类型的攻击（称为 Stored XSS 或 Persistent）可能极难发现，因为数据被间接提供给易受攻击的函数；另外，由于这种攻击可能影响多个用户，因而会造成巨大的影响。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿的用户都会执行这些恶意代码。

示例 2：以下 Visualforce 代码片段读取 HTTP 请求参数 username，并将其显示给用户。

<script>
document.write('{!$CurrentPage.parameters.username}')
</script>

此示例中的代码原本是仅接收字母数字文本并进行显示。但是，如果 username 包含元字符或源代码，则其将由 Web 浏览器执行。

起初，这个例子似乎是不会轻易遭受攻击的。毕竟，有谁会输入导致恶意代码在自己电脑上运行的 URL 呢？真正的危险在于攻击者会创建恶意的 URL，然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时，他们不知不觉地通过易受攻击的网络应用程序，将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。

正如例子中所显示的，XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。有两种 XSS 攻击途径：

- 如Example 1 中所示，数据库或其他数据存储可能会向应用程序提供危险数据，这些数据将包含在动态内容中。从攻击者的角度看，存储恶意内容的最佳位置莫过于可供所有用户（特别是具有较高权限的用户）访问的区域，因为这些用户更有可能处理敏感信息或执行重要操作。

- 如Example 2 中所示，系统从 HTTP 请求中读取数据，并在 HTTP 响应中返回数据。如果攻击者可以将危险内容发送给易受攻击的 Web 应用程序，随后将其反馈给用户并在用户浏览器中执行，则会发生 Reflected XSS。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布的或通过电子邮件直接发送给受害者的 URL 中。以这种方式构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者可以借此诱骗受害者访问该 URL。站点将该内容反馈给用户后，便会执行这些内容，并可执行多项操作，例如转发私人敏感信息、在受害者计算机上执行未经授权的操作等。

Cross-Site Scripting (XSS) 漏洞在以下情况下发生：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Persistent（也称为 Stored）XSS，不可信赖的数据源通常为数据库或其他后端数据存储，而对于 Reflected XSS，该数据源通常为 Web 请求。


2.未经验证但包含在动态内容中的数据将传送给 Web 用户。

传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式，但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。

示例 1：以下 ASP.NET Web 表单可根据一个给定的雇员 ID 来查询数据库，并输出相应雇员姓名。

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>

其中，EmployeeName 为表单控件，定义如下：

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

示例 2：下面的 ASP.NET 代码片段实现的功能与Example 1 等效，但会以编程方式实现所有表单元素。

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;

如果对 name 的值处理得当，这些代码示例就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。

示例 3：下面的 ASP.NET Web 表单会从 HTTP 请求中读取一个雇员 ID，并将其显示给用户。

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

其中，Login 和 EmployeeID 为表单控件，定义如下：

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

示例 4：下面的 ASP.NET 代码片段显示了如何以编程方式实现Example 3.的功能的方法。

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

如Example 1 和Example 2 中所示，如果 Login 只包含标准字母数字文本，则这些示例将正常运行。如果 Login 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。

起初，这个例子似乎是不会轻易遭受攻击的。毕竟，有谁会输入导致恶意代码在自己电脑上运行的 URL 呢？ 真正的危险在于攻击者会创建恶意的 URL，然后采用电子邮件或社交工程的欺骗手段诱使受害者单击链接。当受害者单击该链接时，就会不知不觉地通过易受攻击的 Web 应用程序，使自己的电脑蒙受恶意内容带来的风险。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。

正如例子中所显示的，XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种：

- 如Example 1 和Example 2 中所示，应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。

- 如Example 3 和Example 4 中所示，系统会从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。

— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中，随后这些危险数据被当作可信赖的数据回写到应用程序中，并储存在动态内容中。

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

Cross-Site Scripting (XSS) 漏洞在以下情况下发生：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Persistent（也称为 Stored）XSS，不可信赖的数据源通常为数据库或其他后端数据存储，而对于 Reflected XSS，该数据源通常为 Web 请求。


2.未经验证但包含在动态内容中的数据将传送给 Web 用户。

传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式，但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。

例 1：下面的 CFML 代码片段将根据一个给出的雇员 ID 从数据库中查询该雇员，并显示出该雇员的相应姓名。

 
<cfquery name="matchingEmployees" datasource="cfsnippets">
  SELECT name
  FROM Employees 
  WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>

如果对 name 的值处理得当，该示例中的代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。

例 2：接下来的 CFML 代码片段将从一个 Web 表单中读取雇员 ID，eid，并将其显示给用户。

<cfoutput>
Employee ID: #Form.eid#
</cfoutput>

如Example 1 中所示，如果 Form.eid 只包含标准的字母数字文本，此代码将会正确运行。如果 Form.eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。

起初，这个例子似乎是不会轻易遭受攻击的。毕竟，有谁会输入导致恶意代码在自己电脑上运行的 URL 呢？真正的危险在于攻击者会创建恶意的 URL，然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时，他们不知不觉地通过易受攻击的网络应用程序，将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。

正如例子中所显示的，XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种：

- 如Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。

- 如Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。

— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中，随后这些危险数据被当作可信赖的数据回写到应用程序中，并储存在动态内容中。

Cross-Site Scripting (XSS) 漏洞会在以下情况下发生：

1.数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS，不可信赖的数据源通常为 Web 请求，而对于 Persisted（也称为 Stored）XSS，该数据源通常为数据库或其他后端数据存储。

2.未经验证但包含在动态内容中的数据将传送给 Web 用户。

传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式，但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。


示例 1：以下 Go 代码片段可从 HTTP 请求中读取用户名 user，并将其显示给用户。

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  user := r.FormValue("user")
  ...
  fmt.Fprintln(w, "Username is: ", user)
}

如果 user 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 user 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。

起初，这个例子似乎是不会轻易遭受攻击的。毕竟，有谁会输入导致恶意代码在自己电脑上运行的 URL 呢？真正的危险在于攻击者会创建恶意的 URL，然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时，他们不知不觉地通过易受攻击的网络应用程序，将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。

示例 2：下面的 Go 代码片段会根据一个特定的雇员 ID 来查询数据库，并显示出相应的雇员姓名。

func someHandler(w http.ResponseWriter, r *http.Request){
  ...
  row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
  err := row.Scan(&name)
  ...
  fmt.Fprintln(w, "Username is: ", name)
}

如同Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者便能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”，以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。

正如例子中所显示的，XSS 漏洞是由于 HTTP 响应中包含了未验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种：

- 如Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。

- 如Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。

- 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中，随后这些危险数据被当作可信赖的数据读回到应用程序中，并包含在动态内容中。

Cross-Site Scripting (XSS) 漏洞在以下情况下发生：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Persistent（也称为 Stored）XSS，不可信赖的数据源通常为数据库或其他后端数据存储，而对于 Reflected XSS，该数据源通常为 Web 请求。


2.未经验证但包含在动态内容中的数据将传送给 Web 用户。

传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式，但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。

示例 1：以下 JSP 代码片段可在数据库中查询具有给定 ID 的雇员，并输出相应雇员姓名。

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。

示例 2：以下 JSP 代码片段可从 HTTP 请求中读取雇员 ID eid，并将其显示给用户。

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

如Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。

起初，这个例子似乎是不会轻易遭受攻击的。毕竟，有谁会输入导致恶意代码在自己电脑上运行的 URL 呢？真正的危险在于攻击者会创建恶意的 URL，然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时，他们不知不觉地通过易受攻击的网络应用程序，将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。

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

示例 3：以下代码在 Android WebView 中启用了 JavaScript（默认情况下，JavaScript 为禁用状态），并根据从 Android Intent 接收到的值加载页面。

...
        WebView webview = (WebView) findViewById(R.id.webview);
        webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

如果 url 的值以 javascript: 开头，则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。

正如例子中所显示的，XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种：

- 如Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。

- 如Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。

- 如Example 3 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。

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