SQL Injection (SQLi)
Introduction
SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database.
It generally allows an attacker to view data that they are not normally able to retrieve.
This might include data belonging to other users, or any other data that the application itself is able to access.
In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior.
In some situations, an attacker can escalate a SQL injection attack to compromise the underlying server or other back-end infrastructure, or perform a denial-of-service attack.
Useful Resources
Finding a SQLi attack vector
Whenever faced with user-input, you can check if the target is vulnerable to SQLi by using the following inputs Note that in some cases you may be facing a blind SQLi, which means that you won't be able to "see" any error messages
Take care when injecting the condition OR 1=1 into a SQL query. Even if it appears to be harmless in the context you're injecting into, it's common for applications to use data from a single request in multiple different queries. If your condition reaches an UPDATE or DELETE statement, for example, it can result in an accidental loss of data.
SQL Injection Filter Evasion - Unicode Normalization
Unicode normalization is a process that ensures different binary representations of characters are standardized to the same binary value. This process is crucial in dealing with strings in programming and data processing
You can find a great article here: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/
Depending on how the back-end/front-end is behaving when it receives weird unicode characters an attacker might be able to bypass protections and inject arbitrary characters.
You can use the following payloads to try and trigger a SQLi whenever you are facing any filters. Sometimes, unicode normalization even allows bypassing WAFs in place.
Other characters can be found at:
UNION-Based SQL Injection Payloads
SQL Injection Payloads Lists
SQLMap Basics
Second Order SQLi
Second-order SQL injection arises when user-supplied data is stored by the application and later incorporated into SQL queries in an unsafe way. To detect the vulnerability, it is normally necessary to submit suitable data in one location, and then use some other application function that processes the data in an unsafe way
One example of second order SQLi is the following i faced during a CTF challenge:
The target web application's registration form suffered from SQLi
After registering a user, a specific field inside the user profile showed the result of the SQL injection
To achieve a second-order SQLi with sqlmap i used the following:
sqlmap -r req --batch --dump --risk 3 --level 5 --second-req req2 --dbms=mysql --tamper=space2comment --dump
NoSQL Injection
NoSQL databases provide looser consistency restrictions than traditional SQL databases.
By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits.
Yet these databases are still potentially vulnerable to injection attacks, even if they aren't using the traditional SQL syntax.
Useful External Resources:
Last updated