Disable HTTP Options method

[archanaserver]

[ehelms]

I'm not sure I like enabling mod_security by default, especially for such a small thing. Could you elaborate why this is a good idea?

I am curious about both now: what about mod_security concerns you and if this is the most minimal solution to exclude OPTIONS.

[ekohl]

I suspect it has a performance impact (higher memory, more per request overhead). Perhaps that's neglible, but HTTP OPTIONS is also something I consider to not be a problem that needs solving in the first place

You can also look at Rails and Django middleware and <Limit> statements for the static HTTP side, but as I said: I never considered it to be relevant

[ekohl]

I should have cited some resources. https://security.stackexchange.com/questions/225325/is-the-http-method-options-secure-nowadays is one. If you have a method that tells you which of the 8 methods are supported (one of which could be abused), you can also just try those methods. It's also an open source application. You can open up the source or install it yourself to find out.

The only reason this is even a thing is that some security scanners think it's a thing and people must cross it off their list. Suddenly we'd need to make sure mod_security works. Which is a beast in itself. What if something breaks? Who's going to debug it? Perhaps some default rules that break some functionality. I don't think it's worth the effort and much rather have some knowledge base item we can refer to that we, as the vendor, don't support disabling OPTIONS and that they have to live with it

[ehelms]

These are great points. And I agree the OPTIONS being a vulnerability is questionable given the open source nature of our project and the fact that it doesn't prevent an attacker from finding out just can slow them down.

I was wondering if we should attack this at the application layer? For Rails / Rack, I saw that the rack-cors gem can be used to limit the available methods, e.g. (from their README):

# config/initializers/cors.rb

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'
    resource '*', headers: :any, methods: [:get, :post, :patch, :put]
  end
end

I do not know if this prevents Apache from presenting it and triggering the scanners.

[archanaserver]

Thank you, @ekohl and @ehelms, for your valuable insights on this matter.

Considering the potential performance impact of enabling mod_security and the uncertainties surrounding the effectiveness of an application-level approach to address the HTTP OPTIONS vulnerability, I am committed to exploring alternative solutions, that is to implementing security measures at the application layer. Also do some more research on other solutions.

Your suggestion to implement security measures at the application layer is intriguing. Do you have any references or resources you could recommend for further investigation into this approach?

[ehelms]

Your suggestion to implement security measures at the application layer is intriguing. Do you have any references or resources you could recommend for further investigation into this approach?

I don't have a single great resource here since it's application specific and depends on the needs of the application. If we did do it at the application level, we'd have to make sure all our apps did it (e.g. Pulp, smart-proxy, etc) which greatly expands the scope. I am leaning towards @ekohl view that we just go with we do not support disabling this.

[ehelms]

We have decided not to implement this due to the reasons stated above.