53

我必须为我的 OJT 公司编写一个应用程序管理系统。前端将在 C# 中完成，后端将在 SQL 中完成。

现在我以前从未做过这个范围的项目；在学校里，我们只有关于 SQL 的基本课程。不知何故，我们的老师完全没有讨论 SQL 注入，这是我现在才通过在网上阅读它才接触到的。

所以无论如何我的问题是：如何防止 C# 中的 SQL 注入？我隐约认为可以通过适当地屏蔽应用程序的文本字段来做到这一点，以便它只接受指定格式的输入。例如：电子邮件文本框的格式应为“example@examplecompany.tld”。这种方法就足够了吗？或者.NET 是否有预定义的方法来处理这样的事情？我可以将过滤器应用于文本框，使其仅接受电子邮件地址格式或名称文本框，因此它不接受特殊字符吗？

4

4 回答 4

66

通过使用SqlCommand及其子参数集合，所有检查 sql 注入的痛苦都被消除了，将由这些类处理。

这是一个示例，取自上述文章之一：

private static void UpdateDemographics(Int32 customerID,
    string demoXml, string connectionString)
{
    // Update the demographics for a store, which is stored  
    // in an xml column.  
    string commandText = "UPDATE Sales.Store SET Demographics = @demographics "
        + "WHERE CustomerID = @ID;";

    using (SqlConnection connection = new SqlConnection(connectionString))
    {
        SqlCommand command = new SqlCommand(commandText, connection);
        command.Parameters.Add("@ID", SqlDbType.Int);
        command.Parameters["@ID"].Value = customerID;

        // Use AddWithValue to assign Demographics. 
        // SQL Server will implicitly convert strings into XML.
        command.Parameters.AddWithValue("@demographics", demoXml);

        try
        {
            connection.Open();
            Int32 rowsAffected = command.ExecuteNonQuery();
            Console.WriteLine("RowsAffected: {0}", rowsAffected);
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
    }
}
于 2013-01-17T10:28:20.750 回答
10

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 在强迫您使用参数方面做得很好，因为这正是他们所做的。

Next 访问关于 SQL 注入的 OWASP 站点https://www.owasp.org/index.php/SQL_Injection并使用 SQL 注入备忘单来确保您可以发现并解决代码中出现的任何问题。 https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 最后我想说的是，在您和您公司的其他开发人员之间进行良好的代码审查，您可以在其中审查彼此的代码，例如 SQL 注入和 XSS。很多时候程序员会错过这些东西，因为他们试图赶出一些功能并且没有花太多时间来审查他们的代码。

于 2013-01-17T10:27:17.227 回答
9

我的回答很简单：

使用实体框架在 C# 和 SQL 数据库之间进行通信。这将使参数化的 SQL 字符串不易受到 SQL 注入的影响。

作为奖励，它也很容易使用。

于 2013-01-17T10:05:33.253 回答
5

不应该通过验证您的输入来阻止 SQL 注入；相反，该输入应该在传递到数据库之前正确转义。

如何转义输入完全取决于您用于与数据库交互的技术。在大多数情况下，除非您编写裸 SQL（应尽可能避免），否则框架会自动处理它，因此您可以免费获得防弹保护。

在您确定您的接口技术将是什么之后，您应该进一步探讨这个问题。

于 2013-01-17T10:05:58.513 回答