访问控制：数据库强化

Question

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

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

来源：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 可能仍会在以后的扫描中选择它，因此您仍然需要将其审核为已修复且不再是问题。