Cheat sheets and references

Slides used in this lesson

Because there are differences in syntax, structure, and available functions depending on the 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 out there to give us a help, so let’s take a look at a few of them that we can continuously reference.

By the way, these are lists that I’ve 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

https://github.com/AdmiralGaust/SQL-Injection-cheat-sheet

As I mentioned in a prior lesson, 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.

The first cheat sheet we will look at includes some helpful inputs for that very purpose.

The first two parameters are:

• ‘ (single quote)
• “ (double quote)
  • Trying to cause errors
• ‘ or 1=1
• ‘ or 1=0
• ‘ and 1=1
  • Using boolean injections
• ‘ or sleep(2) and 1=1#
• ‘ or sleep(2)#
  • Use time-delay injections
  • Also uses # which is for comments, essentially causing SQL to ignore anything that would come after our injection
  • Might also try --
• ‘ union select sleep(2)#
  • Stacking both a union and time-delay injection

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, below, this author included payloads from a tool called SQLMap which we will take a look at in another lesson.

These 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.

Master List

https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/

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 dabases use different commenting syntax.

With - -, 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, # sign also works with MySQL.

So as you can see, this cheat sheet is not completely comprehensive and you have to verify some of the information, but it gives us a great head start and it’s helpful reference material.

An example of when you could use commenting for an SQL injection is listed below:

Let’s say you try to log in as an admin user. If the app were vulnerable to this injection, you could type:

admin'--

and the SQL query would look like this:

SELECT * FROM members WHERE username='admin'-- AND password ='password'Code language: JavaScript (javascript)

Since - - comments out everything that comes after it, SQL will interpret it as:

SELECT * FROM members WHERE username='admin'Code language: JavaScript (javascript)

Which would log you in as the administrator user.

Another example is using commenting syntax specific to MySQL which can be used to determine the version of MySQL being run.

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.

Such as using a boolean of 1=1, and causing the database to sleep for 5 seconds if it interprets that 1=1 statement. Then, if the database sleeps for 5 seconds, we know that it has a vulnerabilitiy.

However, if it doesn’t sleep for 5 seconds, then the database is not vulnerable to that specific attack.

In this case, each DBMS has slightly different syntax.

There is a lot more to this article, so feel free to take a look around!

General List

https://portswigger.net/web-security/sql-injection/cheat-sheet

Next, we have a general list of information by PortSwigger including tricks on how to perform string concatenation, which combines strings together.
Again we see tips on using comments.

We see tips on how to extract a database’s version, which again is helpful in figuring out vulnerabilities specific to that version.

We’ve seen most of the tips on this page, but I found the format to be quite nice so I included it here.

UNION attacks

https://portswigger.net/web-security/sql-injection/union-attacks

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, but I will point a few things out.

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 here:

1. Inject a series of ORDER BY clauses and increment the column index until an error or change in behavior occurs
2. Submit a series of UNION SELECT payloads with a different number of NULL values until you get an error or change of behavior

' ORDER BY 1--
' ORDER BY 2--
' ORDER BY 3--

' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL--Code language: PHP (php)

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.

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 previously to combine results into one column.

Their example given shows:

' UNION SELECT username || '~' || password FROM users--Code language: JavaScript (javascript)

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.

Information Gathering

https://portswigger.net/web-security/sql-injection/examining-the-database

We’ve already seen these techniques to gather information, but again, this is a put together in a helpful format.

Blind Injections

https://portswigger.net/web-security/sql-injection/blind

Same thing for Blind injections and conditional responses.

General SQL tips & tricks

https://sqlzoo.net/

Otherwise, I also found this list of 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

https://pwning.owasp-juice.shop/part2/injection.html

And 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 course, and they provide helpful hints throughout this documentation to help us uncover, and then exploit, SQL injections in the application.

It also lists out challenges which gives us helpful indications as to what’s possible in the application, and the difficulty level of achieving that challenge.

Conclusion

So as you complete this lesson, be sure to spend some time reading through these references because in the next few lessons, we will use knowledge from everything we’ve learned to this point in order to gather information and then exploit applications and databases.

By the way, if you’ve found or know of any other cheat sheets that could benefit the community, please share with us at Cybr.com/forums!

With that, let’s make sure we bookmark these references and then complete this lesson to move on to the next!