Skip to main content

How to disable OPTIONS method or at least have it report correct Allow

4 replies [Last post]
hotngui
Offline
Joined: 2006-03-14

We have several customers who are paranoid about their security and are running vulnerability tests against our application which is using Glassfish v3.0.1. They are complaining about methods like 'OPTIONS / HTTP/1.0' are showing that all the methods (GET,POST,PUT,DELETE,TRACE,OPTIONS) are allowed.

In reality TRACE is disabled via the attribute trace-enabled="false".
And the PUT and DELETE methods appear to be magically disabled.

But to satisfy these folks I really need to either have OPTIONS report the correct "Allows" or have OPTIONS disabled.

I have tried using the following constraint which points to a non-existent role in my default-web.xml file but it appears to have no affect.

SecureIt
/*
PUT
OPTIONS
DELETE
TRACE

NoOne

Any clues, suggestions, pointers?
Joey

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
swchan2
Offline
Joined: 2005-03-29

If you put the security constraint in default-web.xml or web.xml in the war and "redeploy" the application, then it will work for the given web application.
There is an issue for the docroot. We are investigating this now.

hotngui
Offline
Joined: 2006-03-14

Maybe I am getting the URL pattern wrong or something, but I cannot get the security-constraint to affect anything. Am trying it in the default-web.xml file.

swchan2
Offline
Joined: 2005-03-29

After changing the default-web.xml, then you "need to redeploy" the web application.
And the security-constraint will take effect in the given web application.
If you want the security-constraint apply to / (cf. docroot), then you need to set the default web module in this moment.

hotngui
Offline
Joined: 2006-03-14

I am using the embedded glassfish and deploying my web applications programmatically. Every web app is completely deployed each time my server application starts.

This also means that I cannot assign a default web module in the domain.xml file since its unknown until runtime. Plus we do indeed keep a few static pages at "/" so it would impossible to a default web module to replace "/".

joey