Overview
如果没有适当的 access control，就会执行一个包含用户控制主键的 SQL 指令，从而允许攻击者访问未经授权的记录。
Details
Database access control 错误在以下情况下发生： 1. 数据从一个不可信赖的数据源进入程序。 2. 这个数据用来指定 SQL 查询中主键的值。 在这种情况下，在 cancel.php 中第 64 行的 mysql_query() 使用该数据。
**例 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（数据验证）项目模板，该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。
Recommendations
与其靠表示层来限制用户输入的值，还不如在应用程序和数据库层上进行 access control。任何情况下都不允许用户在没有取得相应权限的情况下获取或修改数据库中的记录。每个涉及数据库的查询都必须遵守这个原则，这可以通过把当前被授权的用户名作为查询语句的一部分来实现。
**示例 2：**以下代码实现的功能与Example 1 相同，但是附加了一个限制，以验证清单是否属于当前经过身份验证的用户。 ... mysqli = new mysqli(host,dbuser, dbpass, db); userName = getAuthenticated(_SESSION\['userName'\]); id = _POST\['id'\]; query = "SELECT * FROM invoices WHERE id = ? AND user = ?"; stmt = mysqli->prepare(query); stmt->bind_param('ss',id,userName); $stmt->execute(); ...