Abstract
如果没有适当的 access control，就会执行一个包含用户控制主键的 SQL 指令，从而允许攻击者访问未经授权的记录。
Explanation
Database access control 错误在以下情况下发生：
- 数据从一个不可信赖的数据源进入程序。
- 这个数据用来指定 SQL 查询中主键的值。 例 1： 以下代码用到一个参数化指令，这个指令转义了元字符，以防止SQL injection 漏洞，并构建和执行一个 SQL 查询。该 SQL 查询指令可以搜索与指定标识符 [1] 相匹配的清单。 您可以从与当前被授权用户有关的所有清单中选择这些标识符。
...
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 框架都提供对用户输入执行验证的机制。 其中包括 Struts 和 Struts 2。 为了突出显示未经验证的输入源，该规则包会对 HPFortify Static Code Analyzer（ HP Fortify 静态代码分析器）报告的问题动态地重新调整优先级，具体方法是在采用框架验证机制时降低这些问题被利用的可能性并提供相应的依据。 我们将这种功能称之为上下文敏感排序。 为了进一步帮助 HP Fortify 用户执行审计过程， Fortify 安全研究团队开发了 Data Validation（数据验证） 项目模板，该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。
Recommendation
与其靠表示层来限制用户输入的值，还不如在应用程序和数据库层上进行 access control。 任何情况下都不允许用户在没有取得相应权限的情况下获取或修改数据库中的记录。 每个涉及数据库的查询都必须遵守这个原则，这可以通过把当前被授权的用户名作为查询语句的一部分来实现。 例 2： 以下代码实施了与例 1 相同的功能，但是附加了一个限制，即为当前被授权的用户指定某一特定的获取清单的方式。
代码语言：javascript复制...
userName = ctx.getAuthenticatedUserName();
id = Integer.decode(request.getParameter("invoiceID"));
String query =
"SELECT * FROM invoices WHERE id = ? AND user = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
stmt.setString(2, userName);
ResultSet results = stmt.execute();
...
