SQL 注入可能是一个棘手的问题,但有一些方法可以解决它。只需使用 Linq2Entities、Linq2SQL、NHibrenate 之类的 ORM,您的风险就会降低。但是,即使使用它们,您也可能遇到 SQL 注入问题。
SQL 注入的主要内容是用户控制输入(与 XSS 一样)。在最简单的示例中,如果您有一个登录表单(我希望您永远不会有一个这样做的),它需要用户名和密码。
SELECT * FROM Users WHERE Username = '" + username + "' AND password = '" + password + "'"
如果用户为用户名 Admin' -- 输入以下内容,则在对数据库执行时 SQL 语句将如下所示。
SELECT * FROM Users WHERE Username = 'Admin' --' AND password = ''
在这种简单的情况下,使用参数化查询(这是 ORM 所做的)将消除您的风险。您还有一个鲜为人知的 SQL 注入攻击向量的问题,那就是存储过程。在这种情况下,即使您使用参数化查询或 ORM,您仍然会遇到 SQL 注入问题。存储过程可以包含执行命令,而这些命令本身可能容易受到 SQL 注入攻击。
CREATE PROCEDURE SP_GetLogin @username varchar(100), @password varchar(100) AS
DECLARE @sql nvarchar(4000)
SELECT @sql = ' SELECT * FROM users' +
' FROM Product Where username = ''' + @username + ''' AND password = '''+@password+''''
EXECUTE sp_executesql @sql
因此,即使您使用参数化查询或 ORM,此示例也会出现与上一个示例相同的 SQL 注入问题。虽然这个例子看起来很傻,但你会惊讶于这样的东西被写的频率。
我的建议是使用 ORM 立即减少遇到 SQL 注入问题的机会,然后学习发现可能出现问题的代码和存储过程并努力解决它们。我不建议直接使用 ADO.NET(SqlClient、SqlCommand 等...),除非您必须这样做,不是因为将它与参数一起使用不安全,而是因为它更容易变得懒惰并开始编写 SQL使用字符串查询并忽略参数。 ORMS 在强迫您使用参数方面做得很好,因为这正是他们所做的。
下一步访问 OWASP 网站上的 SQL 注入 https://www.owasp.org/index.php/SQL_Injection 并使用 SQL 注入备忘单确保您可以发现并解决代码中可能出现的任何问题。 https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 最后我想说的是,在您和您公司的其他开发人员之间进行良好的代码审查,您可以在其中审查彼此的代码,例如 SQL 注入和 XSS。很多时候程序员会错过这些东西,因为他们试图赶出一些功能并且没有花太多时间来审查他们的代码。