.net - 惠普强化 360 a

Question

扫描 Asp.Net 项目时出现错误，提示访问控制数据库，

它说

“如果没有适当的访问控制，执行包含用户控制的主键的 SQL 语句可以让攻击者查看未经授权的记录。”

即使对输入字段进行了适当的验证并且数据跨层移动，即前端（UI）->业务层->数据层。

控件或数据库上是否有任何属性要设置以便解决问题

Answer 1

“访问控制：数据库”是指从攻击者那里接收到一个 NUMERIC 输入数据，并提供给查询。它可能会针对格式进行验证，例如“确保它是一个正整数”，但风险在于，如果攻击者控制了该值，他可以更改查询的主键，从而获取不同的数据。

这与 SQL 注入的不同之处仅在于 SQL 注入按照惯例意味着攻击者改变了查询的结构（例如，通过添加关键字）。但当然，它们都是向 SQL 中注入内容。

“控件或数据库上是否有属性......？” 不。

1. 要正确验证此数据，您必须放置应用程序级别的控件，以确保攻击者只提供允许他添加的主键。例如，您可以通过根本不向远程客户端提供值来执行此操作。您也许可以跨请求将其保留在会话中。

2. 要正确解决完全合法的问题：在审计分析或主要标签下拉列表中选择“不是问题”。输入评论，向安全主管解释为什么您认为该逻辑是合​​理且安全的。使用不必要的愚蠢提交按钮提交评论。

3. 为了正确解决一整类合法问题：我通常创建一个过滤器来隐藏访问控制：数据库问题，其中不受信任的数据的来源不是远程攻击者，而是数据库。

在这种情况下，查询 1 查找“Jane Doe”并获取她的 foo ID。查询 2 在 ID = Jane 的 foo ID 的另一个地方查找。ID 源自第一个数据库查询。数据将带有一个名为“DATABASE”的 Fortify Taint Flag。您和您的安全审计员可能信任此信息源。或者，它可能被认为是黑客隐藏恶意数据以破坏您的应用程序的另一个地方。我不会知道的。

如果您和您的安全审计员信任数据库，您可以创建一个过滤器“if taint:database -> hide the issue”，然后将此过滤器放入项目模板的默认过滤器集中。您可以使用 Audit Workbench 的 Tools->Project Configuration... 对话框执行此操作。

Answer 2

只要它直接来自用户 fortify 就会警告您。通常它是假阳性的。Fortify 预计，用户输入必须从另一个来源（如数组）进行验证。

另一种解决方法是创建一个自定义 dll，其中包含用于用户输入的验证功能。不要将用户参数直接传递给数据库层。使用您的自定义 dll 验证这些输入。这将 %100 工作。