Automatic SQL injection and database takeover tool
Go to file
Timo Boettcher 4f84215eda Work around PostgreSQL query optimizer for error
Sadly, the mechanism triggering the error using CAST to integer on a
string did not work for me. This is probably caused by PostgreSQL
optimizing the query as described in
https://www.postgresql.org/docs/9.6/static/functions-conditional.html :

    "Note: As described in Section 4.2.14, there are various situations
    in which subexpressions of an expression are evaluated at different
    times, so that the principle that "CASE evaluates only necessary
    subexpressions" is not ironclad. For example a constant 1/0
    subexpression will usually result in a division-by-zero failure at
    planning time, even if it's within a CASE arm that would never be
    entered at run time."

My trivial test case for causing/not causing an error based on a
condition was:
------------------------------------------------------------------------
mytestdb=> SELECT CASE WHEN (1=1) THEN 1/1 ELSE 1/0 END;
    1

mytestdb=> SELECT CASE WHEN (1=2) THEN 1/1 ELSE 1/0 END;
ERROR:  division by zero
------------------------------------------------------------------------
As expected, the division by zero error is only triggered when the
condition is not met.

Second, dynamic, testcase (the first character of VERSION() has ASCII
code 80, so last condition is expected to return true):
------------------------------------------------------------------------
mytestdb=> SELECT ASCII(SUBSTRING((COALESCE(CAST(VERSION() AS CHARACTER(10000)),(CHR(32))))::text FROM 1 FOR 1));
    80
(1 row)
mytestdb=>  SELECT (CASE WHEN (ASCII(SUBSTRING((COALESCE(CAST(VERSION() AS CHARACTER(10000)),(CHR(32))))::text FROM 1 FOR 1))>126) THEN 1 ELSE 2/0 END) IS NULL;
ERROR:  division by zero
mytestdb=>  SELECT (CASE WHEN (ASCII(SUBSTRING((COALESCE(CAST(VERSION() AS CHARACTER(10000)),(CHR(32))))::text FROM 1 FOR 1))>26) THEN 1 ELSE 2/0 END) IS NULL;
ERROR:  division by zero
------------------------------------------------------------------------
However, the ELSE part is evaluated both when the condition is true and
when it is not true, as described in the documentation cited above.

This can be worked around by using an error that can not be detected by
static analysis (length of version() is about 100, so last condition is
expected to return true):
------------------------------------------------------------------------
mytestdb=> SELECT (CASE WHEN (char_length(version())<80) THEN (1/(char_length(substring(version(),1,1))-1)) ELSE 2 END);
    2

mytestdb=> SELECT (CASE WHEN (char_length(version())>80) THEN (1/(char_length(substring(version(),1,1))-1)) ELSE 2 END);
ERROR:  division by zero
------------------------------------------------------------------------
While we know that substring(X, 1, 1) will return 1 for any non-empty
string, the database engine is probably not able to optimize that away
based on the slight chance that VERSION() may return an empty string.

This has been used successfully on PostgreSQL 9.6.
2017-10-06 00:03:22 +02:00
doc Minor update related to the #2695 2017-09-14 13:28:24 +02:00
extra Minor just in case update 2017-08-04 13:59:15 +02:00
lib Minor update for #2731 (--smoke-test failed) 2017-10-04 14:02:47 +02:00
plugins Initial support for #2709 (more work to be done) 2017-09-21 14:35:24 +02:00
procs Minor update 2016-05-30 01:29:40 +02:00
shell Minor consistency update 2017-04-18 14:02:25 +02:00
tamper Minor update for #2731 (--smoke-test failed) 2017-10-04 14:02:47 +02:00
thirdparty Reverting back the bottle.py revision because of numerous Python 2.6 incompatibilities 2017-04-07 15:10:28 +02:00
txt Minor update for #2731 (--smoke-test failed) 2017-10-04 14:02:47 +02:00
udf Stripping PostgreSQL .so files for size issues (Issue #2173) 2016-09-23 13:52:57 +02:00
waf Minor touch for internal re-hashing purposes 2017-10-02 16:32:37 +02:00
xml Work around PostgreSQL query optimizer for error 2017-10-06 00:03:22 +02:00
.gitattributes Update regarding the #2467 2017-04-10 16:44:12 +02:00
.gitignore Taking couple of suggestions from #2417 2017-02-27 22:03:15 +01:00
.travis.yml Adding support for Travis CI 2016-02-29 00:04:31 +01:00
ISSUE_TEMPLATE.md Implementation for an Issue #2221 2016-10-11 17:33:36 +02:00
README.md Minor update related to the #2695 2017-09-14 13:28:24 +02:00
sqlmap.conf Initial support for #2709 (more work to be done) 2017-09-21 14:35:24 +02:00
sqlmap.py Minor patch 2017-07-28 00:00:09 +02:00
sqlmapapi.py Fixes #2691 2017-09-09 22:27:40 +02:00

sqlmap

Build Status Python 2.6|2.7 License Twitter

sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. It comes with a powerful detection engine, many niche features for the ultimate penetration tester and a broad range of switches lasting from database fingerprinting, over data fetching from the database, to accessing the underlying file system and executing commands on the operating system via out-of-band connections.

Screenshots

Screenshot

You can visit the collection of screenshots demonstrating some of features on the wiki.

Installation

You can download the latest tarball by clicking here or latest zipball by clicking here.

Preferably, you can download sqlmap by cloning the Git repository:

git clone --depth 1 https://github.com/sqlmapproject/sqlmap.git sqlmap-dev

sqlmap works out of the box with Python version 2.6.x and 2.7.x on any platform.

Usage

To get a list of basic options and switches use:

python sqlmap.py -h

To get a list of all options and switches use:

python sqlmap.py -hh

You can find a sample run here. To get an overview of sqlmap capabilities, list of supported features and description of all options and switches, along with examples, you are advised to consult the user's manual.

Translations