5

For academical purposes I need to explode a blind sql injection on a form paramater which is sent using the POST method. The form is very simple, it just has an input text box where to introduce the name of a user and a submit button, the output produced just informs about the existence or not of the introduced user. The html code is:

<html>
<head>
      <title>User info</title>
</head>...

<p> Introduce an user to check if it's in the database </p>   
<form method="post">
      User <input type="text" value="" name="user">
      <input type="submit" value="Check!">
</form>
<hr>
</center>
</html>

I know that 'guest' is a valid user name (it returns true) and I've checked manually that it's vulnerable to blind sql injection by introducing guest' and '1'='1 (which return true), and guest' and '1' = '0, (which returns false). Once being sure that it's vulnerable I've tried to use sqlmap to explode the vulnerability using the following command:

# sqlmap -u  "http://foo.com/checkuserform" --method "POST" --data "user=guest" --dbms "mysql" -p "user"

But it seems not being able to explode the vulnerability:

...
    **[00:23:01] [WARNING] the web server responded with an HTTP error code (405) which could interfere with the results of the tests**
    [00:23:01] [INFO] testing if the target URL is stable
    [00:23:02] [INFO] target URL is stable
    [00:23:02] [WARNING] heuristic (basic) test shows that POST parameter 'user' might not be injectable
    ...
    **[00:23:18] [WARNING] POST parameter 'user' is not injectable**
    [00:23:18] [CRITICAL] all tested parameters appear to be not injectable. Try to increase '--level'/'--risk' values to perform more tests. Also, you can try to rerun by providing either a valid value for option '--string' (or '--regexp') If you suspect that there is some kind of protection mechanism involved (e.g. WAF) maybe you could retry with an option '--tamper' (e.g. '--tamper=space2comment')
    [00:23:18] [WARNING] HTTP error codes detected during run:
    405 (Method Not Allowed) - 175 times

A part of not being able to explode the vulnerability what surprises me is the HTTP 405 error,since I've forced the use of POST in the sqlmap command (and I'm not able to reproduce this error if I check it manually with a browser). I've also tried increasing the values of the level and risk parameters without succeed. Do you have any clue why it's happening?

Toni
  • 207
  • 1
  • 2
  • 8
  • try by adding --cookie='' with the sqlmap command, if the application uses any. – Krishna Pandey Dec 22 '15 at 10:48
  • Hi K.P., thanks for the comment, but the app is so simple that it doesn't even use cookies. I've also been playing with the --string param (specifying the text the always and only appears when the app returns true) and --regexp params, with no succeed. – Toni Dec 22 '15 at 10:58

1 Answers1

3

My preferred method of using SQLmap is to submit a request using a browser which is proxied through Burp, copy the request from Burp into a text file, then call sqlmap with the -r parameter pointing to the text file.

This ensures that the submission is going to the correct location, with the required headers and cookies.

In this case, I suspect that you are POSTing to the wrong location - from your description, it sounds like it may be making a Javascript call to a backend service and then providing an alert box or updating the content on the page. Using a proxy to observe this would allow you to check, even if the scripts on the page are obfuscated or excessively complex to allow for reasonable examination.

Matthew
  • 27,233
  • 7
  • 87
  • 101
  • 2
    Matthew, your solution worked fine, I captured the HTTP POST request with Burp, and I used the -r parameter instead or the -u, and it immediately detected the vulnerability. Thanks! – Toni Dec 22 '15 at 23:05
  • The form had two input fields, you were only using one for your sqlmap command, I suspect adding the submit value to your data might have fixed it. – wireghoul Mar 11 '22 at 04:22