NameSpaceRuleChecker: Questions and possible bug with DELETE about restler-fuzzer HOT 10 CLOSED

@rennhard Hi Marc, thanks for your detailed feedback and questions. Here are some answers.

Is allowed access to GET /rest/products/25 intentional?

Yes, by design, the NameSpaceRule checker intentionally flags this access by user-2 of a dynamically-created resource created by user-1. This is to err on the safe side: the checker reports all such (potentially dangerous) valid accesses, at the risk of reporting false alarms in some contexts.

Is the missed vulnerability with DELETE /rest/admin/products/luke/25 due to a bug?

If you set "mode": "exhaustive" in this checker settings (in the settings file - see https://github.com/microsoft/restler-fuzzer/blob/main/docs/user-guide/Checkers.md for how to do this and the exact syntax), you should then see the sequence "POST by user-1;DELETE by user-2" that you expected. (If not, please let us know.)

Is there a good way to link the username in a JWT to parameters used in requests?

No, as what you call "username" in your example is implicit/nameless with RESTler and this checker - the first JWT can dynamically create some resources, while the second JWT tries to access those and reports an alarm whenever it is successful. (The 'names' associated with JWT1 and JWT2, if any, are irrelevant.)

Please let us know if this does not address adequately your questions. Thanks!

from restler-fuzzer.

Hi Patrice

Thanks a lot for the feedback. Setting "mode":"exhaustive" does not help to detect the DELETE issue. I'm using the following setting file:

{
    "checkers": {
        "invaliddynamicobject": {
            "no_defaults":true
        },
        "namespacerule" : {
            "mode":"exhaustive"
        }
    }
}

Note that when adding a bug to the REST API so that when calling DELETE the resource is not deleted but still returns 200, then the issue (sequence POST user1, DELETE user2) is correctly detected (as DELETE now returns 200 and not a 4xx status code because the resource is still existing), even without exhaustive mode. The output of the checker is attached. So the problem may indeed be that the NameSpaceRuleChecker uses a wrong approach when checking the sequence POST - DELETE in the sense that it tries to re-DELETE a resource that is no longer there?

Thanks,
Marc

NameSpaceRuleChecker_20x_1.txt

from restler-fuzzer.

Can you please attach the full network.testing.xxx logs?

from restler-fuzzer.

I'm adding two network logs:

• network.testing.140006863460096.1.txt: This is based on the REST API that does not actually delete the resource when DELETE is called (but it still returns status code 204). Here, the NameSpaceRule Checker finds the vulnerability with the sequence POST-DELETE. And there's also a vulnerability reported by the UseAfterFree checker because the resource is not deleted.

• network.testing.139987614951168.1.txt: Here, the REST API correctly deletes the resource when DELETE is called. The NameSpaceRule Checker does not find the vulnerability (although it should).

network.testing.140006863460096.1.txt
network.testing.139987614951168.1.txt

from restler-fuzzer.

Thanks for these network logs. But can you please confirm that these logs were obtained with

"namespacerule" : {
            "mode":"exhaustive"
        }

? (They do not look like it...) Thanks again!

from restler-fuzzer.

I'm pretty sure I'm using exhaustive mode. I'm using the following file user-settings.json on the command line with --settings user-settings.json:

{
    "checkers": {
        "invaliddynamicobject": {
            "no_defaults":true
        },
        "namespacerule" : {
            "mode":"exhaustive"
        }
    }
}

The reason why I also added the rule for invaliddynamicobject was to make sure the settings file is working (as I get such a vulnerability without the settings file and it went away when using the settings file), as the output files of fuzz-lean don't contain any information about what checker settings were actually used.

I also just checked with fuzz mode (instead of fuzz-lean), but this has no effect on vulnerabilities that are reported (or not) with the DELETE request.

from restler-fuzzer.

Thanks Marc. I've created a new issue to stop the checker from replaying the final request in the sequence prior to sending the attack request. This should hopefully relieve the issue surrounding false negatives when attacking with DELETE requests. I'll look more into what's going on with exhaustive mode as well.

from restler-fuzzer.

Thanks again Marc.

To be clear, there are 2 distinct action items:

• the Namespacerule checker should test the 'POST;DELETE' sequence even in non-exhaustive mode - new issue #112 has been filed to address this.
• the network logs above do not show all the consumer requests being tried in exhaustive mode (as we had expected) - this should be investigated as well (either the exhaustive mode was not turned on properly, or there is a glitch somewhere).

from restler-fuzzer.

Thanks a lot for taking care of this.

I'm closing this issue.

from restler-fuzzer.

Just to conclude:

• the first point above was fixed with issue #112
• the second point above: after further investigation, my understanding of the exhaustive mode was wrong (my mistake) and there was no glitch here.

Thanks again for your feedback.

from restler-fuzzer.