我们运行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);
Sink：DataBase.cs：278
System.Data.SqlClient.SqlParameterCollection.Add()
// Add parameters
foreach (SqlParameter parameter in parameters)
cmd.Parameters.Add(parameter);
答案 0 :(得分：5)
“访问控制：数据库”的要点是它在查询中不够具体，因此可能允许用户查看他们不应该的信息。 这个漏洞的一个简单示例是工资单数据库，其中有一个文本框，其中显示了员工的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可能仍然会在后一次扫描中选择此项，因此您仍然需要将其审核为已修复且不再是问题。