2

嗨,我正在使用一个数据集,在该数据集中我有一个表适配器。在我的表适配器中,我使用存储过程作为查询。如果我使用以下行通过我的表适配器插入表单数据,它对 SQL 注入安全吗?谢谢。

UserDataSetTableAdapters.UserInformationTableAdapter myFactory = new TestProject.UserDataSetTableAdapters.UserInformationTableAdapter();
            myFactory.spTest_InsertUserInformation(id, frmAddress);
4

4 回答 4

4

如果不发布您的存储过程代码,就无法真正回答您的问题,但您可能可以自己回答。


SQL 注入攻击源于用户输入的数据摆动到动态生成和执行的 SQL 查询中。使用存储过程通常通过将参数作为参数传递来避免此问题,因此不会动态生成 SQL。过程会自动封装,不会成为原始 SQL 查询文本的一部分。

以以下为例:

SELECT *
FROM myTable
WHERE myId = @ID;

作为参数,您可以安全地设置@ID为“21; DROP TABLE myTable;”。它将为您转义,整个字符串将与 myId 进行比较。但是,如果您动态生成 SQL 查询,例如

string query = "SELECT *\nFROM myTable\nWHERE myId = " + userEnteredText + ";";

现在你会得到以下信息:

SELECT *
FROM myTable
WHERE myId = 21; DROP TABLE myTable;;

哎哟。


因此,回答您的问题:如果您的存储过程没有根据其参数和EXEC它们动态生成 SQL,那么您应该是安全的。

注意:当然,这依赖于您的 .NET 数据提供程序来调用带有参数的过程,而不是生成动态 SQL 语句。大多数都正确执行此操作,但如果您使用的是第 3 方提供商,则应在假设您安全之前仔细检查。

于 2009-02-27T18:52:46.750 回答
1

简短的回答:是的:)

更新 1:即使您没有在适配器上使用存储过程和定义的带有参数的查询,也可以安全地防止 sql 注入,即 select f1, f2 where f3 = @myparameter ... 这将使用准备好的查询。

于 2009-02-27T18:48:40.287 回答
0

如果您在使用 EXEC (@SQL) 而不是带有参数的sp_executesql 的 proc 本身中使用动态 SQL,那么您是不安全的,否则您是

于 2010-03-04T19:02:55.197 回答
0

使用 SQL Prolier 跟踪进行验证。如果底层 API 是安全的,您将看到参数化的 T-SQL 命令,类似于 sp_executesql。

于 2009-02-27T18:51:43.273 回答