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" <[EMAIL PROTECTED]>
To: <tomcat-user@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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
