QuoteIdentifier是否足以保护查询免受Sql注入攻击?

本文关键字：Sql 注入攻击查询是否保护 QuoteIdentifier | 更新日期: 2023-09-27 18:18:29

虽然参数是防止Sql注入的最佳方法，但有时我们不能在构建动态查询时使用它。例如，表/列/索引名称不能作为参数传入，只能作为纯文本传入。

似乎

SqlCommandBuilder.QuoteIdentifier

是我能找到的唯一选项。调用这个方法是否足以保护我们自己?

MSDN文档:

给定正确目录大小写中的未加引号标识符，返回正确标识符的引号形式。这包括正确地转义标识符中的任何嵌入引号。

例如

"Select * FROM " + SqlCommandBuilder.QuoteIdentifier("CustomTable" + userInputText);

安全怎么办?

编辑:查询只是一个例子。我有兴趣找出是否Sql注入是可能的。

QuoteIdentifier是否足以保护查询免受Sql注入攻击?

它不会保护你免受攻击者进入你不希望他们进入的表。

这样做可能不安全。

防止SqlCommandBuilder出现任何可能的安全问题。QuoteIdentifier方法，您所需要做的就是从数据库中获取可用表名等的列表，并根据它们验证用户输入。

编辑补充:我有理由怀疑QuoteIdentifier是否完全安全:SqlCommandBuilder的文档。QuoteIdentifier方法说(正如你之前引用的):

给定正确目录大小写中的未加引号的标识符，返回该标识符的正确加引号形式。这包括正确转义标识符中的任何嵌入引号。

在该文档中没有任何地方说明如果在错误的目录情况下(无论"目录情况"是什么)给它一个未引用的标识符会发生什么。或者如果标识符比允许的最大长度长会发生什么。当然，不能依赖未定义的行为。

对我来说似乎是安全的。此外，这可能是一个很好的参考:

清理表/列名在动态SQL在。net ?(防止SQL注入攻击)

在表名字段中使用用户输入永远都不安全，无论您如何检查它(除非您将条目限制为一组有限的名称或执行其他类型的魔法)。

即使去掉引号，用户也可以输入:TableName; DROP DATABASE db;或(SELECT * FROM <sensible table)。

可能的解决方案是:

使用ComboBox或等同的，用户不能修改选项
用所有允许的表名检查String[]的输入(它们应该与其中一个表项相同)

，如果用户输入作为表名只是一个例子，但你要使用输入作为SELECT的WHERE子句的一部分，那么你应该检查Bobby Tables。

引自网站:

来自c# Online wiki页面。. NET安全技巧——避免SQL注入

SqlCommand userInfoQuery = new SqlCommand(
    "SELECT id, name, email FROM users WHERE id = @UserName",
    someSqlConnection);
SqlParameter userNameParam = userInfoQuery.Parameters.Add("@UserName",
    SqlDbType.VarChar, 25 /* max length of field */ );
// userName is some string valued user input variable
userNameParam.Value = userName;

或简单的:

String username = "joe.bloggs";
SqlCommand sqlQuery = new SqlCommand("SELECT user_id, first_name,last_name FROM users WHERE username = ?username",  sqlConnection);
sqlQuery.Parameters.AddWithValue("?username", username);

您考虑过使用OData吗?您可以传入文本、选择表、索引等。但是对于OData，您可以选择要以这种方式发布的表，并且它不能被注入攻击，因为您必须显式地允许更新和插入操作。

http://www.odata.org/documentation/odata-version-2-0/uri-conventions/https://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api

相关文章：

最新信息: