有一个带参数的函数。该函数在内部调用带有该参数的存储过程。客户端可以通过HTTP请求传递字符串给函数。
我试图添加一个方法来消除通过参数注入危险SQL语句的任何可能性。方法名称是IsSQLParameterSafe()，它根据参数返回布尔值。如果该值可以安全执行，则该方法将返回true，否则返回false。
在我的例子中，参数不一定要有空格，所以如果有空格，那么它将返回false。同样，我将把输入的长度限制为64因为这是参数的最大长度。
你认为我的主意会奏效吗?如果没有，你能提出建议吗?谢谢
您甚至可以对存储过程使用参数化查询。这是处理SQL注入风险的最佳方法。如果不知道您使用的是什么语言，就很难更具体，但是在Java中，例如，您将使用类似于这样的内容:
String callStmt = "CALL PROC(?)";
PreparedStatement prepStmt = con.prepareStatement(callStmt);
prepStmt.setString(1, parameter);
ResultSet rs = prepStmt.executeQuery();
您可能还对OWASP SQL注入预防备忘单感兴趣，其中有更详细的内容。
您不需要担心，除非您手动将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