Cannot disable HTTP OPTIONS Method

[somayedubati]

Please assist us for Disable HTTP OPTIONS Method in Jetty-9.4.18.20190429. We are getting this as a Moderate Vulnerability in the scans. Jetty is part of the product we are using the Job Scheduler JOC Cockpit Version 1.13.8.

Thanks and appreciate your help!

[joakime]

Specify the constraints in the WEB-INF/web.xml to disable OPTIONS.

  <!-- ==================================================================== -->
  <!-- Disable OPTIONS method with security constraint                        -->
  <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  -->
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Disable OPTIONS</web-resource-name>
      <url-pattern>/</url-pattern>
      <http-method>OPTIONS</http-method>
    </web-resource-collection>
    <auth-constraint/>
  </security-constraint>
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Enable everything but OPTIONS</web-resource-name>
      <url-pattern>/</url-pattern>
      <http-method-omission>OPTIONS</http-method-omission>
    </web-resource-collection>
  </security-constraint>

[somayedubati]

thanks a lot for your assistance! I will update the web.xml and let you know if any issues.

[sbordet]

@somayedubati please note that OPTIONS is a required method to support CORS for browsers -- make sure applications deployed in Jetty does not need to support CORS.

[somayedubati]

@sbordet Thanks for your inputs! We will review and make sure that CORS support needed or not before deployment.

[somayedubati]

@joakime, I updated the web.xml file but still showing the HTTP OPTIONS as a Vulnerability. do you have any suggestions?
Thanks for your assistance!

[janbartel]

@somayedubati the url-pattern should probably be /*, not just /: /* will cover all urls in your webapp, whilst / will only apply to the root page.

[gregw]

The problem could be with a OPTIONS * HTTP/1.1 request. We pass this first to a Server.handleOptions method and if that does nothing, then we do try to handle normally, but I'm not sure how a URI of * will be routed. Testing now.

[somayedubati]

@janbartel and @gregw , thanks for your assistance!
I tried to give both / and /* options and did not help.
@gregw , thanks for testing on your end.

[gregw]

@somayedubati Do you know if the check is sending an OPTIONS * HTTP/1.0 request?
Currently I see that we will route such a request to the root context. Not sure how we could match *? Investigating more....

[gregw]

@somayedubati can you try with no url-pattern element at all?

[gregw]

@somayedubati We have tested the suggestion of @joakime and it is working for us, but it must be on the root context.
However, we have found some other problem with uncovered path warnings.

So perhaps you can try just adding:

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Disable OPTIONS</web-resource-name>
      <url-pattern>/</url-pattern>
      <http-method>OPTIONS</http-method>
    </web-resource-collection>
    <auth-constraint/>
  </security-constraint>

This may deploy with a warning, but should work.

[sbordet]

@somayedubati I would also question the tool you are using that reports OPTIONS as a moderate vulnerability.

OPTIONS is a legit HTTP method, it is heavily used in CORS and therefore important and necessary.

Reporting OPTIONS as moderate vulnerability would be like reporting GET as a moderate vulnerability, in general.

Maybe OPTIONS is reported as moderate vulnerability because your application responds to OPTIONS requests in the wrong way?

[somayedubati]

@gregw , I was using the following based upon application of context. I was getting Forbidden if I use "/" as a context. I will try the new snippet and let you know.

<security-constraint>
<web-resource-collection>
  <web-resource-name>Disable OPTIONS</web-resource-name>
  <url-pattern>/api/*</url-pattern>
  <http-method>OPTIONS</http-method>
</web-resource-collection>
<auth-constraint/>
</security-constraint>
<security-constraint>
<web-resource-collection>
  <web-resource-name>Enable everything but OPTIONS</web-resource-name>
  <url-pattern>/api/*</url-pattern>
  <http-method-omission>OPTIONS</http-method-omission>
 </web-resource-collection>
</security-constraint>

[somayedubati]

@sbordet , I will find out HTTP OPTIONS using. Thanks

[joakime]

It could be a misinterpretation of the report from your security tool.

The OPTIONS method is very much a required feature for nearly all modern browsers.
Please dig into the reason for that report, as it's probably something the tool is expecting in the response headers that isn't present.

[gregw]

@janbartel and I have found an issue with this. The main constraint to block OPTIONS works fine, but there is a problem combining the omitted methods as we already have the following in defaultweb.xml:

  <security-constraint>
    <web-resource-collection>
      <url-pattern>/</url-pattern>
      <http-method-omission>TRACE</http-method-omission>
    </web-resource-collection>
  </security-constraint>

There is some strangeness in how the TRACE and OPTIONS omission constraints are merged. However, we do believe that the following will be sufficient to block all OPTIONS methods unless matched by some other more specific constraint that includes OPTIONS:

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Disable OPTIONS</web-resource-name>
      <url-pattern>/</url-pattern>
      <http-method>OPTIONS</http-method>
    </web-resource-collection>
    <auth-constraint/>
  </security-constraint>