Oracle SQL注入与PL注入剖析

数据库 Oracle
本人很喜欢Oracle SQL注入与PL注入的代码编写,在工作中也很喜欢总结关于PL/SQL的语言,下面就SQL注入这个问题来详细说说吧。

Oracle sql注入是一个古老的安全问题,一般做企业应用的只关注Java层面的编写规范,比如使用preparedStatement,或者干脆直接过滤掉危险字符等等。其实在编写PL/SQL的function或procedure的时候,也存在注入的问题,我们来简单探讨一下。

例如有这样一个procedure,功能为禁用某个table的constraint:

Sql代码

CREATE OR REPLACE PROCEDURE Disable_Constraint  ( p_constraint_name  VARCHAR2, p_table VARCHAR2 )

AUTHID CURRENT_USER

AS

p_schema VARCHAR2(32) := USER;

sql_stmt VARCHAR2(2000) := 'ALTER TABLE '

|| p_schema

|| '.'

|| p_table

|| ' DISABLE CONSTRAINT '

|| p_constraint_name ;

BEGIN

EXECUTE IMMEDIATE sql_stmt;

END;

/

了解Oracle sql注入的同学应该可以看出来,上面的procedure存在几个危险的变量:
1. p_table
2. p_constraint_name
3. p_schema

前两者容易发现,但为什还有p_schema呢?因为当前的USER名字也有可能是用户构造的危险字符串。好了,根据一般规律,我们应该遵循以下顺序进行修改:
1. 静态SQL。能不使用变量就不使用。
2. 绑定变量。与Java中的PreparedStatement类似,不把数据直接拼接在sql里,而是存入变量中,直接被数据库使用。
3. 检查变量的值。

显然,前两个方法对这个procedure不适用。我们只能使用最不爽的第3个方法。好在对于Oracle SQL注入与PL注入来说,我们不用自己编写复杂的字符判断。Oracle有个SYS.DBMS_ASSERT包,提供了一些预置的function,如下:

NOOP No Operation. Returns string unchanged

SIMPLE_SQL_NAME Verify that the input string is a simple SQL name.

QUALIFIED_SQL_NAME Verify that the input string is a qualified SQL name.

SCHEMA_NAME This function verifies that the input string is an existing schema name.

SQL_OBJECT_NAME This function verifies that the input parameter string is a qualified SQL identifier of an existing SQL object.

ENQUOTE_NAME This function encloses a name in double quotes.

ENQUOTE_LITERAL Add leading and trailing single quotes to a string literal.

在执行这些function时,如果传入的变量不满足规定的格式或条件,则会抛异常,从而保护我们自己的procedure不被SQL注入。

我们判断这些方法是否可用:

1. SIMPLE_SQL_NAME, QUALIFIED_SQL_NAME

这些方法要求用户出入的参数本身是一个有效的sql名字。比如,如果有个table名为"Table One",那么就要求传入的值中包含双引号。使用这些方法存在一个问题,直接从data-dictionary读取出来的table名字是不带双引号的。如果用户直接从data-dictionary中读取table名字,然后直接传入我们的procedure,则会因为它不满足simple sql name的要求而抛异常,但实际上这个table名字应该是正确的。所以不能直接使用这些function。

2. SCHEMA_NAME, SQL_OBJECT_NAME

这些方法要求传入的参数值是数据库中已经存在的对象名字。如果数据库中本来有个table名为 "Table One",那么如果用户传入Table One,则被视为正确。使用这些方法,避免了第一个方法的data-dictionary问题,而且也能够避免遭受类似table' -- 的问题。但存在所谓二次攻击的问题。如果用户提前创建了一个包含危险字符的table,然后再调用我们的procedure,依旧会造成SQL注入。

3. ENQUOTE_NAME, ENQUOTE_LITERAL

这些方法直接把参数的值用双引号或单引号括起来。如果括起来之后的值本身还存在危险的话,会抛异常。对于我们举例的procedure来说,只需要使用ENQUOTE_NAME。ENQUOTE_NAME需要两个参数,一个是需要enquote的变量,另一个为是否转换为大写。现在,对于我们的procedure,应该使用ENQUOTE_NAME(p_table, FALSE),保证Table One不被转换为"TABLE ONE"。

这是我们的最终解决方案。但需要注意的是,由于使用了ENQUOTE_NAME,对于我们的procedure来说,table和constraint的名字对大小写敏感。如果名为table_1,则必须传入TABLE_1,否则会执行错误。

修改后的代码如下:

Sql代码

CREATE OR REPLACE PROCEDURE Disable_Constraint  ( p_constraint_name  VARCHAR2, p_table VARCHAR2 )

AUTHID CURRENT_USER

AS

p_schema VARCHAR2(32) := SYS.DBMS_ASSERT.ENQUOTE_NAME(USER, FALSE);

sql_stmt VARCHAR2(2000);

safe_table VARCHAR2(32);

safe_constraint VARCHAR2(32);

BEGIN

safe_table := SYS.DBMS_ASSERT.ENQUOTE_NAME(p_table, FALSE);

safe_constraint := SYS.DBMS_ASSERT.ENQUOTE_NAME(p_constraint_name, FALSE);

sql_stmt := 'ALTER TABLE '

|| p_schema

|| '.'

|| safe_table

|| ' DISABLE CONSTRAINT '

|| safe_constraint ;

EXECUTE IMMEDIATE sql_stmt;

END;

/
 

【编辑推荐】

  1. Oracle性能诊断不能不知的秘籍
  2. 使用dtu远程连接Oracel 9i数据库的方法
  3. Windows2000服务器下安装Oracle9i与10g
  4. Oracle多表查询优化的代码示例
  5. Oracle更改的默认端口号剖析
责任编辑:佚名
相关推荐

2010-04-12 08:59:00

2010-12-20 16:04:30

2009-03-27 10:53:52

注入SQLMySQL

2010-09-14 16:00:16

2017-08-10 10:23:59

2009-12-16 17:58:18

2020-10-26 07:04:29

SQL注入mysql

2013-05-02 15:09:22

2017-05-05 11:31:34

2017-09-07 15:54:49

2011-10-19 10:47:56

2020-12-16 13:22:37

Web安全SQL工具

2010-09-27 11:17:31

2020-09-28 09:30:13

mybatis

2010-09-08 13:10:03

2014-11-27 09:31:26

2010-06-30 17:56:06

2010-11-01 17:22:44

2009-07-24 10:29:29

PL SQL编程规范

2010-10-22 15:18:18

SQL注入漏洞
点赞
收藏

51CTO技术栈公众号