The Oracle® Hacker's Handbook: Hacking and Defending Oracle

5.8. Auditing PL/SQL Code

When auditing PL/SQL code for SQL injection vulnerabilities, anywhere that a dynamic query is being built that uses user input is potentially vulnerable to SQL injection, so it's a good place to look. Another, often overlooked, area is data selected from tables being embedded in queries. The calls of interest to look out for include the following:

EXECUTE IMMEDIATE— EXECUTE IMMEDIATE executes a SQL statement.

DBMS_SQL— The DBMS_SQL package can be used to execute a SQL statement. The statement is first parsed with a call to the PARSE function, which creates a cursor. The cursor is then passed to the EXECUTE procedure and the query is executed. Often, you'll find the call to PARSE without the EXECUTE following it. The reason for this is to check whether an SQL query is syntactically correct without actually executing it. This can often lead to false positives when looking for SQL injection bugs. For example, the DBMS_UTILITY.NAME_TOKENIZE procedure calls DBMS_SQL.PARSE, and this procedure is called from various default packages:

SQL>  declare
  2   A varchar2(200);
  3   B varchar2(200);
  4   C varchar2(200);
  5   D varchar2(200);

6   N number;
  7   begin
  8  dbms_utility.name_tokenize('NA''ME',A,B,C,D,N);
  9  end;
  10  /
  declare
   *
ERROR at line 1:
ORA-01756: quoted string not properly terminated
ORA-06512: at "SYS.DBMS_UTILITY", line 79
ORA-06512: at line 8

DBMS_SYS_SQL— The DBMS_SYS_SQL package has a special function called PARSE_AS_USER. This function takes a userid as one of ...