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 回答