Content is stored in databases, either relational database or non relational database. i.e SQL or NoSQL.

if its stored in SQL, there’s a category of vulnerabilities called SQLi. SQL Injection → meaning, queries made to the database directly.

SQL

SQL Cheat Sheet

SQLi can expose sensitive data (passwords, credit card details), allow unauthorized system access, and lead to significant security breaches.

Detection:

• single quote character ' and look for errors or other anomalies.
• SQL-specific syntax that evaluates to the base (original) value of the entry point, and to a different value, and look for systematic differences in the application responses.
• Boolean conditions, OR 1=1 and OR 1=2
• OAST payloads

Exploitation Varieties:

• vulnerabilities occur within the WHERE clause of a SELECT query

SQL injection vulnerabilities can occur at any location within the query, and within different query types. Some other common 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.

Basic SQL injection example labs:

[Retrieving hidden data](https://www.notion.so/Retrieving-hidden-data-c58af674af1d40dba5312c5aa6e0c211)

[Subverting application logic](https://www.notion.so/Subverting-application-logic-9f221f6c357f47e396c72d22b89dd994)

[UNION attacks](https://www.notion.so/UNION-attacks-5adcf5010f58477881e9cc74fa889390)

[Blind SQL injection](https://www.notion.so/Blind-SQL-injection-0a8972456dc5493fbfd7113da551f042)

First Order SQL injection → user inputs in the request and that input goes into a SQL query in an unsafe way.

Second-order SQL injection → user inputs data through the request, but it gets stored for future usecase. gets placed into a database. a stored SQLi.

the mindset behind is this that, devs know there’s a SQLi present and they are mitigating this vuln by placing it directly into a db. but when the data gets processed later, the query that was saved is still unsafe and thus devs made wrong judgement and SQLi is still there.

SQLi in different formats

• if the input is getting processed a SQL query then we can try SQLi, no matter if input is in XML or JSON, or any other format the input is going.

WAFs might also be in place, so for that. obfuscating the payloads is the best way.

install Hackvertor

• Lab - **SQL injection with filter bypass via XML encoding**

SQLi can be prevented mostly, using parameterised queries instead of adding stuff in the query. parameterized queries or "prepared statements"

• Lab - SQL Injection, simple case