Conversation
|
This looks quite promising! The detection part should already work, but I wonder how we could guide the fuzzer to add properties to The paper "Prototype pollution attack in NodeJS application" describes two forms of vulnerable expressions:
We should be able to create a custom Babel transformer to detect this syntax and invoke appropriate guiding functions. Perhaps it could also invoke a function which could be hooked using the normal hooking framework. The Babel AST explorer shows that the transformer would need to process nested member expressions: https://astexplorer.net/#/gist/0518da7634c3406b968f9ce9478d4b5a/e6629d9f54906e4272a3bf1943710a61a1a5f04e |
|
Norbert, what a great idea, thanks! |
|
I'm a bit confused, but the newest commit "bug detectors: add path traversal" actually belongs to #419, right? But that is already merged, so why is it still shown here? 🤔 |
42ccb07 to
4f54904
Compare
|
Apologies for this giant PR |
fmeum
left a comment
There was a problem hiding this comment.
First comments, but I haven't gotten to the actual bug detector yet :-)
e126977 to
a2c41d4
Compare
a2c41d4 to
b494016
Compare
The bug-detector module should use the normal user-facing API to report findings, register callbacks and the like to verify that those work correctly and be able to be used as examples.
HookManager had too many responsibilities. Extract those out and move to functionally more fitting modules to simplify the project layout. Furthermore, hooks and bug detectors should only use the publicly exposed API from core and not reach into internal modules.
ee8429c to
40e0859
Compare
The core source code file contained functions for varying topics and with different abstraction levels. For better understanding and cohesion these functions were extracted into topic specific files, only exporting really necessary internals.
40e0859 to
a80b211
Compare
This PR has two main additions: