Why is HTTP Options request insecure

问题:

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 ?

回答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.

回答2:

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

回答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.