SQL Injection - Oracle - Time Based

Remediation

1. Use built-in Object Data Models: Instead of directly passing user input to the back-end SQL server, use built-in Object Data Models to gather and handle data. This helps to ensure that the input is properly sanitized and validated before being used in SQL queries.

2. Parameterized queries: Use parameterized queries in the language framework to construct SQL statements. This helps to prevent SQL injection by separating the SQL code from the user input. Here’s an example in Python using the cx_Oracle library:

   import cx_Oracle
   
   # Establish a connection to the Oracle database
   connection = cx_Oracle.connect("username", "password", "hostname:port/service_name")
   
   # Create a cursor object
   cursor = connection.cursor()
   
   # Use a parameterized query to retrieve data
   query = "SELECT * FROM users WHERE username = :username"
   cursor.execute(query, username="admin")
   
   # Fetch the results
   results = cursor.fetchall()
   
   # Close the cursor and connection
   cursor.close()
   connection.close()
   

3. Avoid string concatenation: Avoid directly concatenating user input with SQL statements in the code base. This can make the application vulnerable to SQL injection attacks. Instead, use parameterized queries or stored procedures to handle dynamic SQL statements.

About

Most SQL injection vulnerabilities occur when input from the user is not properly sanitized and is directly passed to the back-end SQL server. This allows attackers to manipulate the input and inject malicious SQL commands into the application.

Risks

SQL injection vulnerabilities can lead to various risks, including:

• Enumeration of column names: An attacker can use SQL injection to gather information about the database structure, such as the names of tables and columns. This information can be used for further attacks or unauthorized access.

• Data retrieval: By injecting malicious SQL commands, an attacker can retrieve sensitive data from the database, such as usernames, passwords, or other confidential information.

• Remote code execution: In some cases, SQL injection vulnerabilities can be exploited to execute arbitrary code on the server, leading to complete compromise of the application and potentially the underlying system.

Most StackHawk tests for SQL injection vulnerabilities are time-based. This means that the scanner tries to make the SQL server perform time-based actions and observes the response time of the application to detect potential SQL injection vulnerabilities.