Safe SQLi wordlist

[AndreaFiocchi]

Feature Request:
Create a wordlist for safe SQL Injection fuzzing that doesn't contain dangerous parameters

Additional context:
Logical operators like ' OR 1=1 can be dangerous if successfully injected on a DELETE or UPDATE query.

[molangning]

Some example queries would be helpful, like DELETE %inject%

[AndreaFiocchi]

UPDATE users SET email = "new@ema.il" WHERE id = %inject%
Injecting OR 1=1 hits every record in the table

Now, this is a fringe case and bad example as id is very unlikely controllable by user input but it gets the point.
Injecting logical operators can result in damage if said operator controls which record(s) the query is hitting.

Another example is commenting out the rest of the query.
In the previous example if email is injectable something like x" -- can unintentionally wreck havoc
UPDATE users SET email = "x" -- " WHERE id = 1

[ItsIgnacioPortal]

Relevant article: https://tcm-sec.com/avoid-or-1-equals-1-in-sql-injections/

[ItsIgnacioPortal]

As discussed in issue sqlmapproject/sqlmap#3688 in the SQLMap project, the risk level of dangerous SQL queries can be reduced by adding a LIMIT 1 suffix to SQL queries. This would limit the impact of any given SQL query to just 1 row.

[ItsIgnacioPortal]

SQLmap uses a --risk parameter to select the level of risk for the queries it's going to run, where:

https://github.com/sqlmapproject/sqlmap/blob/5a097c74c07ed6b68243c6b2593f91f7fa5332d1/sqlmap.conf#L346-L351

# Risk of tests to perform.
# Note: boolean-based blind SQL injection tests with AND are considered
# risk 1, with OR are considered risk 3.
# Valid: Integer between 1 and 3
# Default: 1
risk = 1

[ItsIgnacioPortal]

From the SQLmap docs:

---

Risk

Option: --risk

This option requires an argument which specifies the risk of tests to perform. There are three risk values. The default value is 1 which is innocuous for the majority of SQL injection points. Risk value 2 adds to the default level the tests for heavy query time-based SQL injections and value 3 adds also OR-based SQL injection tests.

In some instances, like a SQL injection in an UPDATE statement, injecting an OR-based payload can lead to an update of all the entries of the table, which is certainly not what the attacker wants. For this reason and others this option has been introduced: the user has control over which payloads get tested, the user can arbitrarily choose to use also potentially dangerous ones. As per the previous option, the payloads used by sqlmap are specified in the textual file xml/payloads.xml and you are free to edit and add your owns.

[ItsIgnacioPortal]

All of the payloads used by SQLmap, along with their respective risk-level are available at https://github.com/sqlmapproject/sqlmap/tree/5a097c74c07ed6b68243c6b2593f91f7fa5332d1/data/xml/payloads.

Because the SQLMap payloads list is constantly updating, a CI/CD pipeline should be made so those files are pulled and processed into wordlists automatically. Ideally we would have a file structure like:

• Fuzzing/Databases/SQLi/
  • Safe payloads/ (Risk = 1)
    • boolean_blind.txt
    • error_based.txt
    • inline_query.txt
    • stacked_queries.txt
    • time_blind.txt
    • union_query.txt
  • Unsafe payloads/ (Risk = 2)
    • boolean_blind.txt
    • error_based.txt
    • inline_query.txt
    • stacked_queries.txt
    • time_blind.txt
    • union_query.txt
  • Dangerous payloads/ (Risk = 3)
    • boolean_blind.txt
    • error_based.txt
    • inline_query.txt
    • stacked_queries.txt
    • time_blind.txt
    • union_query.txt