Stored SQLi

Second Order SQLi or Stored SQLi

Here the SQL query executed by the threat actor does not immediately show a result, instead it is stored and is used in a different part of the target probably after some processing.

Stored SQLi also bypasses the frontend input validation systems because they only occur at the point of initial data entry. The malicious payload does not inject at the entry point hence it has the tendency to get overlooked.

TryHackme Lab

Below are the notes from a lab I solved which demonstrated the use of Stored SQLi.

There was a webpage as follows.

Here the user could store information about a book and the data would show up below which was stored in a database.

The PHP source code running in the backend of this application and the SQL query used was explained in the room. The table name was books and ssn was the ID. Hence all the queries executed regarding adding or modifying data were based on ssn.

The first payload was as follows.

1'; update books set book_name = "compromised"; --

Here the apostrophe acts as an escaping character to exit the previous SQL query. The UPDATE statement is the malicious one where we are renaming all books to compromised. The dashes are used to comment out remainder of the query. The payload was entered in the SSN field

Upon clicking the Add Book button the query was successfully stored in the database as was shown. Next, to trigger the injection I navigated to the update page where the user could update the book details.

Here for the malicious query, I clicked on update and all the books were renamed to compromised.

Hence this was one example of Stored SQLi in action. Next, I dropped a table named hello using this method.

The following payload was used.

123'; drop table hello; -- 

And the table was dropped too.