关于vb.net:SQL注入：为什么以下代码很危险？

SQL Injection: Why is the following code dangerous?

一名实习生已编写以下vb.net代码：

1
2
3
4
5
6
7
8
9
10
11
12

Public Sub PopulateUsersByName (name As String)
'Here, the parameter 'name' is unsantized, coming straight from the form

Dim query As String =""
query += vbNewLine +" SELECT Id, FirstName, LastName FROM dbo.[Users]"
query += vbNewLine +" WHERE FirstName LIKE '" + REPLACE(name,"'","''") +"'"
query += vbNewLine +" OR LastName LIKE '" + REPLACE(name,"'","''") +"'"

'Execute SQLCommand with above query and no parameters
'Then do some other stuff

END Sub

我已经解释了，通常，在尝试执行上述操作时，永远不要使用字符串连接。最佳做法是使用SP或带参数的SQLClient.SQLCommand。

他的逻辑是：通过将所有单引号替换为两个单引号(并在字符串的开头和结尾添加其他单引号)来清理任何sql varchar(xxx)。

我无法提供一个示例，说明用户可以键入以解决此问题的方法-我希望我能找到比"但但是，作为一般负责人，应该避免这种情况-知道的，因为……"更令人信服的事情。好吧，别跟我争论-我是老板，我的愿望就是你的命令。"

注意：该代码将始终连接到我们的Microsoft SQL Server。但是我可以想象它未能清理其他一些SQL实现上的输入。

更新：

为了更清楚一点，我正在寻找的是参数name的可能值，该值将允许某人将SQL注入查询中。

相关讨论

请参阅有关安全性的问题/答案。两个要点-最佳答案是有关SQL走私技术的。第一个评论是"为什么不正确地做它而不是想知道它是否可以被利用？"
@Damien_The_Unbeliever我浏览了SQL Smuggling PDF，找不到任何适用于上述问题的内容。即使编写也不会导致代码失败。至于"为什么不正确地做而不是想知道它是否可利用"，问题是我的实习生百分百肯定它是不可利用的。我不确定那个人……我想我将不得不诉诸："我是老板……"
但是存在SQL走私的概念。即使该PDF不包含任何已知能在今天使用的表格，谁知道明天是否找不到适用于SQL Server和您的数据库的新表格？还是3年后？您的实习生是否承诺在发现这种新漏洞后的零日通知时间内返回并免费工作以识别并修复所有问题位置？参数使您可以将"应视为代码的事物"和"绝对应仅被视为数据的事物"完全分开。
您可能需要阅读以下答案：stackoverflow.com/a/15596300/2505574
@Damien_The_Unbeliever我认为您误解了这个问题。我不是要找人说服我遵循最佳实践-我已经计划更改代码。我只是希望有一个具体的例子来解释最佳实践。
@ObsidianPhoenix谢谢-但在我的情况下，用户输入在开头和结尾处添加了单引号-它不是可在不同情况下使用的通用函数(例如：`或")。
也许它不在此查询上，但是他有可能在其他查询上忘记了。在投入生产之前，您需要有人检查所有查询以确保它们没问题。确保数字(不仅是字符串)也可以。
我只是在等待答案(从您的实习生那里)弹出，说"这不是"。
我想知道，为什么要添加新行？有点毫无意义。...您是以某种方式记录或显示查询吗？如果要显示查询，使用参数(应该使用)会增加一些难度。
好吧，随着我的跟进，我希望弄清楚-首次发现SQL注入时，许多人认为将报价加倍就足够了。然后发现了一种走私技术，突然之间有些人的"不可利用"代码突然出现了。然后出现了另一种技术。然后另一个。但是，每一个都是一个突破，根本问题没有得到解决(混合代码和数据)，并且长期以来一直知道适当的解决方案。这不是一个很好的解释吗？
因此，问题的要旨是"我们可以提供特定的name值"，这将允许我们执行任意SQL？在这种情况下可能不会。尽管您需要检查整个堆栈的相关源代码，以确保.NET Framework /传输协议/ SQL Server。尽管有其他原因坚持参数化查询。除了绝对安全之外，它们还更好地利用了计划缓存，而不是用一次性的即席查询填充它。
@the_lotus新行只是为了使代码在调试过程中更具可读性。它并没有真正造成伤害，并且使调试更快。我通常鼓励使用换行符-我有没有想到过的缺点？
@Damien_The_Unbeliever感谢您提供给我的所有信息-在指出这一点时，它肯定会使我的观点更强。我的主旨是在这种情况下还可以，但是因为我不想每次都坐下来仔细检查他的询问，通常他不应该这样做。我是老板，所以他最好听；)
@MartinSmith是的，那是正确的...那就是我想要的要点。性能方面是我完全忽略的一个方面……感谢您指出这一点。
@ganders哈哈，如果我的实习生看到这个：D会很尴尬。但是，再三考虑，如果我向他展示人们如何被串联SQL的想法所困扰，那可能是最好的！
是的，Omaer有一天会告诉他，我自己可能需要对他的代码进行操作，而我不想花所有这些天来调试代码！

尝试使用他的代码，使用'％_％'(带或不带单引号)作为输入。...与SQL中的用法相同。...

1	select SELECT Id, FirstName, LastName FROM dbo.[Users] from TBL_EMPLOYEES where FirstName like '%_%' or LastName like '%_%'

不管它是否失败，他的代码都是很糟糕的……很公平，这只是一个衬里，而除此之外，包括复杂的SQL语句将很难维护和调试。让他习惯使用它们，并允许他利用T-SQL的灵活性和强大功能...大声笑，我怕想想我编写的某些SQL在代码中的样子。

您知道，我一直都在遇到这样的代码(而且更糟糕)……只是因为它可能会工作一段时间，但这并不意味着这是正确的方法。……如果您的实习生没有这样做听经验，他永远不会成为一个好的开发者，可悲的是，这是事实

我曾经减少了一个初级开发人员尝试以与您的实习生相同的方式导入CSV文件(5,000万行)的尝试，从她的300行代码(这永远行不通)到仅一行LINQ即可将其转换为XML(我们不能使用Bulk Insert或bcp)和精美的SP。

消毒不是答案。您可以通过引号并使用"走私"。一个很好的例子是http://danuxx.blogspot.com.br/2011/08/sql-injection-bypassing-single-quotes.html

另外一个好的做法(使用动态查询)是使用参数动态查询。 SP也可以做到这一点(如果您当然不在其中使用动态查询)。