Question

场景：我的查询变量是动态的，根据报表类型（_reportType），有四个可能的值。意味着有4个不同的查询，其中一些在@STAFF条件下没有where，所以我的问题是，仅保留我的

是否安全？

dBCommand.AddParameter("@STAFF", staff)

为了安全起见，我是否应该包括其他条件？

if(_reportType == 1) 
{
    dBCommand.AddParameter("@STAFF", staff);
}
else if (_reportType == 2) 
{
    //code
}
else if (_reportType == 3) 
{
    //code
}
else
{
     //Don't add dBCommand.AddParameter("@STAFF", staff);
}

即使我不打算在查询中使用它，仅留下addParameter("@STAFF", staff)还是安全的吗？

我要写的例子

dBCommand.Initialize(string.Format(query, "RetailTable"), batch);
dBCommand.AddParameter("@STAFF", staff);

但是查询值在@STAFF条件下没有WHERE

Answer 1

除了将值发送到服务器的少量开销外，通常还可以指定未使用的参数。例外是，如果您执行的DDL查询的限制是该批处理中的唯一语句（例如CREATE VIEW）。由于该参数，这些操作将失败。

Answer 2

您的方法中有2种明显的不良做法：

1。在代码内生成动态查询。

此方法具有许多缺点，并可能存在安全漏洞。您几乎应该始终避免这样做。

请通过以下链接了解更多信息：

https://codingsight.com/dynamic-sql-vs-stored-procedure/ https://www.ecanarys.com/Blogs/ArticleID/112/SQL-injection-attack-and-prevention-using-stored-procedure

2。尝试使用适合您所有变体的通用Where子句。

无论查询是在应用程序代码中还是在存储过程中编写，此方法在等待时都是灾难性的。

这是丑陋的代码气味和维护噩梦。

没有一个开发人员可以百分百确定在应用程序的生命周期内不需要进行任何更改，因为一个简单的事实，即客户端将需要定期进行增强。

因此，即使这种方法可能在短时间内对您有用，也会反吹。

假设，在此期间，由于新要求，添加的过滤器参数很少。现在，想象一下您的代码是什么样子，以及如果处理不当可能会产生的问题。特别是当您不进行这些更改时。吓人吧？

无论编写代码的人如何，始终编写的代码不仅易于阅读和理解，而且易于增强和维护。

因此，恕我直言，您应该添加这些if-else条件或使用switch-case块来保护自己和客户。一开始它可能看起来有些过分，但是将来肯定会有所收获。

希望获得帮助！

即使我不打算在查询中使用dBCommand.AddParameter还是安全的？

2 个答案: