pkg/ffuf: fix panic in Windows when parsing wordlist flag #335
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This change addresses two panics that happened while parsing the provided wordlist flag in Windows systems.
pkg/ffuf/util.go:40
: panic happened when the provided path was invalid. Example:.\wordlist.txt:
as theos.Stat
call returned an error different thanos.ErrNotExist
.pkg/ffuf/optionsparser.go:179
: panic happened when the provided value did not existed and did not contain a colon character. Example:.\asdf.txt
when the local file.\asdf.txt
did not exist. This panic happened due tostrings.LastIndex
returning-1
when the provided substring does not appear. Therefore,v[:-1]
panicking.Fixes #333
Additonally
CONTRIBUTORS.md
.The file should be alphabetically ordered.
CHANGELOG.md
Please, test this patch thoroughly using a Windows system before merging it. I'd like to contribute unit tests for this patch too in order to avoid having a regression or incomplete fix. However, it would require a bigger refactor of the file rather than just 2 panic fixes.
Note:
pkg/ffuf/optionsparser.go:181
(L185 on my patch) does not panic asstrings.LastIndex
returning -1 will make the slice access to bev[0:]
, preserving the completev
value. It would be nice to prevent this in a next patch, though.