support of JSON objects in the HTTP parameters

Hello,

I found that sqlmap missed an sql injection in the following structure of parameters:
https://xxx/api/get?cat_id=["string"]

I have specified a payload location manually using asterisk as below:
https://xxx/api/get?cat_id=["string*"]
and sqlmap managed to found and exploit the vulnerability.

The application is written on PHP, I'm not sure what's a framework behind it or how the the app parses this parameter.

Perhaps, you will know better. I suspect it has something to do with nested insertions?
Hope you can enhance the tool so it would parse such parameter and pick up the vulnerability automatically.

Thank you.

Well, this doesn't look like a standard way that parameter values are enclosed. If I see this kind of behavior in future I'll gladly add the prefix/suffix boundary support (in higher levels). Till then closing this down

I disagree that this is non-standard way. I have requested an additional info from developers but it looks like parse_str function is involved here. I have verified the issue with a commercial scanner and it was able to pick it up.

Can you please find me the standard involved?

Or a bulk of sample URLs on regular web sites that uses those?

So developers came back with an explanation this is a JSON object and they parse it later using a usual parser:
JSON.parse('["string"]');
See the following document for more details: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse

I double checked the original request and it was a JSON GET request indeed with the following header:
Accept: application/json, text/javascript, */*; q=0.01

I agree that this might not be a common way of using it so I would suggest to include that case to a high level of tests (5?..).

In regular web applications, JSON is used in POST data (containing all parameter names and values as serialized dictionary). I am not arguing that you have a JSON in your case (though as an array in GET parameter value). I just wanted you to send me some real-life examples (and not a link to what is JSON).

The app is using standard jquery and bootstrap js libraries. Json query is getting created using similar code:

return $.ajax({
        url: top.serverLocations + 'api/' + id + '/' + top.catId(),
        type: 'get',
        async: true,
        dataType: 'json'
});

It returns a standard JSON reply too. This API call (see the url) is used by a mobile client in my case (real life example).

I'm also telling you that a commercial scanner supports it just fine.
I'm ok if you don't want to improve sqlmap.

I'm ok if you don't want to improve sqlmap. <- LOL
Your provided code does not produce JSON dumped array in GET parameter
I won't reply any more to this Issue. You have a custom injection marker and you are pushing me to include some support for shitty developer code including the JSON dumped array into the GET parameter. Also, you have a nerve to write the 1)

Implementation for an Issue #1826

Implemented.

Now you'll be asked it appears that provided value for .... parameter '...' has boundaries. Do you want to inject inside? [y/N] <- though, for now it is not turned on by default (in batch mode)

Perfect, thanks!

P.S. sorry for the 1). I didnt mean to hurt you in any way. We all know how passion you are and sqlmap is the best tool for sqli exploitation. That's why I wanted to add one more bit to make it better.

FYI, below is the actual source code (sanitized):

    api.get = {
        all: function (a, xx, xxx) {
            var categories;
            var cat_id = a['cat_id'];
            if (cat_id) {
                categories = cat_id.indexOf('[') != -1 ? JSON.parse(cat_id) : cat_id.split(',');
            }
......
            }).then(function (b) {
                    var query = "select ..." and (" + categories.map(function (c) {
                                return "c.category like " + "%" + c + "%"

As said, it is not a standard way for parameter passing. You can see that it extracts JSON content from within brackets

Ok, I'm back with a similar problem. I'm testing a new web application written on Java this time.
The new JSON request is below:

POST /poll/receive HTTP/1.1
Host: xxx.com

pollerRequest=[{"Key":420918415693,"cId":"10157","IdsMap":{"notification":false,"chathook":false},"uId":"Od6jrt4sTwogA==","timestamp":1463368146585,"startPolling":true}]

As you can see, the change that you have implemented is not sufficient. Here is the current output:

it appears that provided value for POST parameter 'pollerRequest' has boundaries. Do you want to inject inside?
<skip>"startPolling":true*}]') [y/N] y

The current implementation just injects "*" to the last parameter ("startPolling") and skips all other json fields.

I suggest to detect JSON objects submitted as a value of parameters properly. So that it would be parsed and tested fully.

Thank you.

And your example is an abomination of pollerRequest parameter value with JSON array containing single dictionary having all those regular key values. Afterwards you have a nerve to "suggest" something.

I'll gladly cut this kind of "suggestions" with: you have a custom injection marker (*) for this kind of cases.

Thank you

p.s. at the end (today?) maybe I'll write a support for this kind of requests, but as you can see I tend to become very edgy with this kind of suggestions

well, "*" is a workaround but it is difficult to inject it manually into a big json object. For example, there are 10 parameters in the last json request.

It would be just nicer to have a feature which would "normalize" variations of it.
Take burp, as an example. They have "attack insertion points" menu: URL parameters values, body parameters values, cookie, parameters itselves and so on. They can even change locations: URL to body, body to URL and so on.

Is it a standard way? No. Do developers use it? Yes.
Does it help to find vulnerabilities? Definitely yes.

I agree that this is a feature of a scanner, not a post exploitation tool.
So it is your call really. Thank you for looking at it.

Update for an Issue #1826

Added support with last commit

Update for an Issue #1826

cool, thanks

sqlmap: bump to the latest, sqlmapproject/sqlmap#1826

Navigation Menu

Repository navigation

support of JSON objects in the HTTP parameters #1826

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

support of JSON objects in the HTTP parameters #1826

Description

Activity

stamparm commented on Apr 25, 2016

blshkv commented on Apr 26, 2016

stamparm commented on Apr 26, 2016

stamparm commented on Apr 26, 2016

blshkv commented on Apr 26, 2016

stamparm commented on Apr 28, 2016

blshkv commented on Apr 28, 2016

stamparm commented on Apr 29, 2016

1 remaining item

stamparm commented on Apr 29, 2016

blshkv commented on Apr 30, 2016

blshkv commented on May 5, 2016

stamparm commented on May 5, 2016

blshkv commented on May 16, 2016

stamparm commented on May 16, 2016

stamparm commented on May 16, 2016

blshkv commented on May 17, 2016

stamparm commented on May 17, 2016

blshkv commented on May 17, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions