Why can't sqlmap find an SQL injection in my code?

  • I installed XAMPP on my development PC, and started Apache HTTP server and MySQL.

    It comes with a test page "CD collection", with the following back-end PHP code:

    mysql_query("DELETE FROM cds WHERE id=".round($_REQUEST['id']));

    I'm not an expert in PHP, I'm guessing the round call is there to prevent SQL injection. So I removed it from the PHP code, leaving the following:

    mysql_query("DELETE FROM cds WHERE id=".$_REQUEST['id']);

    I verified that I can modify the query parameters in the URL to do whatever I like to the database, so the SQL injection vulnerability is definitely there.

    Now I'm trying to use sqlmap to find the SQL injection vulnerability. I run it like this:

    python sqlmap.py -u ""

    But it returns the following:

    [16:01:47] [WARNING] GET parameter 'id' is not injectable [16:01:47] [CRITICAL] all parameters are not injectable, try to increase --level/--risk values to perform more tests. Rerun without providing the --te chnique switch. Give it a go with the --text-only switch if the target page has a low percentage of textual content (~15.27% of page content is text)

    Any idea of what I may be doing wrong?

  • p____h

    p____h Correct answer

    9 years ago

    There is a huge probability, that your server doesn't display any errors/warnings. Sqlmap tries to inject sql inj.-like payloads and observes the webapp "state". As sqlmap hasn't got an access to your vulnerable code or DB content it could just only guess the potential vulnerability by observing webapp behaviour – in this case „visual” behaviour (no warnings/errors – no potential sql-inj.).

    However, sqlmap gave you pretty nice hint: try to increase level/risk values:

        python sqlmap.py -u "http://..." --level=3 --risk=3

    after that change you will increase the amount of payloads (sent to your webapp) and you will find blind sql.inj!. It means that on level 3 (and --risk=3) sqlmap doesn't check only „visible” effects. It uses some time-taking operation [BENCHMARK()] which delays server response if sql. Inj. occurs.

    Thanks for the answer, it turns out that increasing the level and risk did work. Apologies to @D.W. who did ask me this earlier, but it appeared I wasn't running it properly.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM