The Database Hacker's Handbook: Defending Database Servers

Injecting into DELETE, INSERT, and UPDATE Statements

Injecting into DELETE, INSERT, and UPDATE statements gives attackers much more flexibility than injecting into SELECT statements in terms of what actions they can take. Remembering that no DDL or DML statements can be performed from within a SELECT statement without the use of AUTONOMOUS_TRANSACTION, the same is not true of DELETE, INSERT, and UPDATE statements. Well, half true. No DDL statements can be executed but DML statements can. This essentially means that when injecting into either a DELETE, INSERT, or UPDATE statement, an attacker can use any of DELETE, INSERT, or UPDATE queries to manipulate any table the PL/SQL definer has access to and not just the table the original query is manipulating. For example, assume a PL/SQL program INSERTs into table FOO and it is vulnerable to SQL injection. An attacker can inject into this PL/SQL program a function that DELETEs from table BAR.

Injecting into INSERT Statements

Before playing around with INSERT statements let's create a table to play with:

CREATE TABLE EMPLOYEES (EMP_NAME VARCHAR(50));

Consider the following PL/SQL procedure:

CREATE OR REPLACE PROCEDURE NEW_EMP(P_NAME VARCHAR2) AS
STMT VARCHAR2(200);
BEGIN

STMT :=‘INSERT INTO EMPLOYEES (EMP_NAME) VALUES (‘’’ || P_NAME || ‘’‘)’;
EXECUTE IMMEDIATE STMT;
END;
/

This procedure takes as its argument the name of a new employee. This is then placed into the STMT buffer, which is then executed with EXECUTE IMMEDIATE. All fairly ...