SQL注入，一个老掉牙的安全问题，有SQL的地方就会有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; / |
了解SQL注入的同学应该可以看出来，上面的procedure存在几个危险的变量：
1. p_table
2. p_constraint_name
3. p_schema
前两者容易发现，但为什还有p_schema呢？因为当前的USER名字也有可能是用户构造的危险字符串。好了，根据一般规律，我们应该遵循以下顺序进行修改：
1. 静态SQL。能不使用变量就不使用。
2. 绑定变量。与Java中的PreparedStatement类似，不把数据直接拼接在sql里，而是存入变量中，直接被数据库使用。
3. 检查变量的值。
显然，前两个方法对这个procedure不适用。我们只能使用最不爽的第3个方法。 好在对于PL/SQL来说，我们不用自己编写复杂的字符判断。Oracle有个SYS.DBMS_ASSERT包，提供了一些预置的function，如下：
| NOOP | No Operation. Returns string unchanged |
| SIMPLE_SQL_NAME | Verify that the input string is a simpleSQLname. |
| QUALIFIED_SQL_NAME | Verify that the input string is a qualifiedSQLname. |
| 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 qualifiedSQLidentifier of an existingSQLobject. |
| ENQUOTE_NAME | This function encloses a name in double quotes. |
| ENQUOTE_LITERAL | Add leading and trailing single quotes to a string literal. |
（请参考：http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28419/d_assert.htm）
在执行这些function时，如果传入的变量不满足规定的格式或条件，则会抛异常，从而保护我们自己的procedure不被SQL注入。
