Question

我正在评估为我的sp做SQL注入的可能性。

我已尝试使用它来进行SQL注入，但没有设法注入（意味着注入文本按正常方式插入到表中）：

data'; DROP TABLE my_table; --

我应该如何尝试SQL注入？或者SP是如此安全，以至于某种程度上阻止了SQL注入？

我的减少SP如下：

@ID int,
@AIType varchar(1),
@parent varchar(20),
@child varchar(20),
AS
BEGIN

SET NOCOUNT ON;
-- Insert statements for procedure here
BEGIN TRY
    UPDATE AI_Grouping
    SET AIType=@AIType, 
        parent=@parent,
        child=@child,
    WHERE ID=@ID
END TRY
BEGIN CATCH
    -- Catch exceptions
END CATCH
END

修改

如果有帮助 - 在前端，我有一个字段长度验证，它与SP变量类型一致。有些字段限制最多8个字符，有些字段最多20个字符（如上例所示）。也许我上面尝试的注射示例是一个不好的例子，因为长度超过20个字符...... 最终的问题是，我的SP是否容易受到SQL注入攻击？

Answer 1

来自文章：How to write SQL injection proof PL/SQL

区分编译时修复的SQL语句文本和   运行时创建的SQL语句文本

我们将术语编译时修复的SQL语句文本定义为a的文本   SQL语句在运行时无法更改且可以放心   通过阅读源代码确定。更确切地说，它是一个文本   SQL语句是PL / SQL静态varchar2表达式14。 a的价值   PL / SQL静态varchar2表达式在运行时不能更改，可以在编译时预先计算。

嵌入式SQL的SQL语句文本由PL / SQL组成   编译器并不能在运行时更改。因此，嵌入式SQL肯定   仅执行编译时修复的SQL语句text15。

但是，可以很容易地安排任何PL / SQL的执行方法   动态SQL将在特定的调用站点上仅执行编译时修复的SQL。

所以你的代码是安全的。

要区分编译时固定的SQL 和运行时创建的SQL ，这里有两个示例：

编译时固定的SQL

CREATE PROCEDURE remove_emp (p_employee_id NUMBER) AS
  BEGIN
     -- here the delete command is immutable, therefore sql injection safe
     DELETE FROM employees
        WHERE employees.employee_id = p_employee_id;
  END;

运行时创建的SQL

CREATE PROCEDURE remove_emp (p_employee_id VARCHAR2) AS
  BEGIN
     -- here the delete command is dynamically created allowing 
     -- sql injection
     execute immediate 'DELETE FROM employees
        WHERE employees.employee_id = ' || p_employee_id || ';';
  END;

存储过程的

1 个答案: