-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Add Sniper Mode #469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Sniper Mode #469
Conversation
…nctions for Requests
joohoi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! Sorry that it took so long to get around to review this. This is a great addition, and a total beast of a PR 💥
I love how you added tests alongside of it too.
I'm going to need a bit more time to go through it all. In case you haven't completely given up on this because of the long delays, maybe you could fix the merge conflict I must have caused with other changes meanwhile?
|
Heya, definitely still keen to get this merged. I'll take a look at the merge conflicts during the week and see if i can sort it out. |
|
Looks like the merge conflict was just the language changes in the termhandler. Easy fix |
joohoi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All in all, looks good! I absolutely love that you included tests for the couple heavily modified files too. The only minor tweaks that came to my mind were reading the template char from the inputprovider itself, as well as the following:
I wonder if it would make sense to reword this job-start message in case the user is running in sniper mode:
Line 208 in b56de00
| j.Output.Info(fmt.Sprintf("Starting queued job on target: %s", j.Config.Url)) |
|
Righto, I've updated sniper mode to use the Changing the job-start message is a good idea, I've made that change so the user can see how far through the sniper job queue they've progressed |
|
Heya, keen to get this merged. Was there any other info or changes you needed from me? |
joohoi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's good to go, sorry for the delay!
* Modify SimpleRunner to take a Request parameter, add base and copy functions for Requests * Add Request structs to run queues * Implemented sniper mode * Added request and optionsparser tests for sniper mode * Removed unneccesary print statements * Updated readme.md and terminal output * Enabled command inputs for sniper mode * correctly initialize validmode in optionsparser * Remove unnecessary print data in TestScrubTemplates * Use InputProvider for sniper template characters * Add a sniper-mode specific queue job execution log
|
I saw @denandz Just a suggestion, but it might be useful to add it to https://github.com/ffuf/ffuf/wiki as well. |
Description
This pull request adds a "sniper" mode to ffuf. This lets you specify payload locations using template characters, and ffuf will then run through each one. TLDR, this now works:
ffuf will hit each of the payload locations above, one after the other, while preserving the other values.
Here's some background before delving into the details.
The main issue is that using ffuf to hunt for vulnerabilities rather than do content discovery can be rather clunky. What I'd like to do is take a single request that I'm interested in, highlight the locations I want to attack, and then have ffuf go through and smash my word-list at each value, one after the other, while preserving the legitimate values in the other fields I've highlighted.
Currently, a single request would need multiple command line runs and multiple request files (if you use ffuf with request files instead of building out every request by hand with flags), one for each fuzzing location. For example, the following request (an attempt to log in to GitHub):
This would need a 14 different request files for just value side of the
POSTparameters, each with aFUZZparameter. When looking at an entire application this becomes problematic. With the sniper mode that this pull request implements, instead of using 14 different request files, there is just one:The section sign characters can be added in
viusingctrl-kfollowed byshift+S+E. There are key combos for windows/macos/linux/whatever detailed hereThis pull request touches a fair bit of ffuf's internals, which I'll try go over in some detail.
General arch
I tried to integrate these changes with the existing ffuf design without changing the internals too much wherever possible. The new sniper mode is a thin veil over the clusterbomb mode. It generally works like this:
FUZZused as the keywordStart()) and if sniper mode is configured, then the requests are parsed for template characters (§)SniperRequests, with one location specified by the user replaced byFUZZin each request.Change summary
main.go- minor changes for new mode stringinput/input.go- minor changes to support the new mode stringinteractive/termhandler.go- Queue jobs are no longer just for recursion jobs, so the language has been changed in the termhandler to reflect that.runner/simple.go-Prepare()has been modified to take a Request parameter, rather than build a newRequeststruct from the global config.ffuf/config.go-InputProviderConfignow includes aTemplatestring field which holds the payload locator symbol used by sniper mode.ffuf/interfaces.go-RunnerProviderhas been tweaked such thatPreparenow requires a base request.ffuf/job.go-QueueJobstructs now hold aRequestfield, this is the base request used by each QueueJob when it's running.Start()has been modified to implement the sniper request parser when necessary, and additional changes made to the other methods to support pulling the base request for each job out of the queue struct.ffuf/optionsparser.go- Changes for the additional mode and a validator for sniper configuration. This now handles the modes prior to dealing with wordlists/input commands.ffuf/optionsparser_test.go- New file, implements test logic for the sniper validator.ffuf/request.go- New methods to generate requests from the current config, copy requests and handle sniper request parsing logic.ffuf/request_test.go- New file, tests for the new Request functions