Attackers typically use an out-of-band SQLi when a direct query-response fails their goal. One method consists of submitting an SQL statement that creates a connection between the target database and a server the attacker controls. The attacker can then use this connection to collect data or otherwise control the database’s behavior. Like unsanitized inputs, this type of SQLi attack usually relies on the database not properly validating user inputs.
This example of an out-of-band SQLi uses two tables named Contacts and Users:
The Contacts table has the following fields:
Meanwhile the Users table includes:
Users log in to the database by entering their user name and password on a login page. The web server uses this information to construct a query that looks like the following:
select EmployeeID from Users where username=’jdoe1′ and password=’P@$$w0rd’;
The web server then executes this query, which returns the EmployeeID of the user with the user name of “jdoe1” and password is “P@$$w0rd”. Database servers typically return a status code as well to indicate that the query returned a result. If it did, the webserver logs the user into the database.
An attacker in an out-of-band SQLi attack can exploit the authentication process by submitting a password of “x’ or 1==1” resulting in the query:
Select EmployeeID from Users where username=’jdoe1′ and password=’x’ or 1==1;
In this case, the condition 1==1 is always true, so the web application authenticates the login attempt to jdoe1 even though the attacker didn’t provide the correct password for that account.
It may also be possible to obtain user data similarly, provided the web page can display data. In addition to the “‘x’ or 1==1” clause, the attacker can add a string like “UNION SELECT LastName, credit card number, security code from Contacts” to the password field. If the web application fails to validate the password data and executes the resulting query, it will return every user’s last name, credit card number, and security code.