Question

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

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

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

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

由于

Answer 1

即使存储过程也可以使用参数化查询。这是处理SQL注入风险的最佳方法。在不知道你正在使用什么语言的情况下更难具体化，但在Java中，你会使用类似的东西：

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

您可能也对OWASP SQL Injection Prevention Cheat Sheet感兴趣，后者会详细介绍。

Answer 2

除非您手动将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

消除了注入危险SQL查询的可能性

2 个答案: