injection/sql_injection

10 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Three SQL Injection attack classes

SQL Injection attacks are classified into three types: Inband (data extracted using the same channel as injection, presented directly in the web page), Out-of-band (data retrieved using a different channel such as email), and Inferential or Blind (no actual data transfer, tester reconstructs information by observing database server behavior).

Code review for SQL Injection detection

During code review, check that all database queries are done via prepared statements. If dynamic statements are used, verify that data is sanitized before being part of the statement. Auditors should look for uses of sp_execute, execute, or exec within SQL Server stored procedures, and similar functions for other database vendors.

Blind SQL Injection time delay technique

The time delay exploitation technique is useful for Blind SQL Injection where the outcome is unknown. An injected query with a conditional delay is sent; if true, the server response is delayed. The tester monitors response time to determine if the conditional is true. Different DBMSs require different implementations. Example: http://www.example.com/product.php?id=10 AND IF(version() like '5%', sleep(10), 'false'))-- where a 10-second delay indicates MySQL version 5.x.

Blind SQL Injection out-of-band technique

Out-of-band exploitation is useful for Blind SQL Injection situations. The technique uses DBMS functions to perform an out-of-band connection and deliver injected query results to the tester's server. Each DBMS has its own specific functions for this technique.

Prepared statements prevent SQL Injection

Prepared statements with parameterized queries ensure an attacker cannot change the intent of a query even if SQL commands are inserted. For example, if an attacker enters userID of 'tom' or '1'='1', a parameterized query looks for a username literally matching the entire string 'tom' or '1'='1' rather than executing as SQL logic.

Java PreparedStatement safe usage

Java's PreparedStatement implements parameterized queries safely. Example: String query = "SELECT account_balance FROM user_data WHERE user_name = ?"; PreparedStatement pstmt = connection.prepareStatement(query); pstmt.setString(1, custname); ResultSet results = pstmt.executeQuery();

Java CallableStatement for stored procedures

Java's CallableStatement implements the stored procedure interface. Example: CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}"); cs.setString(1, custname); ResultSet results = cs.executeQuery(); The sp_getAccountBalance stored procedure must be predefined in the database and implement the required functionality.

Stored procedures not always safe from SQL Injection

Stored procedures and prepared statements have equal effectiveness in preventing SQL Injection when implemented safely. 'Implemented safely' means the stored procedure does not include any unsafe dynamic SQL generation. Certain standard stored procedure programming constructs have the same effect as parameterized queries.

Allow-list validation for SQL query parts

Various parts of SQL queries are not legal locations for bind variables, including table names, column names, and sort order indicators (ASC or DESC). For these situations, input validation or query redesign is the appropriate defense. Parameter values should be mapped to legal/expected table or column names to ensure unvalidated user input does not end up in the query.

Escaping as last resort for SQL Injection

Escaping all user-supplied input should only be used as a last resort when prepared statements, stored procedures, and input validation are not feasible. This technique is frail compared to other defenses and cannot guarantee prevention of all SQL Injection in all situations. It is usually only recommended to retrofit legacy code when input validation is not cost effective.

Give your agent this brain