6 sqlmap cheat sheets to help you find SQL injections

sqlmap cheat sheets

Here’s a collection of cheat sheets we created to go along with our course: The Practical Guide to sqlmap for SQL Injection. If you find these helpful, please share them on social media and tag @cybrcom. Thanks!!

1. sqlmap’s source code structure and how to navigate it

The main repository: https://github.com/sqlmapproject/sqlmap

sqlmap repository structure

Let’s start from the bottom up:

sqlmapapi.py: sqlmap can be used as an API, which is something we’ll look at later in this course, but this serves as the entry point to enable and control our API

sqlmap.py: this, on the other hand, is the entry point for using sqlmap itself (python sqlmap.py -h)

sqlmap.conf: this is the configuration file for sqlmap’s options, so this is where we can modify some of sqlmap’s default configuration values in a more permanent way than typing them out in the terminal each time we issue a command

Next we have README, LICENSE, Travis CI (Continuous Integration), pylint code analysis file, and git files

thirdparty: this is where we can see the 3rd party tools needed for certain sqlmap functionality (ie: identywaf used to identify WAFs)

tamper: these are our tamper scripts, which are used to evade security controls (such as WAFs, IPSs, etc). There are over 60 scripts included by default, but we can also add our own

plugins: these are generic and DBMS-specific sets of plugins which are used by sqlmap to connect, fingerprint, enumerate, takover, etc… so these are very important functions

lib: another set of really important functions is in /lib. These are the libraries used by sqlmap, and it contains controller functions, core functions, parse functions, request functions, takeover functions, techniques functions (blind, dns, error, union), and utils (utilities) functions

extra: extra contains additional functionality that doesn’t quite fit in lib or plugins. For example, there is a vulnserver that we can use to test sqlmap functionality. There’s also a cloak script that can be used to encrypt and compress binary files in order to evade anti viruses. When using backdoors through sqlmap, sqlmap automatically takes care of that for you. But if you needed to manually cloak backdoors or other files that could be blocked by detection software, you could manually use cloak.py.

doc: this contains general files about sqlmap’s authors, its changelog, a thanks file for contributors, a list of third parties and their licenses, copyrights, etc, and translations for different languages other than english.

data: finally, we have data which contains a lot of templates and text documents that sqlmap uses extensively during its operations.

  • html is simply a demo page
  • procs contains SQL snippets used on target systems, and so they’re separated by DBMS
  • shell contains backdoor and stager shell scripts, useful for the takeover phase
  • txt contains common columns, tables, files, outputs, keywords, user-agents, and wordlists, all useful for brute-force operations, fingerprinting, bypassing basic security controls, and masking sqlmap’s identity
  • udf stands for user-defined functions, and this contains user-defined function binary files which can be used in the takeover phase to try and create our own functions in the target DBMS, which could help us assume control over that database.
  • xml is where you will find payloads for each technique. You will also find something called banner which sqlmap uses to identify which DBMS we’re dealing with, and more specifically, what versions are installed. These files also help identify what webserver is in place, and what languages as well as settings power the application(s) that we’re targeting. We also have:
    • boundaries.xml: contains a list of boundaries that are used in SQL queries
    • errors.xml: contains known error messages separated by DBMS
    • queries.xml: contains the correct syntax for each DBMS for various operations (ie: cast, length, isnull, delimiter, etc)

.github is just a convention folder used to place GitHub related information inside of it, like the Code of Conduct, Contribution guidelines, how to donate to the project, and the format to follow for opening bug reports or feature requests.

All of this data, all of those functions, and all of those configuration files serve a purpose. They’re there to give sqlmap its functionality. Understanding how its structured and how it works together is important for a number of reasons:

  1. As you become a more advanced user of sqlmap, you can extend its functionality. You can add more tamper scripts. You can change payloads. You can change default configurations, etc…
  2. If you run across an issue, you can try to troubleshoot yourself before opening an issue ticket, and then if you find a solution, you can propose that solution to the authors of sqlmap
  3. As changes get pushed to sqlmap, and as you update your version, you can keep track of changes and get a better understanding of what’s been added, fixed, or removed

Now that we looked at the entire repo and how it’s structured, let’s narrow it down a bit more to some of the most useful directories.

2. Important and useful sqlmap directories

We already briefly mentioned most of these in the prior section, but let’s take a closer look.

/tamper/

This is where you’ll find tamper scripts, which are used primarily to bypass WAFs and evade security controls.

Using these scripts is simple, as you can use the --tamper option:

--tamper="random,appendnullbyte,between,base64encode"
Code language: JavaScript (javascript)

This would instruct sqlmap to use all of the scripts separated by commas.

/data/txt/

This directory contains text files that sqlmap uses quite extensively during its operations:

  • common-columns
  • common-files
  • common-outputs
  • common-tables
  • keywords
  • smalldict
  • user-agents
  • wordlists

These files are used for everything from randomizing user-agent header values, to brute-forcing common column/file/table names, to guessing values for optimization.

You can add/remove values in these text files to your heart’s content.

/data/xml/payloads/

Curious to see what payloads sqlmap is using with its fingerprinting, enumeration, and takeover actions? This is where you’ll find them.

You can also add/remove payloads to your heart’s content.

The payloads are broken down by SQL injection technique:

  • boolean_blind
  • error_based
  • inline_query
  • stacked_queries
  • time_blind
  • union_query

/sqlmap.conf

This is the heart of sqlmap’s configuration. This file includes defaults for all options that need defaults to function, which means you can change these defaults either directly in this file, or via the terminal when you issue commands. Note that if you update a default in this conf file and then issue a different value via the terminal, the terminal value will take precedence.

/output/

This directory (usually located at /home/kali/.local/share/sqlmap/output/ if you use kali) is where results from sqlmap commands get stored which you can then explore and review. This is helpful when you need to share results in your reports and with developers, or if you want to perform additional analysis with 3rd party tools.

/history/

This directory (usually located at /home/kali/.local/share/sqlmap/history/ if you use kali) is where a SQL file gets generated and updated automatically by sqlmap as you issue commands. This essentially acts as a SQLite database which sqlmap can pull from to remember actions and results.

3. Test –levels and the impact they will have on your commands

This option decides what tests are performed and what tests aren’t performed. Let’s take a look at each level. (You can view payloads and which get triggered at which levels here.)

Level 1

This is the most basic level. sqlmap tests all GET and POST parameters. So regardless of the level that we choose, GET and POST parameters will always be tested by default, unless we specifically tell sqlmap not to.

Level 2

This level starts to also look at HTTP Cookie headers for SQL injection vulnerability.

We can also set cookie headers manually with --cookie=COOKIE, and we can use --param-exclude=EXCLUDE to bypass testing of certain cookies that match the given regular expression. We can also skip testing the Cookie headers by using --skip="cookies" or by using -p and not including cookies, even if we have this level enabled.

Examples:

sqlmap -u 'http://localhost:8440/" --level=2
sqlmap -u 'http://localhost:8440/" --level=2 --cookie="PHPSESSID=..." --param-exclude="PHPSESSID"
sqlmap -u 'http://localhost:8440/" --level=2 --cookie="PHPSESSID=..." --skip="cookies"
sqlmap -u 'http://localhost:8440/" --level=2 --cookie="PHPSESSID=..." -p "id"

Level 3

This level adds 2 new types of headers into the mix:

  • HTTP User-Agent header
  • HTTP Referer header

So by including this level, we are now testing for level 1 + level 2 + level 3.

Level 4

Level 4 seems to mostly implement more payloads for certain types of techniques, not necessarily new headers to test as compared to the other levels. For example:

Level 5

Finally, the highest level adds HTTP Host headers to test for SQL injections, as well as additional checks that we can also look for in each respective file.

One thing to keep in mind as you increase the levels, you will be increasing the number of requests, so if you set level 5, it will take significantly longer than if you choose level 2.

1: Always (<100 requests) 2: Try a bit harder (100-200 requests) 3: Good number of requests (200-500 requests) 4: Extensive test (500-1000 requests) 5: You have plenty of time (>1000 requests) Source: https://github.com/sqlmapproject/sqlmap/blob/master/data/xml/payloads/boolean_blind.xml#L21
Code language: HTTP (http)

4. –risk levels and the impact they will have on your commands

This option is similar to the --level option, but instead of dictating which headers and techniques to include in tests, this option looks at the risk levels.

Certain payloads that can be used to test for SQL injections can be destructive, because they can make modifications to databases and their entries, or they can take down databases by using resource-intensive queries. In some situations, that could be unacceptable since it would go outside of your testing scope or cause damage to a business. That’s why the authors of sqlmap added 3 levels.

Level 1

The first level, level 1, is intended to not cause any damage to databases and applications. It is the least offensive of all levels, so it’s a great place to start and is the default value.

Level 2

The 2nd level starts to add heavy time-based SQL injection queries. This can slow down the database or even potentially take it down. So be careful when using this risk level.

Level 3

The 3rd and final risk level adds OR based SQL injection tests. The reason this is in the highest risk level is because injecting OR payloads in certain queries can actually lead to updates of entries in database tables. Changing data in the database is never what you would want unless you are testing a throw-away environment and database. If you were to do that in a production environment, it could have disastrous consequences.

Only use this risk level if you know what you are doing, if you have explicit permissions, and if everyone is on the same page as to what this risk level does.

To get a comprehensive list of which payloads get executed at which risk levels, you can again take a look at all of the default payloads that sqlmap uses here. You can also add your own or make modifications, by the way, as you become a more advanced user of sqlmap, and to customize it to your needs or your client’s needs.

5. Verbosity levels for troubleshooting and to see what sqlmap is doing under the hood

Verbosity is used to control how much information sqlmap outputs when we’re using the tool. Some people may want more feedback from the tool to understand what’s going on and to debug, while others may find all of that extra information unnecessary.

By default, sqlmap uses a verbosity level of 1, which they define as Show Python tracebacks, errors, and critical messages from level 0, plus Show information and warning messages

So each of these levels stack on top of each other:

  • 0: Show only Python tracebacks, error and critical messages.
  • 1: Show also information and warning messages.
  • 2: Show also debug messages.
  • 3: Show also payloads injected.
  • 4: Show also HTTP requests.
  • 5: Show also HTTP response headers.
  • 6: Show also HTTP response page content.

Again, this is personal preference and it depends on what you’re doing, but level 2 is recommended for the detection and takeover phases.

Level 3 is recommended if you want to see what payloads are being injected and if you want to be able to share those payloads with your developers or your client in order to show them exactly what worked and what didn’t work.

Otherwise, levels 4 – 6 include HTTP requests information, response headers, and response page content, which would be a lot of information to sift through, so it’s not recommended unless you absolutely need to know that information.

One more note to take here is that you can also replace the numeric values for this option (ie: -v 4) with the corresponding number of vs (ie: -vvvv)

sqlmap -v 4 sqlmap -vvvv

You can also further filter results with grep:

sqlmap -v 4 | grep <filter>
Code language: HTML, XML (xml)

This option has to be used with other mandatory options, so if you try to set it by itself, it will give you an error and ask you to provide another mandatory option. This means you have to set the verbosity level for each of your commands, unless you set it in the sqlmap configuration file.

6. List of sqlmap’s Tamper scripts and what they do

sqlmap, by default, does very little to obfuscate payloads. Obfuscation, if you’re not familiar with the term already, is the act of hiding the true intention of our payload, which is a technique used to try and evade detection because it makes the payload deliberately difficult to understand. Just by looking at it, you wouldn’t be able to tell that it’s malicious.

This could be a problem if you’re trying to evade WAFs, IPSs, or other types of security controls and monitoring systems.

So in cases that you are trying to bypass input validation, or trying to slip through a Web Application Firewall, you may want to try and use --tamper options.

With this option, you can pass in a number of different values that are all separated by commas, and these values will load different tampering scripts. You can also create your own tamper scripts.

For example:

--tamper="between,randomcase"
Code language: JavaScript (javascript)

You can also use this command to list all of the tamper scripts in your terminal:

--list-tampers
Code language: PHP (php)

If we navigate to /tamper on GitHub, we’ll find a list of all the included tamper scripts. From there, we can click on one and see what the code does, since these are all python scripts. To make it a little bit easier, you can download the cheat sheet above which includes all of the available tamper scripts and a brief description of what each one does.

Want to learn more about sqlmap beyond cheat sheets?

Enroll in our Practical Guide to sqlmap for SQL Injection course

Found these cheat sheets helpful? Please consider sharing on social media and tagging us @cybrcom 🙂

Related Articles

Responses

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.