0

有一个带有参数的函数。该函数在内部调用带有参数的存储过程。客户端可以通过 HTTP 请求将字符串传递给函数。

我正在尝试添加一种方法来消除通过参数注入危险 SQL 语句的任何可能性。方法名称是 IsSQLParameterSafe()，它根据参数返回布尔值。如果该值可以安全执行，则该方法将返回 true，否则返回 false。

在我的情况下，参数不必有空格，所以如果有任何空格，那么它将返回 false。另外，我将输入的长度限制为 64，因为它是参数的最大长度。

你认为我的想法会奏效吗？如果没有，你能提出一些想法吗？

谢谢

4

2 回答 2

2

即使使用存储过程，您也可以使用参数化查询。这是应对 SQL 注入风险的最佳方式。如果不知道您使用的是什么语言，很难更具体，但是在 Java 中，例如，您会使用类似于以下内容的内容：

String callStmt = "CALL PROC(?)";
PreparedStatement prepStmt = con.prepareStatement(callStmt);
prepStmt.setString(1, parameter);
ResultSet rs = prepStmt.executeQuery();

您可能还对 OWASP SQL 注入预防备忘单感兴趣，其中包含更多详细信息。

于 2013-05-29T12:32:30.643 回答
1

您无需担心，除非您手动将 SQL 拼接在一起，然后使用 EXEC 命令执行它。

例如，这是一个简单的存储过程：

CREATE PROCEDURE DeleteRecord
(
@name VARCHAR(64)
)
AS
BEGIN
DELETE FROM Records WHERE [Name] = @name
END

如果您尝试将此字符串传递到过程中...

name OR 1=1

...然后程序将删除 0 条记录，因为没有人有这个确切的名称。

为什么不删除所有内容？

存储过程不会将 SQL 拼接成一个大字符串（您经常在 PHP 初学者教程中看到这种事情）。相反，它传递原始 SQL 语句，然后将每个参数作为不同的参数。我不知道它是如何工作的技术细节，但我从经验中知道添加斜杠和引号以及乱码不会破坏这个查询。

但...

如果您正在编写动态 SQL，并且您的参数表示一个表或列名，那么您需要更加小心。我会为此使用白名单。

http://www.sommarskog.se/dynamic_sql.html

于 2013-05-29T12:46:10.600 回答