Sqlmap keeps an ongoing session file that it uses to track
results and where it is in various processes.
We'll clear our session and have sqlmap start from scratch by
adding the flush‑session option to are command line.
The level parameter controls a number of tests that sqlmap will use.
It'll also change where sqlmap will insert payloads.
By default, sqlmap will test all GET and POST query parameters.
At level two, sqlmap will test values and cookies,
and at level three, it includes values in the User‑Agent header.
The higher the level,
the better the chance of detecting more difficult injections.
Increasing the risk parameter will include payloads
that may have dangerous side effects.
For example,
setting the risk value to 2 will include heavy
time‑based queries in a list of tests.
Setting it to 3 will include payloads that contain OR injections.
Both of these may have side effects,
depending on the exact nature of the underlying query.
For instance,
an OR injection in a SQL updating statement may end up
updating all the entries in a table.
A time‑heavy injection may cause instability in
databases with inadequate configurations.
Be careful with these, and only use higher values after extra testing.
With that said, let's go for it and set the level to 5 and the risk to 30.
Sqlmap will now be testing with its full set of payloads.
Since we flushed a session file,
sqlmap doesn't remember our answers to these questions.
We'll run through them just like we did in the previous demo.
Comparing these results with the results from earlier, we see an added payload.
Sqlmap added a boolean‑based blind payload containing an OR clause to the
list of payloads that this SQL injection is vulnerable to.
Using sqlmap, we can perform an extensive test of our target application.
We can use the crawl option to find injection points that we
may have missed. Adjusting the level and risk parameters
will give us even more coverage.
This is something that I'd only do at the end of an assessment
and if I'm testing in a non‑production environment. We instruct
sqlmap to crawl the application using a crawl option and
specify how deep to go. Now,
instead of providing the URL with the query parameters and
specifying that we only want the id parameter tested, let's remove
the query parameters and the ‑p parameter.
We're removing these parameters since we want to
verify that our options are correct.
If they are, sqlmap should detect a form on the page and submit it for us.
When it submits the form,
it'll see the id query parameter and pick it up for testing.
We'll leave the other options just like they are.
I mentioned the form submission. By default, sqlmap will not
submit any forms during its crawl process.
We have to specify that we want that to happen by using the forms parameter.
Now be cautious with this as you may never know what is
exactly going on in the back end.
It's not uncommon, for instance,
to have a Contact Us form that is sending emails to someone.
The last thing you want is an irritated person on the phone
because they woke up to thousands of junk emails.
There's also another catch here.
During the crawl process, sqlmap is most likely going to hit a logout endpoint.
If it does, our session will end.
We can tell sqlmap to ignore the logout page by
using the crawl‑exclude parameter.
This parameter takes a regular expression for pages to ignore.
We'll add the logout page, as well as the security page to this exclusion list.
The security page has a form that changes the
security level that we used earlier.
We don't want the security level changing while we're performing a
scan. Even though we're specifying the security level in the
cookie, we'll exclude this page to be on the safe side. We'll say
no to checking the sitemap here.
If your application has one, sqlmap can parse it and
add the results to the crawl scope.
We'll stick with one thread here,
but you'll probably want to use more for real‑world testing.
Do we want to normalize crawling results?
The normalization process means that sqlmap will treat URLs
the same except for extra information.
For example,
if one URL has a slash at the end and another doesn't. Normalizing the paths
will make this the same URL instead of two. This is generally a good practice
to do this, so we'll go along with sqlmap here.
Here we have the option to save the list of URLs
that sqlmap identifies to a file.
This is very handy for testing and to make sure there's nothing
from the crawl that is being left out or that is there that
shouldn't be. So now sqlmap is going to confirm that you want
to test each form in URL.
We'll say no to testing these for right now so we can see
what the rest of the run looks like.
This output is worth reviewing to make sure there isn't anything
else we should exclude from our scan. For instance,
in the above output, there's the setup page.
This page offers the ability to reset the database.
If the database is reset, it will end our active session,
preventing us from finishing the scan. I would add this page to the
crawl‑exclude list before continuing with testing.
I take a careful and deliberate approach when using sqlmap during an assessment.
Sqlmap provides these checks to ensure that it is doing what we intend it to.
It's worth taking the extra time to streamline our
testing and reduce any side effects.