防止SQL注入的好方法是什么?

本文关键字：方法 是什么 SQL 注入 防止 | 更新日期: 2023-09-27 17:54:02

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

我以前从来没有做过这么大范围的项目;在学校里，我们只学过基本的SQL课程。不知怎么的，我们的老师完全没有讨论SQL注入，这是我现在通过在网上阅读才接触到的。

所以无论如何我的问题是:你如何防止SQL注入c# ?我模糊地认为，这可以通过适当地屏蔽应用程序的文本字段来实现，以便它只接受指定格式的输入。例如:电子邮件文本框的格式应为"example@examplecompany.tld"。这种方法足够吗?或者。net有预定义的方法来处理这些东西吗?我可以对文本框应用过滤器，使其只接受电子邮件地址格式或名称文本框，使其不接受特殊字符吗?

防止SQL注入的好方法是什么?

通过使用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);
        }
    }
}

我的回答很简单:

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

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

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。很多时候，程序员错过了这些东西，因为他们试图赶出一些功能，而没有花太多时间检查他们的代码。

SQL注入不应该通过验证您的输入来阻止;相反，在传递给数据库之前，应该对该输入进行适当的转义。

如何转义输入完全取决于您使用什么技术与数据库进行交互。在大多数情况下，除非你写的是纯SQL(你应该尽量避免这种情况)，否则框架会自动处理它，这样你就可以免费得到防弹保护。

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

相关文章：