What is SQL Injection

SQL Injection — the process of injecting SQL language code within data requests that result in application backend database server either surrendering confidential data or cause the execution of malicious scripting content on the database that could result in a complete compromise of the host.

Understanding Second-Order Code Injection

Imagine a scenario wherein a malicious code injected into an application by an attacker which does not get immediately get executed in the application.

Yes, you read that right. It’s a familiar story and it usually goes like this, user-provided data becomes a threat when it is utilized by the application or any other application wherein the injected code provided by the attacker gets activated resulting in successful exploitation.

First -order and Second-order SQL Injection differ primarily in the way that the attacker can simply enter a malicious string and cause the modified code to be executed immediately.

See the difference?

The attacker injects into persistent storage (such as a table row) which is deemed as a trusted source. An attack is subsequently executed by another activity.

Image for post

Credit: portswigger.net

Testing Challenge

The attacking nature of common code injection allows an attacker to discover the vulnerability by observing the application response.

Testing for Second Order SQL Injection is slightly difficult because it requires the attacker to have the knowledge of backend operation of the application.

How can you beat that?

Automated web-application assessment tools are not adequate to identify these vulnerabilities. An automated tool is not smart enough to identify the change in application behavior in any of the subsequent responses caused by the malicious injection in one of the previous queries.

What makes an application vulnerable to Second-order SQL Injection

This kind of vulnerability happens because a good programmer maybe will patch his code to prevent SQL injections in forms where the user can input something BUT he will not do the same thing where a user doesn’t have any sort of interaction with the application database.

Exploit Scenario

A second-order SQL Injection, on the other hand, is a vulnerability exploitable in two different steps:

Firstly, we STORE a particular user-supplied input value in the DB and
Secondly, we use the stored value to exploit a vulnerability in a vulnerable function in the source code which constructs the dynamic query of the web application.

So let’s get down to business and look at how a vulnerable application could be exploited in more detail with the help of a hypothetical scenario:

Example 1

CREATE TABLE USERS ( userId serial PRIMARY KEY, firstName TEXT )

Suppose you have some SAFE code like this, receiving firstName from a form:

$firstname = someEscapeFunction($_POST[“firstName”]);

$SQL = “INSERT INTO USERS (firstname) VALUES (‘{$firstName }’);”;
someConnection->execute($SQL);

So far so good, assuming that someEscapeFunction() does a fine job. It isn’t possible to inject SQL. If I would now send my payload as a value for firstname, you wouldn’t mind:

Payload : bla’); DELETE FROM USERS; //

Now, suppose somebody on the same system wants to transport firstName from USERS to SOME, and does that like this:

$userid = 42; $SQL = “SELECT firstname FROM USERS WHERE (userId={$userid})”; $RS = con->fetchAll($SQL); $firstName = $RS[0][“firstName”];

And then inserts it into SOME table without escaping:

$SQL = “INSERT INTO SOME VALUES (‘{$firstName}’);”;

Malicious query becomes like this:

INSERT INTO SOME VALUES (‘ bla’); DELETE FROM USERS; //

At this point you realise that if the firstname contains some delete command, it will still be executed.

#owasp #hacking #cybersecurity #sql-injection #vulnerability #sql