SQL Injection

SQL Injection

Overview

SQL injection (SQLi) is a vulnerability in which an application accepts input into an SQL statement and treats this input as part of the statement. Typically, SQLi allows a malicious attacker to view, modify or delete data that should not be able to be retrieved. An SQLi vulnerability was found for this host which allows an attacker to execute code and view data from the SQL service by submitting SQL queries.

An attacker could exploit this lack of input sanitization to exfiltrate database data and files, tamper with the data, or perform resource exhaustion. Depending on the database and how it is configured, an attacker could potentially remotely execute code on the server running the database.

Business Impact

Data exfiltration through a SQLi attack could lead to reputational damage or regulatory fines for the business due to an attacker’s unauthorized access to data. This could also result in reputational damage for the business through the impact to customers’ trust. The severity of the impact to the business is dependent on the sensitivity of the data being stored in, and transmitted by the application.

Steps to Reproduce

1. Using a browser, login to in-scope asset at: {{URL}}

2. Browse to account page

3. Modify ID token to add single quote

4. View error which states 'SQL Syntax Error'

5. Replace ID value with the following payload:

{{payload}}

Proof of Concept (PoC)

The screenshot below demonstrates the SQLi being executed:

{{screenshot}}

The following database name and database user have been retrieved to demonstrate that the PoC exfiltrates valid database information:

{{database name/database user}}

Guidance

For an SQL Injection vulnerability, please include specific non-Personally Identifiable Information (PII) discovered in the database, such as Database Version, a listing of database tables, or an injected 'sleep' payload.

Demonstrating access to data other than the database version or database tables is not permitted without explicit permission from the program. Do not access Personally Identifiable Information (PII).

You may present your evidence as output from a tool such as SQLMap, unless the program forbids the use of these tools, and it may be in the format of terminal output, screenshots.

Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full proof-of-concept. a

Recommendation(s)

To prevent SQL injection attacks, it is recommended that queries use parameterized queries instead of string concatenation. For example, the following is a good statement:

txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = @0";

Whereas the following is a bad statement:

txtSQL = "SELECT * FROM Users WHERE getRequestString("UserId") = @0";

Using parameterized queries allows for code and data to be distinguished by the database regardless of input. However, all inputs should go through a validation process which only allows content to be processed by the database if it passes validation.

For more information, view the following resources:

• https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

• https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html

• https://www.w3schools.com/sql/sql_injection.asp