Question

小背景：我是这家公司唯一的程序员。我正在使用预先存在的框架。

也就是说，该公司有一个dll（Database.dll），其中包含“我需要的所有数据库交互”。如同，它有Query()，Update()，Insert()等。现在，我正在编写的项目设置了对Database.dll的引用。我的项目接受零用户输入。与用户输入最接近的是用户可以从中选择日期的下拉框。没有太多的经验，我很好奇我是否还需要担心SQL注入？如果是这样，那么查询会写成

var query = string.Format("SELECT timestamp FROM table1 WHERE date = \"{0}\" 
                           AND measured_dist = bit_loc AND rop > 0" , Date))

足以作为参数化查询吗？请记住，所有查询执行都由预先存在的Query()处理，我告诉我必须使用它，并且无法编辑。

修改

该程序是WinForm应用程序。

Answer 1

如评论中所述，答案是“永远”。因为这么容易为它添加一个参数并正确地执行它而不是连接：只是第一次正确地执行它。另外：你认为注射不是你所展示的代码中唯一的问题吗？该代码也易受本地化/国际化的影响。对于在不同文化中配置PC的用户会发生什么？日期和数字将以不同的方式呈现 - 并且经常会破坏。参数不会发生这种情况。另外：名字经常有撇号：）

Answer 2

延伸@ KirkWoll非常有效的注释，只要在SQL语句中包含任何用户输入（或来自自动源的输入），就会使程序面临SQL注入的风险。

作为一项政策问题，您永远不应该使用任何此类输入构建自己的SQL语句。

始终清理输入并始终使用参数化查询作为针对SQL注入的第一道防线。

如果您之前没有看过，那么xkcd上有很好的例证

http://xkcd.com/327/

Answer 3

鉴于这是一个WinForms程序，访问数据库的唯一安全方法是使用带参数的存储过程。然后创建仅有权访问这些SP的用户。其他任何事情都不安全。

虽然带有参数的查询在与可能具有“攻击”输入的Web应用程序一起使用时用作安全措施，但当与本地应用程序一起使用时，它们会失败，可以将其拆分并重新写入任何内容。如果您不提供SP安全性，则会丢失。

Answer 4

即使用户交互可能是下拉列表，但复杂的攻击者也可能插入不在选择列表中的值。所以，是的，你仍然应该警惕SQL注入。

Answer 5

即使没有SQL注入，我也会使用预准备语句。它们更容易使用，在某些情况下，它们允许数据库缓存语句，而不必在下次使用时编译它。 Oracle这样做，我认为SQL Server确实如此，我不知道MySQL是否会这样做。

你应该总是假设有黑客，即使在内部内部网项目中，我使用预备语句，我使用nonce来防止CSRF。

什么时候担心SQL注入保护

5 个答案: