fortify - 访问控制 : Database Fortify

Question

我们运行了 Fortify 扫描并遇到了一些访问控制:数据库问题。该代码正在获取文本框值并将其设置为字符串变量。在这种情况下，它将值从 TextBox 传递到数据库中的存储过程。关于如何解决此访问控制:数据库问题的任何想法？

没有适当的访问控制，DataBase.cs 中的 ExecuteNonQuery() 方法
可以在第 320 行执行包含攻击者控制的主数据库的 SQL 语句
key ，从而允许攻击者访问未经授权的记录。

来源:Tool.ascx.cs:591 System.Web.UI.WebControls.TextBox.get_Text()

rptItem.FindControl("lblClmInvalidEntry").Visible = false;    
ToolDataAccess.UpdateToolData(strSDN, strSSNum, strRANC, strAdvRecDate, strAdvSubDate,  strClmRecDate, strClmAuth, strClmSubDate, strAdvAuth, txtNoteEntry.Text);

接收器:DataBase.cs:278

System.Data.SqlClient.SqlParameterCollection.Add()

// Add parameters

foreach (SqlParameter parameter in parameters)

cmd.Parameters.Add(parameter);

Answer 1

“访问控制:数据库”的重点在于它在查询中不够具体，因此可能允许用户看到他们不应该看到的信息。
此漏洞的一个简单示例是工资单数据库，其中有一个文本框显示员工的 ID 并给出他们的薪水，这可能允许用户更改 ID 并查看其他员工的薪水。
这通常是预期功能的另一个示例是在网站 URL 中，其中产品 ID 用于参数，这意味着用户可以浏览您网站上的每个产品。但由于这仅允许用户查看他们应该能够查看的信息，因此这并不是一个特别的安全问题。

例如:

"SELECT account_balance FROM accounts WHERE account_number = " + $input_from_attacker + ";"
// even if we safely build the query above, preventing change to the query structure,
// the attacker can still send someone else's account number, and read Grandma's balance!

由于这是非常基于上下文的，因此很难静态确定，因此有很多示例 Fortify 可能会捕捉到这一点，但它实际上是预期的功能。这并不是说该工具已损坏，这只是静态分析的局限性之一，并且取决于您的程序应该做什么，它可能会或可能不会。
如果这打算像这样工作，那么我建议将其审核为不是问题或抑制问题。
如果您可以看到这绝对是一个问题，并且用户可以看到他们不应该看到的信息，那么存储过程需要更加具体，以便用户只能看到他们应该能够看到的信息。然而，SCA 可能仍会在后面的扫描中发现这一点，因此您仍然需要将其审核为已修复且不再是问题。