Securing PL/SQL Applications with DBMS_ASSERT

Over the past few years Oracle has fixed a large number of PL/SQL injection vulnerabilities in their database server product. The vulnerability arises due to procedures and functions accepting user input and performing no validation on it before passing off to be executed in an SQL query. By carefully crafting their input an attacker can inject nefarious SQL and gain complete control over the database server under the right circumstances; the right circumstances are provided by being able to inject into a PL/SQL procedure or function owned by a high privileged user such as SYS, SYSMAN, MDSYS, CTXSYS or WKSYS and which has not been defined with the AUTHID CURRENT_USER keyword.

To help combat this class of attack Oracle has introduced the DBMS_ASSERT PL/SQL package. Whilst integrated into Oracle 10g Version 2 from day one, the DBMS_ASSERT was introduced into 10g Version 1 as part of the October 2005 Critical Patch Update. As a security researcher, it is excellent to see Oracle finally making the right positive moves in the direction of greater security.

The DBMS_ASSERT package exports a number of functions that can be used to validate user input. There are seven functions available namely NOOP, SCHEMA_NAME, SQL_OBJECT_NAME, QUALIFIED_SQL_NAME, SIMPLE_SQL_NAME, ENQUOTE_NAME and ENQUOTE_LITERAL. Wherever your PL/SQL applications embed values, input or data in SQL statements which are then executed, these functions should be used to ensure that whatever's going into the query cannot be used inject arbitrary SQL. Even if the source of the data or value is considered as trusted Id recommend erring on the side of caution and going ahead and validating.

Unless you try something to which you have not already succeeded ~ Then you shall NEVER grow