Open joaociocca opened 1 year ago
Just checking I'm understanding correctly, you are talking about starting all HTTP enumeration from a specific path rather than /, i.e. feroxbuster would fuzz /[path]/[fuzz] instead of /[fuzz] and other HTTP plugins would handle it accordingly?
Could be done using globals. The issue with automatically using a redirect path is you could miss stuff. For example, requesting / might redirect to /home/ but that doesn't mean files don't exist in /. But I guess that could be another non-default option for the dirbuster plugin.
Lets say I started an autorecon. It was doing it's thing with everything else, but the target "sub.domain" when curl'd or browsed to redirects you to "sub.domain/this/other/path/because/who/knows". From the redirect, we get a completely different starting point for everything. HTTP(S)
I know there's
--curl.path
, but it doesn't seem to reflect on... well, anywhere other than curl. Everything else, including the dirbuster plugin, still goes for the target domain only. Would be nice if there was a "target path" to use in cases like this, could expand usage of AutoRecon for cases when target (sub)domain redirects to a path.Hm... perhaps identifying a redirect (dunno about python, but I know how to do it in bash 😅) could be explicitly shown in the progress messages of the AutoRecon when not using target path parameter (yeah, I know it's easy and simple to see the redirect in gathered logs, just throwing ideas around).