Adding scope_distance config for hunt module

[Giardi77]

Problem: The hunt module generates findings for out-of-scope targets (e.g., distance > 0) , even when the scan is intended for distance 0 targets due to the default scope_distance_modifier, causing it to generate a lot of noise like:

[FINDING]               {"description": "Found potential SERVER-SIDE TEMPLATE INJECTION parameter [id]", "host": "www.googletagmanager.com", "url": "https://www.googletagmanager.com/gtag/js"}       hunt    (distance-1)

Solution: Make hunt module's scope_distance_modifier configurable. This allows restricting hunt to operate only on distance 0 targets by setting scope_distance in its configuration.

ps: I don't know if this is the right way to approach the problem but this tool is amazing and i wanted to try and contribute with something little.

[TheTechromancer]

The bug in this situation is that WEB_PARAMETER events are being raised for out of scope assets. This shouldn't be happening.

@liquidsec

[liquidsec]

The bug in this situation is that WEB_PARAMETER events are being raised for out of scope assets. This shouldn't be happening.

@liquidsec

This is not a bug, this has always been by design. They are all coming from in-scope assets, but where there are links for out of scope ones. I believe hunt is the only module ingesting them that is not in-scope-only - another intentional decision. But I can see the merit it making that behavior optional (and off by default)

[liquidsec]

@Giardi77 I have also noticed this can be noisy, and think the default behavior should be changed.

can you make the following changes, and then I will pull this in?

Lets actually make the default setting 1

You have to have an options description if you add an option, reference another module to see how this is done. It won't pass the tests otherwise.

[TheTechromancer]

I think the default should be 0. Results from hunt are already low confidence, being based only on the name of the parameter. It seems excessive to run it on out of scope stuff by default.

[liquidsec]

I think the default should be 0. Results from hunt are already low confidence, being based only on the name of the parameter. It seems excessive to run it on out of scope stuff by default.

No, you're right - I forgot how that setting worked. @Giardi77 0 is what we want.

[TheTechromancer]

@Giardi77 in this case the scope distance modifier can be removed altogether. That will default it to 0, but allow it to scale with the user's scope.search_distance setting, in case they're interested in further out targets.

[Giardi77]

sorry for the pytest_debug.log thing

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93%. Comparing base (912d836) to head (ea4b533).
Report is 5 commits behind head on dev.

Additional details and impacted files

@@          Coverage Diff          @@
##             dev   #2457   +/-   ##
=====================================
- Coverage     93%     93%   -0%     
=====================================
  Files        398     398           
  Lines      33078   33077    -1     
=====================================
- Hits       30587   30567   -20     
- Misses      2491    2510   +19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheTechromancer]

No worries, thanks for your work on this!

[liquidsec]

@Giardi77 in this case the scope distance modifier can be removed altogether. That will default it to 0, but allow it to scale with the user's scope.search_distance setting, in case they're interested in further out targets.

i think the idea was that you might want to adjust this separately: that was the original intent of the way it was before. You're basically getting them for "free" so why not, even if they aren't in scope (no additional requests are required - it won't actually make an out-of-scope request)

But at this point, its probably not worth the extra complexity.