Why is HTTP Options request insecure

Question

I recently heard from a security audit that HTTP Options is insecure in general and the web-server should not allow it. Can someone explain the reasons why is it so ?

Answer 1

HTTP Options verb can divulge config / debug data on your Web server and as such should only be permitted if it's legitimately needed. Read this post on security stack exchange

https://security.stackexchange.com/questions/21413/how-to-exploit-http-methods

REST APIs make use of Options and I believe it should remain enabled.

Answer 2

Why was this considered bad:

In the past, the main issue was that OPTIONS would expose other potentially dangerous operations available via the webserver. In reality, those operations were exposed whether OPTIONS told you so or not, so the actual danger was more towards easy-profiling by lazy attackers. Automated malware kits will often kick the doors with known DELETE or PUT etc commands regardless of whether OPTIONS works.

In modern systems:

OPTIONS actually have a more valid purpose in regards to CORS (cross-site origin) requests made via XHR (generally JavaScript etc used in modern UI's that don't require full-page FORM posts etc)

Part of the CORS request is basically to say

"I have a request coming from this site/subdomain. What can I do"

This is done with the OPTIONS request with an Origin header, and the response would indicate

"OK, based on where you're coming from, you send POST and GET requests with [these headers]"

This is important, because many sites these days use different subdomains for common functionality (including logins etc). Without CORS, subdomain B cannot access the cookies associated with a login via subdomain A.

If the browser can't send an OPTIONS request to subdomain A, then it will simply abort POST'ing data. No OPTIONS, no XHR CORS request, and stuff will likely break.

Answer 3

One interesting point for REST servers, they are not unlikely to tell you which methods are allowed. For example, it may generate such a response:

405 HTTP/1.1
Server: FooBar v0.1
Allow: POST,GET,DELETE,OPTIONS

The OPTIONS command returns similar information, it also tells you whether certain headers will be supported.

OPTIONS * HTTP/1.1
Host: api.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

And in the answer you get:

Access-Control-Allow-Methods: POST,GET,DELETE,OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type

So we see the same information as shown in the 405 error above.

It supports all the CORS features so it could include an Origin and reply that it does (or not) accept said origin:

Origin: https://api.example.com

will get a reply:

Access-Control-Allow-Origin: https://api.example.com

Some servers would implement the PUT and DELETE commands to work on the server's file system directly and having the OPTIONS available would smoothly tell you that these two methods were supported. I don't personally see why the OPTIONS got its bad rep since attempting a PUT would also tell you whether it was supported or not. So with or without OPTIONS, if you have a stupid server implementation, a hacker can take over your server.

Personally, I've never see a server that supported PUT and DELETE to directly update your server's files! Now, if you do not have a REST or WebDav or a need for CORS, I would turn off the OPTIONS feature because it is really not useful.

Answer 4

OPTIONS is a diagnostic method, which returns a message useful mainly for debugging and the like. This message basically reports, surprisingly, which HTTP Methods are active on the webserver. In reality, this is rarely used nowadays for legitimate purposes, but it does grant a potential attacker a little bit of help: it can be considered a shortcut to find another hole. Now, this by itself is not really a vulnerability; but since there is no real use for it, it just affects your attack surface, and ideally should be disabled. NOTE: Despite the above, OPTIONS method IS used for several legitimate purposes nowadays, for example some REST APIs require an OPTIONS request, CORS requires pre-flight requests, and so on. So there definitely are scenarios wherein OPTIONS should be enabled, but the default should still be "disabled unless required".

source: https://security.stackexchange.com/questions/21413/how-to-exploit-http-methods