extend tamper scripts to support decoders for processing responses

[flowztul]

I recently ran into the issue of an SQL-injectable application returning data in a format that sqlmap didn't handle too well. I therefore extended the tamper script logic to also support adding decoders that process responses returned from getPage() before the rest of sqlmap's logic takes over. As I'm not very familiar with the sqlmap codebase I would certainly welcome review of this patch.

[stamparm]

extend tamper scripts to support decoders for processing responses

tamper_priorities = []  
decode_priorities = []

if kb.decodeFunctions:  
    for function in kb.decodeFunctions:  
        page, headers, code= function(page, headers, code)

How can we merge this? This can't go into the master branch.

You say "extend tamper scripts" while you are making "decoding functions". I need to drop this one.

[stamparm]

I see what is your idea, but this is not a proper implementation for it.

[flowztul]

I was aiming at having a minimal impact on the existing code. What specifically do you object to?

[stamparm]

Why are you using tampering script mechanism while handling and naming
those "decoding functions". That's like making a new car that has two
wheels and it works on a foot work, but you call it a car because of some
unknown reason.
On Aug 25, 2013 12:22 AM, "Lutz Wolf" notifications@github.com wrote:

I was aiming at having a minimal impact on the existing code. What
specifically do you object to?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/512#issuecomment-23217720
.

[flowztul]

I modified the tamper script mechanism because it does most of what I needed, i.e., it imports additional python code and stores the function references somewhere. For my purpose, the only difference is that I don't need to modify requests, but responses (which could probably still be called "tampering" in a way).

So, my idea was to support an additional function name (I picked decode(), but it could also be called tamper_response() or anything else) when importing a tamper script, store references to these functions in a list other than kb.tamperFunctions and to use them to process anything returned from Connect.getPage().

What are your thoughts on this general procedure? Do you have any suggestions for an alternate solution to do what I want?

[stamparm]

Sorry for waiting. Problem is of a general matter.

If we are talking about encoding/decoding we can enlist them as:

1. encoding of request body
2. encoding of request payload
3. decoding of response body

Introducing only one of those, while neglecting the rest, is a little bit clumsy. Also, this moment I can't think of a way how to make a support for all those situations without making gazzilion new switches and/or xyz scripts.

[flowztul]

So what would you think of using the existing tamper script mechanism and extend it to provide support for more general hooks? It already supports 2), my patches introduce basic support for 3), maybe 1) can be added as well. The existing mechanism may have to be changed somewhat, e.g. to use more consistent function names for 1)-3) but it could possibly be done while retaining backwards compatibility for existing tamper scripts for now.

[stamparm]

Issue #25