Now that we’ve covered general concepts of SQL for SQL injections, and we’ve learned the basics of powerful SQL injection techniques, let’s gather SQL injection cheat sheets and references that will prove to be very useful throughout the rest of our series.
Because there are differences in syntax, structure, and available functions depending on the Database Management System (DBMS) that an application is using, we have to learn their various quirks in order to effectively perform SQL injections. But, most of us are not experts in every DBMS out there, and it takes time to build up that kind of knowledge.
Luckily, many cheat sheets and reference materials exist, so let’s take a look at a few of them that we can continuously reference. If you find any other good ones, please share with us in the comments below!
By the way, these are lists that I found just by searching, so no paywalls or anything, just simple free resources to get us started.
- Getting started finding a vulnerable parameter
- Master list
- General list
- UNION attacks
- Info gathering
- Blind injections
- General SQL tips & tricks
- Juice Shop hints
Getting started finding a vulnerable parameter
As we mentioned in the prior post, one of the first steps we will need to take to test an application and database for SQL injection vulnerability is to try to get any kind of non-expected response.
Think of this as prodding defenses to see if there are any weaknesses. This first cheat sheet we will look at includes some helpful inputs for that very purpose. Let’s take a closer look!
‘ or 1=1
‘ or 1=0
‘ and 1=1
‘ or sleep(2) and 1=1#
‘ or sleep(2)#
- Also uses
#which is for comments, essentially causing SQL to ignore anything that would come after our injection
- Might also try
- Also uses
Union and time-delay
‘ union select sleep(2)#
If you don’t remember how UNION works, check out our SQL primer post.
If one or more of these inputs work, then we can use that to our advantage. If none of those work, we can try others.
For example, further on the page, the author included payloads from a tool called SQLMap which we will take a look at in another post later on in the series. Those are some of the payloads the tool uses to test for vulnerabilities, so they are also inputs we can try to use manually.
Further down, there are other types of payloads we can try, and then there are tips on how to determine:
- The number of columns in the current table
- The available columns in tables
- Displaying database, column, and table names through the metadata table like we talked about
- and more
So this is a helpful cheat sheet as a starting point.
Another, more comprehensive list, that we will call our “Master List” is by Netsparker. I won’t go through all of it for the sake of time, but they include a Table of Contents, and they also label which statements work for which database management system, like MySQL, SQL Server, PostgreSQL, and Oracle, or other databases.
For example, and one very helpful trick that we will use constantly when performing SQL injections, is commenting out the rest of a query. But, different databases use different commenting syntax, so what works on one may not work on the other.
--, they put an (SM) next to it, meaning that it works for SQL Server & MySQL, and by the way it also works for SQLite, PostgreSQL, and Oracle.
On the other hand, the
# sign also works with MySQL, but it wouldn’t work with SQLite, as an example.
Let’s talk about a quick example of when you could use commenting for an SQL injection. Let’s say you try to log in as an admin user. If the app were vulnerable to this injection, you could type in the login input field:
and the SQL query would look like this:
SELECT * FROM members WHERE username='admin'-- AND password ='password'
-- comments out everything that comes after it, SQL will interpret it as:
SELECT * FROM members WHERE username='admin'
Which would log you in as the administrator user, assuming that ‘admin’ is a valid username. This trick completely ignores the fact that there should be a password.
Some of the information in that cheat sheet is outdated and may need to be verified, but it gives us a great head start and it’s helpful reference material.
Further down the page, they mention If Statements, which are a key part of performing Blind SQL injections, since we can run IF statements to trigger certain actions.
For example, with MySQL, a basic IF statement would look like this:
The ‘true’ statement would happen if
1=1 (which it always does), otherwise if the statement were false, it would return the ‘false’ part. This technique can be used to test vulnerabilities, or it can be used to extract information from the database.
As you can see in the cheat sheet, each DBMS has a slightly different syntax.
There is a lot more to this article, so feel free to take a look around!
Next, we have a general list of information by PortSwigger including:
- String concatenation
- Database version
- Database contents
- Conditional errors
- Batched (stacked) queries
- Time delays
- Conditional time delays
- DNS lookup
- DNS lookup with data exfiltration
Some of these tips have already been listed in other sheets we’ve looked at, but I found the format to be quite nice so I included it here.
One other very helpful cheat sheet by PortSwigger is specific to UNION attacks. I do recommend that you take some time reading through this reference since UNION attacks are important to know, but I will point a few things out.
Matching the number of columns between two tables
When performing a UNION attack, you have to match the number and data type of columns from the tables you are combining. That’s why it’s important to determine the number of columns that are being returned from the original query, and they list two methods of achieving that in this list.
- Inject a series of
ORDER BYclauses and increment the column index until an error or change in behavior occurs (that would mean you’ve exceeded the number of columns)
- Submit a series of
UNION SELECTpayloads with a different number of
NULLvalues until you get an error or change of behavior
Example 1 ' ORDER BY 1-- ' ORDER BY 2-- ' ORDER BY 3-- Example 2 ' UNION SELECT NULL-- ' UNION SELECT NULL,NULL-- ' UNION SELECT NULL,NULL,NULL--
The reason that
NULL is very helpful with
UNION attacks is because
NULL is convertible to every commonly used data type, so it maximizes our chances of success if we don’t know what each data type for each column is.
Using concatenation to retrieve multiple values in a single column
If you run into a situation where the legitimate query only returns a single column and you’re trying to extract multiple column’s worth of data, you can use the concatenation trick we saw in the previous cheat sheet to combine results into one column.
Their example given shows:
' UNION SELECT username || '~' || password FROM users--
In this case, we are combining usernames & passwords together, but separating them with a
~ so that we can easily separate them in the output that we receive after the fact.
- Username: admin
- Password hash: f4cfc757b94003dca21fabdb770bfb1f
We’ve already seen most of these techniques to gather information, but again, this is put together in a nice, referenceable format.
Same thing for Blind injections and conditional responses. While we’ve reviewed concepts of blind injections, this cheat sheet provides additional tips and tricks.
General SQL tips & tricks
For general SQL commands, tips, and tricks that contains helpful information not just for SQL injections, but also for general SQL usage.
OWASP Juice Shop Injections
Finally, as we prepare to launch hands-on attacks against safe & legal environments, I wanted to share this cheat sheet for OWASP Juice Shop injection attacks.
The OWASP Juice Shop is one of the environments we will be using throughout this series, and they provide helpful hints in the documentation to help us uncover, and then exploit, SQL injections in the application.
We’ve also created a blog post explaining the OWASP Juice Shop in more detail.
It lists out challenges which gives us helpful indications as to what’s possible in the application, and the difficulty level of achieving the various challenges.
So as you complete this lesson, be sure to spend some time reading through these references because in the next few posts, we will use knowledge from everything we’ve learned to this point in order to gather information and then exploit applications and databases.
With that, let’s make sure we bookmark these references and then complete this lesson to move on to the next!
SQL Injection Attacks Series
Continue learning about SQL Injection Attacks with our YouTube playlist:
If you prefer reading, check out our ebook: