Comments (10)
@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.
Related Issues (20)
- refactor compiler configs so strict deserialization can be turned on HOT 2
- Content-Length header is not getting fuzzed based on the list of naughty strings HOT 1
- "Attempting to get resources from GET request..." ignores required GET parameters
- Can't run restler compile
- Ensuring Mandatory Headers for API Access in Restler Requests HOT 1
- How to properly configure and use authentication tokens in Restler? HOT 1
- Improve logging in RESTler compile step in case of a spec issue instead of just failing without and not giving clear indication of which property is problematic HOT 1
- RESTler's attempts to reproduce bugs add extra quotes (") for values sourced from restler_custom_payload
- Automatic inferred dependencies not working
- Trace database requests include authorization token
- Dynamic object encoding is adding extra double quotes when consuming value from other call
- RESTler is logging error for missing parameter in the response even when the parameter is not configured for the specific response code
- RESTler ran forever: "Exhausted collection..." loop prevented RESTler from honoring --time_budget
- Token Refresh Interval is not working under Proxy
- Can RESTler detect other status codes than 500? HOT 1
- Question about "restler_custom_payload_header" HOT 1
- [Feature Request] Improve Annotations to Support Integer Responses
- Handling ByteArray in Request Object During Fuzz Testing: Incorrect JSON Representation Issue
- Authorization using setting 'token_refresh_cmd' not working HOT 2
- Fail to build docker image locally HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from restler-fuzzer.