You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ted Anagnost <an...@comcast.net> on 2005/03/02 07:21:53 UTC
Re: How to disable PUT, DELETE http methods etc if not using container managed security?
Thanks Bill but I'm not sure it's working.
Per your suggestion here's what I have now:
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Context</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>HEAD</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>TRACE</http-method>
<http-method>OPTIONS</http-method>
</web-resource-collection>
<auth-constraint />
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Context</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<!-- auth-constraint goes here if you requre authentication -->
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
But, how do I verify that PUT's and DELETE's are blocked now? My
vulnerability scanner still shows them as open:
"It seems that the PUT method is enabled on your web server
Although we could not exploit this, you'd better disable it
Solution : disable this method
Risk factor : High
BID : 12141"
If I try to delete index.jsp through a telnet session:
DELETE /index.jsp HTTP/1.1
I get this as a response:
HTTP/1.1 400 Bad Request
What's a good way to verify that DELETE is blocked? Can someone give a
definitive test?
Thanks
----- Original Message -----
From: "Bill Barker" <wb...@wilshire.com>
To: <to...@jakarta.apache.org>
Sent: Saturday, February 26, 2005 3:33 PM
Subject: Re: How to disable PUT, DELETE http methods etc if not using
container managed security?
> For TC 5.x.x, you need two security-constraints to do what you want. One
> of them looks like your first example, and the other like your second
> example (except that you probably want <auth-constraint />, which is "deny
> all", instead of <role-name/> which is deny to all but the blank role).
> Since you are forbidding all access, you could also drop the
> <user-data-constraint> on the second one (since with it, TC will first
> redirect a PUT to SSL, and then deny it).
>
> "Ted Anagnost" <an...@comcast.net> wrote in message
> news:004101c51bcf$8c184c30$6401a8c0@blobofi...
> Is there a way to prevent PUT or DELETE http methods if you're not using
> container managed security? If so, how?
>
> I already have this to force the use of https:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Protected Context</web-resource-name>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <!-- auth-constraint goes here if you requre authentication -->
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
> What changes are needed? I tried this but it didn't seem to work:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Protected Context</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>HEAD</http-method> <----------------------------------
> <http-method>PUT</http-method>
> <----------------------------------
> <http-method>DELETE</http-method> <----------------------------------
> <http-method>TRACE</http-method> <----------------------------------
> <http-method>OPTIONS</http-method> <----------------------------------
> </web-resource-collection>
> <auth-constraint>
> <role-name></role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
> Inserting these statements seems to turn off the automatic enforcement of
> https which was achieved with the first version.
>
> Any ideas? Thanks
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: How to disable PUT, DELETE http methods etc if not using container managed security?
Posted by Bill Barker <wb...@wilshire.com>.
Sorry, I blanked on this one. You also need the
<http-method>GET</http-method> etc on the second (SSL) constraint. It's a
pain, but the servlet-spec says you get the least restrictive combination of
constraints.
"Ted Anagnost" <an...@comcast.net> wrote in message
news:001001c51ef0$21f3fe70$6401a8c0@blobofi...
> Thanks Bill but I'm not sure it's working.
>
> Per your suggestion here's what I have now:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Protected Context</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>HEAD</http-method>
> <http-method>PUT</http-method>
> <http-method>DELETE</http-method>
> <http-method>TRACE</http-method>
> <http-method>OPTIONS</http-method>
> </web-resource-collection>
> <auth-constraint />
> </security-constraint>
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Protected Context</web-resource-name>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <!-- auth-constraint goes here if you requre authentication -->
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
> But, how do I verify that PUT's and DELETE's are blocked now? My
> vulnerability scanner still shows them as open:
>
> "It seems that the PUT method is enabled on your web server
> Although we could not exploit this, you'd better disable it
>
> Solution : disable this method
> Risk factor : High
> BID : 12141"
>
> If I try to delete index.jsp through a telnet session:
>
> DELETE /index.jsp HTTP/1.1
>
> I get this as a response:
>
> HTTP/1.1 400 Bad Request
>
> What's a good way to verify that DELETE is blocked? Can someone give a
> definitive test?
>
> Thanks
>
>
>
>
> ----- Original Message -----
> From: "Bill Barker" <wb...@wilshire.com>
> To: <to...@jakarta.apache.org>
> Sent: Saturday, February 26, 2005 3:33 PM
> Subject: Re: How to disable PUT, DELETE http methods etc if not using
> container managed security?
>
>
>> For TC 5.x.x, you need two security-constraints to do what you want. One
>> of them looks like your first example, and the other like your second
>> example (except that you probably want <auth-constraint />, which is
>> "deny all", instead of <role-name/> which is deny to all but the blank
>> role). Since you are forbidding all access, you could also drop the
>> <user-data-constraint> on the second one (since with it, TC will first
>> redirect a PUT to SSL, and then deny it).
>>
>> "Ted Anagnost" <an...@comcast.net> wrote in message
>> news:004101c51bcf$8c184c30$6401a8c0@blobofi...
>> Is there a way to prevent PUT or DELETE http methods if you're not using
>> container managed security? If so, how?
>>
>> I already have this to force the use of https:
>>
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name>Protected Context</web-resource-name>
>> <url-pattern>/*</url-pattern>
>> </web-resource-collection>
>> <!-- auth-constraint goes here if you requre authentication -->
>> <user-data-constraint>
>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>> </user-data-constraint>
>> </security-constraint>
>>
>> What changes are needed? I tried this but it didn't seem to work:
>>
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name>Protected Context</web-resource-name>
>> <url-pattern>/*</url-pattern>
>> <http-method>HEAD</http-method> <----------------------------------
>> <http-method>PUT</http-method> <----------------------------------
>> <http-method>DELETE</http-method> <----------------------------------
>> <http-method>TRACE</http-method> <----------------------------------
>> <http-method>OPTIONS</http-method> <----------------------------------
>> </web-resource-collection>
>> <auth-constraint>
>> <role-name></role-name>
>> </auth-constraint>
>> <user-data-constraint>
>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>> </user-data-constraint>
>> </security-constraint>
>>
>> Inserting these statements seems to turn off the automatic enforcement of
>> https which was achieved with the first version.
>>
>> Any ideas? Thanks
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org