[FEATURE REQUEST] Fuzzing with OPTIONS method then automatically Fuzzing with method returned in Allow headers.

[0xDexter0us]

Is your feature request related to a problem? Please describe.

When fuzzing APIs we all know and are lazy to FUZZ all GET, POST, PUT, PATCH, and DELETE, and miss a lot of stuff as for example GET /foo gives 404 while POST /foo might give a 200 Ok,

Describe the solution you'd like
My solution sounds simple but might be hard to implement.

• Fuzz with -m OPTIONS flag.
• Read all the responses of 200 and 204, it's just headers.
• Extract the value of the Allow & Access-Control-Allow-Headers headers from the responses.
• Fuzz those methods from the responses. (Just with caution in the case of the DELETE method)

Additional context

[mzpqnxow]

Is your feature request related to a problem? Please describe.

When fuzzing APIs we all know and are lazy to FUZZ all GET, POST, PUT, PATCH, and DELETE, and miss a lot of stuff as for example GET /foo gives 404 while POST /foo might give a 200 Ok,

Describe the solution you'd like

My solution sounds simple but might be hard to implement.

• Fuzz with -m OPTIONS flag.

• Read all the responses of 200 and 204, it's just headers.

• Extract the value of the Allow & Access-Control-Allow-Headers headers from the responses.

• Fuzz those methods from the responses. (Just with caution in the case of the DELETE method)

Additional context

It would also be useful to have this occur on a per-directory basis. For example, OPTIONS / is the base case. Consider a case where OPTIONS / returns HEAD, GET; later, the directory /api is discovered. An OPTIONS request to /api may return something different (GET, PUT, POST, etc)

Obviously it's common for there to be per-directory configurations on modern reverse proxies and load-balancers. What I'm not sure of, though, is how often (in practice) OPTIONS actually provides full and honest information (assuming it's supported at all)

Just a thought, I'm not sure I have an immediate use-case for it

[0xDexter0us]

@mzpqnxow

What I'm not sure of, though, is how often (in practice) OPTIONS actually provides full and honest information (assuming it's supported at all)

APIs that implement CORS always provide full and honest information as it is mandatory because of the pre-flight requests sent by the browsers and it is way too common.

I'm not sure I have an immediate use case for it

Any reasons?

[epi052]

Hey there, thanks for submitting this!

Im neck deep in life stuff right now. I'll be able to reply in detail in a week or two. Just wanted to let you know I saw it. Thanks again!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[epi052]

howdy!

I like the idea! This feature could be exposed as one of the collect family; maybe --collect-options? it'd probably be good to tie it to --smart and --thorough meta options as well.

i don't have the time right now to work on this, but would happily accept a PR in the interim.

Thank you for the suggestion!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mzpqnxow]

@mzpqnxow

What I'm not sure of, though, is how often (in practice) OPTIONS actually provides full and honest information (assuming it's supported at all)

APIs that implement CORS always provide full and honest information as it is mandatory because of the pre-flight requests sent by the browsers and it is way too common.

I'm not sure I have an immediate use case for it

Any reasons?

First, sorry for this comment, it lacked context and was not constructive. And it also lacked full consideration of your point referring CORS

There are two parts to this:

1. By volume, the servers that I need to test do not implement CORS, because, reasons. I understand that's not representative of the modern Internet, or all users of feroxbuster; it's just a characteristic for the very small subset that I tend to deal with. Think misconfigured servers and "traditional" (maybe "legacy") APIs and sites with mostly static content. For these, CORS is rarely a consideration, so I hadn't thought much about it. I probably should
2. There's a caveat that (I think) should be put on the "full and honest" bit, but please check my work there and correct me if I'm mistaken

I won't go into detail on the first bit but I will concede that services implementing CORS will become a larger portion of my scope over time. In fact, that's part of the reason that I'm interested in you checking if my next point is valid

For the "full and honest" bit - I'll say that if I understand how CORS is implemented, "full and honest" is not quite true; specifically the "full" part. It can be misleading

My understanding of CORS is that it ultimately operates as a whitelist mechanism

It will tell a browser "You can use POST and DELETE"- as opposed to a blacklists, which might say "You can not use PUT, UPDATE, ..."

Perhaps it's possible to do both, but either way, you might only be seeing a subset of the verbs supported by the endpoint(s) - specifically, those explicitly intended to be consumed by a browser

This is not a criticism of CORS or a suggestion that using the latter (or any other) approach would have been batter- quite the opposite, it makes the most sense this way. I'm only stating it that way to highlight that verbs/methods that are not intended for use via a browser at all or across origins will be omitted, because they're implicitly denied by not being explicitly permitted (I think?)

Perhaps you've already considered this or know exactly what I mean; if not, here's a contrived example, because everyone loves contrived examples...

• Consider an application /api/v1/ that supports a site for consumers that want to purchase widgets and such
• The developers want to allow searching from a browser via "POST" (or, what the heck, "SEARCH")
• They also want to support retrieving of specific items via "GET"
• The verbs "PUT", "DELETE" and "UPDATE" are implemented in most of the endpoints across that API, but they are not intended for cross-origin use- or even use in a browser at all. They're intended to be consumed directly and programmatically

In this case, taking advantage of CORS will let you know about "POST"/"SEARCH", but it will not let you know about "PUT", "DELETE" and "UPDATE"

Please correct me if I'm mistaken there, you can probably tell that I don't work much with CORS since I neglected to consider it until you mentioned it ;)

Is this an edge-case? Very possibly. I suppose it depends on the API frameworks in use and the most common practices of developers, right?

All this to say that, as I understand it, CORS is informative but not comprehensive or authoritative

It would be useful to create a starting point for verbs based on CORS information, but that information should not be trusted completely if you want thorough testing

The specific implementation within something like feroxbuster that I think should be avoided is to override a list of verbs supplied by the user with a subset of those (only the ones effectively "advertised" by CORS), because it could cause some misses

Again though, I have no idea how big of an impact this would have in practice. A web dev, or someone with the patience to test some whitebox applications could probably help determine that with data

Hopefully that's a little more helpful than my previous comment.

In the end, my thinking was based in the fact that @epi052 only has so much time to implement all of these great features. He's implemented quite a few that I was personally very interested in- so I am a little (selfishly) defensive of his time 😀

Thanks for the ideas and discussion
@0xDexter0us

And thanks for the great work @epi052