Skip to content
Convenience wrapper around the sqlmap SQL injection tool to help with automation
Shell Python
Branch: master
Clone or download
Latest commit 8ee1346 Dec 15, 2017
Type Name Latest commit message Commit time
Failed to load latest commit information.
samples Initial commit Dec 15, 2017
.gitignore Initial commit Dec 15, 2017
LICENSE Initial commit Dec 15, 2017
NOTICE Initial commit Dec 15, 2017 Initial commit Dec 15, 2017
Vagrantfile Initial commit Dec 15, 2017
esm-7 Initial commit Dec 15, 2017 Initial commit Dec 15, 2017
login-cli Initial commit Dec 15, 2017
sqlmap-client Initial commit Dec 15, 2017
sqlmap-rest-api-scan-taskid-data.schema.json Initial commit Dec 15, 2017
sqlmap-rest-api-scan-taskid-log.schema.json Initial commit Dec 15, 2017

ESM-7 Overview

The goal of this tool is to simplify the automated testing of SQL Injection using existing tools. The sqlmap ( tool tests an application for SQL Injection vulnerabilities by fuzzing the application with known SQL injection attack signatures and monitoring the response. It also has exploitation capabilities that allow testers to use discovered vulnerabilities to obtain information from the underlying database or host system. However, it has over 170 different command switches that can be used, and the level of complexity can be overwhelming; thus the tool is often only used by experienced pen testers.

Such complexity can make it difficult for an organization to use the tool in automated security testing. However, such testing need not be comprehensive. Even executing baseline testing is a step in the right direction. To that end, we take a standard scenario for a rudimentary test and simplify the parameters necessary to run a SQL Injection test via sqlmap.

We recognized that much of the existing automated application security testing currently breaks down when targeting authenticated sites that require login.

In order to simplify authenticated testing, we include a utility (login-cli) that, when provided the proper login URL and request format, can provide sqlmap the authenticated session cookies generated by login.


At a high level, the execution can be summarized as: esm-7 [-v] [input-attack.conf] [output-file]

The following configuration parameters encapsulate the primary information necessary to execute a SQL Injection attack:

  • loginURL (optional): the URL for the login page. Alternatively, if a website does not require authentication but needs a legitimate existing session, this parameter can be used with any page from the application that will issue a new session cookie.
  • loginPOST (optional): the HTTP POST body to authenticate using the loginURL.
  • sqliURL: the URL to test for SQL Injection. Any parameters included in the URL are used to fuzz for SQL Injection, which means at least one parameter must be present in the URL or POST body.
  • sqliPOST (optional): the HTTP POST body to go along with the sqliURL (if applicable).
  • sqliParam (optional): the parameter to test. Solely used for optimization purposes to reduce the amount of fuzzing if the target parameter is already suspected (e.g., from unconfirmed DAST findings).
  • sqliDB (optional): the type of underlying DBMS used by the application. Solely used for optimization purposes to reduce the amount of fuzzing if the backend database is already known (e.g., from threat modeling information).

These configuration parameters are placed in a text file (see samples/sample-attack.conf) as name/value pairs in a property file. For example:


Using these configuration parameters, our wrapper script (esm-7) builds a JSON data structure that is sent to the sqlmap REST API to trigger a scan of the target URL. We use the following sqlmap options for a "typical" scan:

  • level: 5 the level of intensity used to scan with sqlmap.
  • getBanner: true we use this flag to trigger sqlmap to retrieve the database banner if there is a SQL Injection vulnerability; the banner then serves as "evidence" of the successful exploit.
  • batch: true ensures that sqlmap runs as if unattended.
  • answers: provides pre-populated answers to common sqlmap questions.
  • redirect to=N do not follow redirects (for performance reasons).
  • detect backend=N do not detect the backend database type (for performance reasons).
  • extended UNION=Y perform extended UNION testing.
  • extending provided risk=N do not extend testing (for performance reasons).
  • keep testing the others=N once one injection point is found, stop testing (for performance reasons).
  • data: $sqliPOST the HTTP POST body provided by config file (if present).
  • testParameter: $sqliParam the parameter provided by config file (if present).
  • dbms: $sqliDB the database type to target (if present).
  • cookie: [obtained via login-cli] the session cookie obtained via login-cli

These defaults were chosen as a reasonable baseline for demonstration purposes. An organization would tune the parameters to their desired level of rigor in the wrapper script.

The esm-7 wrapper script then generates JSON similar to the following:

  "level": 5,
  "getBanner": true,
  "batch": true,
  "answers": "redirect to=N,detect backend=N,extended UNION=Y,extending provided risk=N,keep testing the others=N",
  "cookie": "JSESSIONID=fd646fa4779399bf2a699de26ab00333",
  "url": ""

The resulting output from sqlmap is in JSON form (see samples/sample-attack.conf, samples/sample-esm7-error.conf, samples/sample-esm7-error2.conf, samples/sample-esm7-error3.conf, samples/sample-novulns-output.conf, samples/sample-esm7-output.conf). Consult the sqlmap JSON documentation for how to interpret this output.


The Quick Demo below uses the included Vagrantfile to set up a virtual machine with all the necessary components to use the esm-7 wrapper script as described above. However, the included shell script can also be used to install the necessary components on an Ubuntu 16.04.2 64-bit system.

The script installs python, copies over esm-7 and its related utilities, and downloads a known version of sqlmap. It then installs the sqlmapapi (the REST API executable) as a systemd service and starts it.

Quick Demo

As a demonstration, a Vagrantfile has been provided that installs the ESM-7 components and a sample target application (an old vulnerable version of dotCMS).


In order to execute the quick demo below, Vagrant and VirtualBox must be installed. Installers for these products are available from HashiCorp and Oracle respectively:


Use the following steps to manually execute an attack scenario for the ESM-7 tool:

  1. vagrant up
  2. vagrant ssh (or vagrant putty on Windows)
  3. esm-7 -v /opt/attack-scripts/esm7/samples/sample-attack.conf ~/esm7-output.json
  4. cat ~/esm7-output.json
You can’t perform that action at this time.