5

I have a multipart form data where I am suspecting one of the multipart form fields (parameter named htmlbevt_id), to be vulnerable to SQLi. To test for the same I captured the request using Burp and saved it in a file, say myFile. Now on SQLMap I ran the following command:

sqlmap -r /root/Desktop/myFile -p htmlbevt_id

I get the following error message:

unable to connect to the target URL or proxy. sqlmap is going to retry the request

Am I missing something?

Am I required to login to the application before I run the above query? If so, how do I make SQL recognize the login? I mean is it that I need to login to the application from the browser and then run the above query (in which case I am not certain how exactly would SQLMap get to know that I am already logged into the application), or is there a different way to do this ?

Through some further googling i learned that --cookie needs to be used to replay the session authentication in SQLmap. Also since the request is a POST, some forums suggest the usage of --data as well, which I did. None of this has however been useful so far. I tried -v 6 to debug and see what was going wrong. And SQLmap reports "not a valid WebScarab log data". Not sure if this is the cause of the error.

Ok, a lot of the problem was solved. So now with the help of CO2 extension for Burp I was able to replay the entire traffic of the multipart POST request, along with all the session cookies, through SQLMap.

But now there is a different problem that I am facing. While I check for the application in the browser the session is still alive. But while scanning the SQLi injectable suspected parameter with SQLMap (I set verbose level to 3) I found that the server was returning a HTTP 400 session time out. What could be going wrong and is there a way to keep the session maintained while SQLMap does the scanning ?

  • If authentication in the application is tracked through cookies, after login copy the authentication cookie from the browser and use with with the sqlmap --cookie parameter. However, in this case you might not have the right capture. Make sure the captured request has GET or POST URL addresses as well as the Host: parameter. In some cases this might be due to the fact that the URL is accessible through proxy in browser but not from sqlmap. – void_in Sep 3 '14 at 18:23
  • Hi. I tried the --cookie switch and added all the cookies along with the above query. I also tried using --data as the request was a POST, hoping that it might help. But none of this has been helpful so far. I get the same error message still. – qre0ct Sep 4 '14 at 3:49
3

Are you able to replay the request in burp? (Send To Repeater => Go)

If so the easy way to get this into SQLMap is to use the CO2 extension which adds "Send to SQLMap" in the right-click menu this gives you the command-line to give to SQLMap with all your cookies and any data in the request.

  • yes. I am able to replay it back in the repeater. But CO2 is still under development. Are you sure it is stable and it gives the desired results? – qre0ct Sep 4 '14 at 4:49
  • More over I tried adding ver 4.0, 5.0 and 6.0 and none of them could be added as an extension in Burp free. There were some errors. – qre0ct Sep 4 '14 at 4:58
  • Ok, so this problem was solved. I was able to add CO2 v 6.0 to Burp free in Kali. The problem was an outdated version of Java on Kali. Updated Java to the latest version and the problem was fixed. – qre0ct Sep 4 '14 at 5:44
2

What it looks like you are trying to do is to run SQLmap on a static text file. The Request file is designed to capture requests to REPLAY against the server. Your command needs the proxy or URL you need to test.

  • Hi. To replay a request that originally deals with multipart form data, some of the forums suggest that the request be intercepted and saved as a static text file. And then the above query be run. Is there another way of achieving this ? – qre0ct Sep 4 '14 at 3:46
2

I am coming from your post from the null group. Glad you got almost closer to 0wn the system;)

in sqlmap's parlance LEVEL could mean two things. I am responding to your edit on Sept 4 12.58.

  • -v (1-6) is the verbosity level, which is used to output specify the amount of messages sqlmap spits to the screen.
  • --level (1-5) is the sqli detected level. If the specified level is more than 2, then sqlmap would try to inject. Increasing the level may sometimes cause HTTP 400 bad request because the HTTP headers would be manipulated to detect sql injection happening via values in the HTTP headers. May be that is why you get a HTTP 400, I am not sure what you mean by HTTP 400 session time out though.

Try reducing the level or ignore the --level switch (let it be with its default of 1) try adjusting the --risk switch. Did you actually set the verbose level or the detection level?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.