log should contain the URI and when it's a POST should contain the POST body

[jabra-]

The log output doesn't contain enough information to verify the SQL injection manually.

It should be enough to be repeatable using manual techniques.

[stamparm]

Which log are you referring to? Log file, traffic file, verbose output (-v..)?

[jabra-]

The file I'm talking about is output/WEBAPP/log.

On Thu, Dec 6, 2012 at 9:56 AM, Miroslav Stampar
notifications@github.comwrote:

Which log are you referring to? Log file, traffic file, verbose output
(-v..)?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/286#issuecomment-11088371.

[stamparm]

You can get that same data inside traffic file or with high verbose level (e.g. -v 6). This is a first request to put that inside log file. Inside log file there is sufficient data to see what's happening. For everything else there are other means (as stated)

[bdamele]

Not a bad idea, to add to the log file the raw request at the beginning. Although, a user having used sqlmap to detect and exploit the SQLi knows what the request is when he provides it with -u or -r. Certainly with -l and --forms or similar this is useful.

[stamparm]

You can get all this with -t traffic.txt

[stamparm]

Also, inside log file we write any injection point found by the way. Including whole request would just put a more mess inside.

[bdamele]

In my opinion this introduces no mess in my opinion if we add it once only.

[stamparm]

Because of the workflow how we use log file we can't put request just once. We have to put it every single time injection point is found. Also, as with --flush-session it's not erased (on purpose as log file should stay)

[jabra-]

IMO, it should include each unique URI...

For a single URI with multiple parameters that could be written just once...

On Thu, Dec 6, 2012 at 10:08 AM, Miroslav Stampar
notifications@github.comwrote:

Because of the workflow how we use log file we can't put request just
once. We have to put it every single time injection point is found. Also,
as with --flush-session it's not erased (on purpose as log file should
stay)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/286#issuecomment-11088846.

[stamparm]

could anybody pinpoint to me where to put URI inside this: http://pastebin.com/YL3zqPGJ

we use log file as an output of standard console output (stuff from lib/core/dump.py). we don't usually output URI. hence, we would also need to output URI to the console

[stamparm]

p.s. have you noticed that there is a file (inside that same folder) named target.txt?

[jabra-]

Yes, but it only includes a single target since sqlmap doesnt append data
to the file.

On Thu, Dec 6, 2012 at 10:21 AM, Miroslav Stampar
notifications@github.comwrote:

p.s. have you noticed that there is a file (inside that same folder) named
target.txt?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/286#issuecomment-11089373.

[stamparm]

And what's wrong with good old -t traffic.txt for special cases when target.txt is not enough?

[jabra-]

-t traffic.txt has all of the data for all requests. I'm just looking for
the sql injection locations.

On Thu, Dec 6, 2012 at 10:27 AM, Miroslav Stampar
notifications@github.comwrote:

And what's wrong with good old -t traffic.txt for special cases when
target.txt is not enough?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/286#issuecomment-11089654.

[stamparm]

And inside log file you can't find sql injection locations?

[jabra-]

It doesn't have the full location to verify it manually.

On Thu, Dec 6, 2012 at 10:33 AM, Miroslav Stampar
notifications@github.comwrote:

And inside log file you can't find sql injection locations?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/286#issuecomment-11089934.

[stamparm]

p.s. so you want complete URI and POST body inside log file because all other data inside log, target.txt and traffic.txt is not enough. do you want something else along?

[stamparm]

I'll upgrade target.txt file to contain that information (POST data if used
along with multiple urls if such case)
On Dec 6, 2012 4:35 PM, "jasbro" notifications@github.com wrote:

It doesn't have the full location to verify it manually.

On Thu, Dec 6, 2012 at 10:33 AM, Miroslav Stampar
notifications@github.comwrote:

And inside log file you can't find sql injection locations?

—
Reply to this email directly or view it on GitHub<
https://github.com/sqlmapproject/sqlmap/issues/286#issuecomment-11089934>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/286#issuecomment-11090001.

[jabra-]

Thanks.

On Thu, Dec 6, 2012 at 10:55 AM, Miroslav Stampar
notifications@github.comwrote:

I'll upgrade target.txt file to contain that information (POST data if
used
along with multiple urls if such case)
On Dec 6, 2012 4:35 PM, "jasbro" notifications@github.com wrote:

It doesn't have the full location to verify it manually.

On Thu, Dec 6, 2012 at 10:33 AM, Miroslav Stampar
notifications@github.comwrote:

And inside log file you can't find sql injection locations?

—
Reply to this email directly or view it on GitHub<
https://github.com/sqlmapproject/sqlmap/issues/286#issuecomment-11089934>.

—
Reply to this email directly or view it on GitHub<
https://github.com/sqlmapproject/sqlmap/issues/286#issuecomment-11090001>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/286#issuecomment-11090872.

[mukareste]

Obviously, I'm a bit late, but in my opinion, the log, target and the traffic files are more than enough. Also, if you are doing a pentest (that's what sqlmap is meant for, AFAIK), you would capture the entire traffic anyway, and it is trivial to extract the requests from the dump if you cannot find them in the above mentioned files.

[stamparm]

Now inside the corresponding target.txt file you'll find:

A) in case of HTTP GET method:

http://www.target.com/vuln.php?id=1&id2=2 (GET)

A) in case of HTTP POST method:

http://www.target.com/vuln.php (POST)

id=1&id2=2