若未经 authentication 便在匿名绑定下有效地执行 LDAP 查询，会导致攻击者滥用低端配置的 LDAP 环境。

例 1：以下代码使用 ldap_simple_bind_s() 匿名绑定到一个 LDAP 目录。

...
rc = ldap_simple_bind_s( ld, NULL, NULL );
  if ( rc != LDAP_SUCCESS ) {
    ...
  }
...

针对 ld 执行的所有 LDAP 查询都会在未经 authentication 和 access control 的情况下执行。攻击者可能会采取意想不到的方式操纵其中的某个查询，以便可以访问本应受目录 access control 机制保护的记录。

若未经 authentication 便在匿名绑定下有效地执行 LDAP 查询，会导致攻击者滥用低端配置的 LDAP 环境。

例 1：以下代码使用一个匿名绑定创建 DirContext ctx。

...
env.put(Context.SECURITY_AUTHENTICATION, "none");
DirContext ctx = new InitialDirContext(env);
...

针对 ctx 执行的所有 LDAP 查询都会在未经 authentication 和 access control 的情况下执行。攻击者可能会采取意想不到的方式操纵其中的某个查询，以便可以访问本应受目录 access control 机制保护的记录。

在匿名绑定下有效地执行 LDAP 查询（没有身份验证）可导致攻击者滥用配置不当的 LDAP 环境。

示例 1：如果用户输入空密码，以下代码将创建一个匿名绑定。

...
$ldapbind = ldap_bind ($ldap, $dn, $password = "" );
...

通过此连接执行的所有后续 LDAP 查询都是在没有身份验证和 Access Control 的情况下执行的。攻击者可能会以意外的方式操纵其中一个查询，从而获取对受目录 Access Control 机制保护的记录的访问权限。

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

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

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

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

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

2. 数据用于在 LDAP 查询中指定一个数据值。
示例 1：以下代码会在使用雇员名称创建 LDAP 查询之前，使用一个允许列表来验证雇员名称的有效性。该验证避免了 LDAP injection 漏洞，但仍可能留下代码漏洞。

char* allowlist_verify(char* name) {
    const char *error;
    int errOffset;
    char* regex = "^[a-zA-Z\\-\\.']+$";
    pcre* re = pcre_compile(regex, 0, &err, &errOffset, NULL);
    int rc = pcre_exec(re, NULL, name, strlen(name), 0, 0, NULL, 0);
    if (rc == 1)
        return name;
    return NULL;
}
...
fgets(managerName, sizeof(managerName), socket);
char* verified_name = allowlist_verify(managerName);
if(verified_name != NULL) {
    snprintf(filter, sizeof(filter), "(manager=%s)", verified_name);
    if ( ( rc = ldap_search_ext_s( ld, FIND_DN, LDAP_SCOPE_BASE,
            filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
            LDAP_NO_LIMIT, &result ) ) == LDAP_SUCCESS ) {
    ...
    }
}

问题在于开发人员未能考虑到若攻击者提供可供选择的 username 值，会发生什么情况。因为本例子中的代码是在匿名绑定情况下执行查询，不管当前已验证用户的身份如何，它都会将有效的雇员 ID 返回至目录入口。

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

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

2. 数据用于在 LDAP 查询中指定一个数据值。
例 1：当前已验证用户的雇员 ID 会随着各个请求一起，通过客户端界面自动提交。以下代码在使用雇员 ID 构建 LDAP 查询之前，将检查该雇员 ID 是否为整数。该验证避免了 LDAP injection 漏洞，但仍可能留下代码漏洞。

...
env.put(Context.SECURITY_AUTHENTICATION, "none");
DirContext ctx = new InitialDirContext(env);

String empID = request.getParameter("empID");

try
{
  int id = Integer.parseInt(empID);

  BasicAttribute attr = new BasicAttribute("empID", empID);

  NamingEnumeration employee =
            ctx.search("ou=People,dc=example,dc=com",attr);
...

问题在于开发人员未能考虑到若攻击者提供可供选择的 empID 值，会发生什么情况。尽管该界面会自动提交当前用户的雇员 ID，但是攻击者也可能在恶意请求中提交其他值替换当前的 ID。因为本例子中的代码是在匿名绑定情况下执行查询，不管当前已验证用户的身份如何，它都会将有效的雇员 ID 返回至目录入口。