我们判断这些方法是否可用:
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; / |