Is the HTTP method OPTIONS secure nowadays?

Question

I've read How to exploit HTTP Methods:

OPTIONS - this 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".

This post is a bit old now. What's up today with the OPTIONS methods? Most of the scans show that it's a vulnerability. Is it really dangerous?

I have no choice to use OPTIONS for some of my apps. What can I do to secure it?

Answer 1

I would say implementing the OPTIONS method, in itself, is not a significant security risk. Yes, it nicely enumerates which other methods are implemented by a server, but it is in the handling of those other methods that the potential for danger lies, not in the reporting that they are handled.

For example, the TRACE method can be a vector of attack. If you implement OPTIONS, and it includes TRACE in its response, a potential attacker can use OPTIONS to discover that TRACE is supported then decide to try and launch an attack on TRACE. However, if OPTIONS is not implemented, or it lies and says TRACE is not implemented, the attacker could still decide to try and mount an attack using TRACE. In fact, they are probably just as likely to not use the OPTIONS command at all and simply see if an attack on TRACE will work.

You should focus on making sure that potentially unsafe methods (such as TRACE) are disabled or suitably protected, ahead of worrying whether OPTIONS tells an attacker they exist.

---

The OSWAP GitHub page on Test HTTP Methods starts by listing the eight HTTP methods defined by RFC 2616 (HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS and CONNECT) but only mentions four that should be disabled (or sufficiently protected):

More specifically, the methods that should be disabled are the following:

• PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository.
• DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.
• CONNECT: This method could allow a client to use the web server as a proxy.
• TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page).

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.

And while it highlights how the OPTIONS command can be used by a tester to determine potential vulnerabilities:

How to Test

Discover the Supported Methods

To perform this test, the tester needs some way to figure out which HTTP methods are supported by the web server that is being examined. The OPTIONS HTTP method provides the tester with the most direct and effective way to do that. RFC 2616 states that, “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.

Execution of a test-script only highlights the TRACE method as risky:

The same test can also be executed using nmap and the http-methods NSE script:

C:\Tools\nmap-6.40>nmap -p 443 --script http-methods localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2015-11-04 11:52 Romance Standard Time

Nmap scan report for localhost (127.0.0.1)
Host is up (0.0094s latency).
PORT    STATE SERVICE
443/tcp open  https
| http-methods: OPTIONS TRACE GET HEAD POST
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html

Nmap done: 1 IP address (1 host up) scanned in 20.48 seconds

The rest of the OSWAP page discusses potential security problems (e.g. the potential of using TRACE to exfiltrate cookies tagged httpOnly into JavaScript), but does not talk of OPTIONS being a security concern.