# SQL Injection (SQLi)

## Vuln - SQL Injection (SQLi) <mark style="color:red;">Synack</mark>

## <mark style="color:yellow;">General SQLi Report Requirements</mark>

***

## <mark style="color:yellow;">**Full:**</mark>

* Write-ups that provide enough evidence to demonstrate and confirm the existence of the vulnerability and, by exploiting the vulnerability, show database information (db\_name, current\_user, hostname etc.) and table dumps with sensitive information obtained.
  \*
  * **Please note**, we do not need full table dumps. We just need you to show that some data can be extracted from a table. One row of table data is all that is required.

## <mark style="color:yellow;">**Partial:**</mark>

SQL Injection (SQLi) Partial\* (Last update: SS 17-May-2022)

These will only be accepted at VO discretion.  Evidence must be sufficient to prove SQLi exists even though full impact is not demonstrable.  Full impact is strongly encouraged.&#x20;

We require documented partial data extraction, please demonstrate two (or more) of the below:

* Exact DB version extracted from the DBMS
* Current user
* Current DB
* Table and/or Column names (note that brute force attacks should be carefully checked for false positives)
* Other (meta-)data being extracted (such as the length) will be accepted on a per-submission basis

Note: All the above must be retrieved via the SQLi, and not a fingerprint, heuristic or similar

Update 5/17/22 SS

A number of SQLi partial reports have been returned closed not valid from several clients due to new WAF configurations returning false positives in SQLmap. Updated partial requirement to two or more of the following for partial SQLi.&#x20;

In addition, please try to add supporting documentation of two or more of the below criteria:

* Boolean evaluations (e.g. \`1=1\` vs \`1=2\`)
* Short \`Sleep\`/\`WAITFORDELAY\`/etc. commands being correctly evaluated
* SQLMap confirming the issue, with an injection type (a heuristics check does not meet this requirement). Please place SQLMap's detection in the Vulnerable HTTP Request section.

## <mark style="color:yellow;">**BOTH:**</mark>

* HTTP requests where payloads are sent are required
* Screenshots of collected evidence
* Commands used for tools, such as SQLMap
* Include any PoC code if the attack is automated
* If authentication is required, attach the credentials used in your first step

***

## <mark style="color:red;">Template Contents</mark>

***

## <mark style="color:yellow;">**Title**</mark>

Full (or Partial) SQL Injection at {path}

***

## <mark style="color:yellow;">**Description**</mark>

An SQL Injection vulnerability is present at {path} in the {name of param} parameter. SQL Injection vulnerabilities are a type of injection attack where user supplied input is leveraged by a malicious user to escape the context of a database query. This allows an arbitrary injected SQL statement to be passed to the backend database for evaluation and execution. The severity of SQLi is similar in many ways to remote code execution since an attacker achieves execution of arbitrary database commands.

***

## <mark style="color:yellow;">**Impact**</mark>

#### <mark style="color:red;">An attacker can inject arbitrary queries to be executed by the backend database which could enable an attacker to:</mark>

* Extract all sensitive data from the databases
* Extract usernames and passwords for account takeovers
* Automate insert statements to corrupt database data
* Escape to the underlying OS to execute arbitrary code and take over the host server
* Create legitimate user credentials for persistence
* Gather data for lateral movement
* Pass the backend database administrative commands, such as drop tables, or shutdown the SQL instance

#### <mark style="color:red;">Performing any of the above actions can lead to significant business impacts, undermining the confidentiality and integrity of an application and leading to:</mark>

* Negative effects on client relations
* Disruption of sales or other critical functionality
* Loss of confidentiality and integrity of client data
* Loss of user confidence in the application
* Costly data breaches

***

## <mark style="color:yellow;">**Recommended Fix**</mark>

#### <mark style="color:red;">The following may help remediate the vulnerability:</mark>

* Implement parameterized queries
* Use stored procedures
* Sanitize user supplied input to the vulnerable parameters
* Whitelist allowed specials characters
* Consider removing any web facing administrative assets
* Use the role based access control of least privilege for the user account running the database instance

#### Additional information on preventing SQL injection is available from [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)

***
