6 sqlmap cheat sheets to help you find SQL injections
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
techniques functions (
utils (utilities) functions
extra: extra contains additional functionality that doesn’t quite fit in
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
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.
htmlis simply a demo page
procscontains SQL snippets used on target systems, and so they’re separated by DBMS
shellcontains backdoor and stager shell scripts, useful for the takeover phase
txtcontains 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
udfstands 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.
xmlis where you will find
payloadsfor each technique. You will also find something called
bannerwhich 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:
.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:
- 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…
- 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
- 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.
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
This would instruct sqlmap to use all of the scripts separated by commas.
This directory contains text files that sqlmap uses quite extensively during its operations:
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.
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:
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.
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.
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.)
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.
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.
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"
This level adds 2 new types of headers into the mix:
So by including this level, we are now testing for level 1 + level 2 + level 3.
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:
- Boolean-blind level 4 includes, as some examples (there are others):
- MySQL boolean-based blind – Parameter replace (MAKE_SET)
- MySQL boolean-based blind – Parameter replace (ELT)
- MySQL boolean-based blind – Parameter replace (bool*int)
- PostgreSQL boolean-based blind – Parameter replace (original value)
- Microsoft SQL Server/Sybase boolean-based blind – Parameter replace (original value)
- etc… (filter by
- Stacked queries
- Time blind
- Union query
- Inline query (only includes tests for levels 1-3)
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#L21Code 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.
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.
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.
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
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
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.
You can also use this command to list all of the tamper scripts in your terminal:
--list-tampersCode 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 🙂
very good explanations thank you i appreciate your effort
Thanks for the kind comment! Glad it helped 🙂
hello, thank you for your sharing, is that a problem if i share the images on Linkedin?
Not at all! Please do. Feel free to tag us too if you’d like! You can find me @ Christophe Limpalair