SQL Injection - Oracle - Time Based

Remediation

This finding is a time-based blind SQL injection in an Oracle database. The scanner did not use an error message or a visible change in the page. It injected a controllable Oracle sleep into the parameter, varied the requested delay, and confirmed the flaw because the response time scaled with the delay it asked for. The detection is blind, so input filtering alone does not fix the problem. The injected SQL still runs. You must change how the query is built.

1. Use bind variables (parameterized queries). Separate the SQL code from the user data, so the input is always a value and never SQL. In Oracle, use bind variables (:name) with PreparedStatement (JDBC) or the equivalent in your framework. Example with Python and cx_Oracle:

   import cx_Oracle
   
   connection = cx_Oracle.connect("username", "password", "hostname:port/service_name")
   cursor = connection.cursor()
   
   query = "SELECT * FROM users WHERE username = :username"
   cursor.execute(query, username="admin")
   
   results = cursor.fetchall()
   cursor.close()
   connection.close()

2. Never concatenate user input into SQL. Do not build queries with string concatenation, and do not pass user input to EXECUTE IMMEDIATE or dynamic PL/SQL. If you must build dynamic SQL, use a bind variable for every value, and check identifiers against an allow-list (for example with DBMS_ASSERT).

3. Remove the time-delay primitive (defense in depth). This test creates its delay with the Oracle package DBMS_PIPE. Revoke EXECUTE on DBMS_PIPE from PUBLIC and from the application schema. Also revoke EXECUTE on other packages that enable time-based or out-of-band attacks: DBMS_LOCK, UTL_INADDR, UTL_HTTP, UTL_TCP, and UTL_SMTP. This blocks the delay technique even if an injection point remains.

4. Apply least privilege. Run the application with a low-privileged Oracle account. Grant only the tables and views that the application needs. Do not use SYS, SYSTEM, or a DBA account. This does not remove the injection, but it limits the damage.

About

SQL injection happens when user input is not separated from the SQL command and reaches the Oracle server as code. This test detects the blind case with a dose-response timing check. The scanner injected a controllable delay (DBMS_PIPE.RECEIVE_MESSAGE) into the parameter, then varied the requested delay across several requests. It raised the alert only because the measured response time scaled with the requested delay, and a second confirmation pass matched. This method confirms a real injection and rejects a slow response that random load causes.

Risks

Blind SQL injection is as dangerous as any other SQL injection, even though the response shows no error or data. The risks include:

• Data theft one value at a time: An attacker reads any data the database user can reach by asking true or false questions and measuring the response time.
• Data change and logic bypass: An attacker reads, changes, or deletes data, or bypasses application logic.
• Server compromise: On an over-privileged or misconfigured database, an attacker can reach the file system, the network, or run commands, which can lead to full compromise.