search

JGillam / burp-co2

A collection of enhancements for Portswigger's popular Burp Suite web penetration testing tool.
Other
151 stars 33 forks source link

Possible improvements #8

Closed Hipapheralkus closed 8 years ago

Hipapheralkus commented 9 years ago
  1. Session management As Burp has already a session management built-in, would it be possible to incorporate it within the SQLMapper? Or even a half way (if returned XZY in response, I'm out of session, invoke Burp session management macro, get a fresh session parameter YZX and use it in header within cookies).
  2. Dropdown menus for technologies used I have to go into manual and search for possible DBMS (e.g. mssql) and OS (e.g. Windows). Would it be possible to simply choose these from dropdown menus?
  3. Run button When path to sqlmap.py is not set, Run button is grayed out. Would it be possible to have some asterisk/question mark nearby? As "Config" appears to belong to "Extra SQLmap params" rather than to Run button; and I'm probably not the only one who had a hard time figuring it out for the first time.
  4. Active scan I can see that it is possible to scan 1 request at a time. However, would it be possible to actually incorporate this into an Active scan? Hence many more requests could be scanned.
JGillam commented 9 years ago

Thanks for the ideas. :) Here are some responses:

  1. SQLMapper does incorporate cookies. I'm not sure how the Burp plugin could incorporate anything more intelligent since all it does is pass the work over to SQLMap. These same capabilities would have to exist in SQLMap, wouldn't they?
  2. Dropdowns are a good idea, especially for options that come from a fairly static list.
  3. Good point. I'll see what I can do to make it more obvious in the UI
  4. That's an interesting idea. I'm hesitant to add this to the active scanner simply because I'm not a fan of blindly active scanning anyway. But another reason why this would be complicated is because SQLMap is an external process. Imagine what a mess you would have if you kicked off an active scan across a site with many forms? You would be spawning a lot of SQLMap processes and having to wait for each one. Its also usually best to interact with them rather than blindly accept defaults.
Hipapheralkus commented 9 years ago
  1. It is true that SQLMapper does support cookies, and I can use --safe-url with payload in POST to access each time to generate a fresh cookie; however on all platforms I'm testing there are CSRF tokens in each POST which can't be that easily found and incorporated within the request via SQLMapper and with new session new pair is generated. Also, sometimes there are platforms which require 2 or 3 steps (e.g. also memorable word, security question, ...) which is impossible to do with SQLMapper and I can either test them manually (however when WAF detects attack, I'm kicked out of the session so it is time consuming) or I can use Burp Active scan for SQL injections. However possibility of using SQLMapper with Burp session management would be a very strong tool. I'm not sure how CO2 is communicating with SQLMapper, but I've generated a logfile of all HTTP communication. If that could be used; by analyzing a response, Burp would find out whether session exists, and if not session management would kick in, cookie jar would be updated and Burp could alter next request and send it via SQLMapper. It is only my guess, I have no idea if that is possible to do in the first place. Another way could be that after setting a session management, Burp could pass new set of cookies/CSRF tokens to SQLMapper.
  2. I'm aware of interaction being the best option, however detecting at least a low-hanging-fruit platform-wide would be a great improvement:) Especially if the website contains hundreds of pages, each sometimes with hundreds of parameters, where it is almost impossible to do manual evaluation. Concerning the active scan, if I set number of threads to 1 (to both Burp active scan and SQLMapper as well), active scan is only scanning a particular page before moving to another one; and SQLMapper would run only 1 instance so in theory, I could have a DFS searching using 1 thread. Burp Active scan already contains SQL injections so platform-wide scanning is possible, however performing more advanced attacked/specialized settings is only possible via SQLMapper. Being able to scan all requests from Active scan with specialized settings (e.g. using specialized tamper files) would find many more issues than Burp Active scan in my opinion, especially during internal tests where penetration tester is familiar with all the technologies used.
  3. That reminds me - you could also add few new commands: "--safe-url="; "--safe-freq=" and "--safe-post=" parameters for a basic session management into CO2, I think it could be used by many people:) Although I couldn't find "--safe-post=" in the official documentation but it does work and when I need to do a POST with to login page with some data (e.g. "username=user&password=password1") it is possible to do so.
Hipapheralkus commented 8 years ago

I just found out that session management is possible rather easily - all it takes is to set up Burp session management; Turn on "Proxy" in Tool Scope of Burp's session detection; and set proxy in SQLMapper to http://127.0.0.1:8081 (Burp's listening port) and now everything sent from SQLMapper goes through Burp and it takes care of the entire session management:) And as a bonus, everything is present in History - all requests and responses:) So "--safe-url=" is not needed at all.

JGillam commented 8 years ago

I've opened new enhancement requests for the items in this thread that seem easily achievable. Feel free to add new requests for others. I prefer not to have multiple enhancements on the same ticket because it makes it harder to track.