Scope control in Nuclei is hard #8097
SamIntruder
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I recently discovered a scope control issue that doesn't seem to be solvable with Nuclei's current redirect behaviour, due to the conflict between flags like -fhr/-dr and the redirect options at the template level.
We currently run Nuclei with -fhr enabled, for scope control - however, it was discovered that doing this enables redirect behaviour on all templates, not just those with configured redirect behaviour at the template level. Due to some templates having relatively weak matchers, this results in lots of FP. For instance, imagine a template which requests /some/path/exists and checks for a 200 - if the server redirects all paths to the root, this will always fire. Sometimes the matcher can't be made any stronger (as appears to be the case for at least some of the templates in the PD set which expose this). You can tell a template to never redirect - and most of them do - but -fhr overrides this.
So we considered turning of -fhr. However, -fhr is also the only scope control Nuclei has on the redirects - if you turn it off, a redirect to an off-network host will result in requests being sent to that host.
We have a patch that implements a new flag, which basically implements -fhr but without the override: 'follow redirects, but only to the same host, and only if enabled at the template level'. I can submit this as a PR, but first I wanted to ask the community: can you see a better way to fix this issue? Ideally, I think this is how -fhr should work (its the intuitive way, no?) but, I think changing this might break behaviour people rely on.
Ultimately, I think we need some proper scope control - and wouldn't mind working on this, too. But, we'd still need a behaviour level change, anyway.
All reactions