Re: How to disable PUT, DELETE http methods etc if not using container managed security?
Sorry, I blanked on this one. You also need the http-methodGET/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 [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method http-methodPUT/http-method http-methodDELETE/http-method http-methodTRACE/http-method http-methodOPTIONS/http-method /web-resource-collection auth-constraint / /security-constraint security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/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-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/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-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method -- http-methodPUT/http-method -- http-methodDELETE/http-method -- http-methodTRACE/http-method-- http-methodOPTIONS/http-method -- /web-resource-collection auth-constraint role-name/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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]
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-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method http-methodPUT/http-method http-methodDELETE/http-method http-methodTRACE/http-method http-methodOPTIONS/http-method /web-resource-collection auth-constraint / /security-constraint security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/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-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/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-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method -- http-methodPUT/http-method -- http-methodDELETE/http-method -- http-methodTRACE/http-method-- http-methodOPTIONS/http-method -- /web-resource-collection auth-constraint role-name/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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]
Re: How to disable PUT, DELETE http methods etc if not using container managed security?
transport-guaranteeCONFIDENTIAL/transport-guarantee means that request must be encrypted (use ssl) Unless the default servlet (in conf/web.xml) is configured to allow put and delete - there is not worry. (As long as your don't write any servlets to handle put and delete) -Tim Ted Anagnost wrote: 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-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/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-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method -- http-methodPUT/http-method-- http-methodDELETE/http-method -- http-methodTRACE/http-method-- http-methodOPTIONS/http-method -- /web-resource-collection auth-constraint role-name/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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]
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-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/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-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method -- http-methodPUT/http-method-- http-methodDELETE/http-method -- http-methodTRACE/http-method-- http-methodOPTIONS/http-method -- /web-resource-collection auth-constraint role-name/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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]
How to disable PUT, DELETE http methods etc if not using container managed security?
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-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/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-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method -- http-methodPUT/http-method-- http-methodDELETE/http-method -- http-methodTRACE/http-method-- http-methodOPTIONS/http-method -- /web-resource-collection auth-constraint role-name/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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
Re: disable put, delete
It should already be disabled. See the configuration of the DefaultServlet in $CATALINA_HOME/conf/web.xml -Tim Ben Kim wrote: I'm running 5.0.28 and when I ran nessus scan, it gives me a warning about put and delete methods. I'm not sure how I should take it... It seems it's not applicable but nessus still gives the warning. Could anyone advise whether tomcat configuration needs to be fixed, and then how? (The BID was not straightforward to me.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: disable put, delete
It should already be disabled. See the configuration of the DefaultServlet in $CATALINA_HOME/conf/web.xml I'd appreciate more advice. I've tested it myself and it didn't work. My nessus also says it could not exploit it but recommends I disable it. Here's my DefaultServlet section, all surrounded by !-- -- line by line, from the $CATALINA_HOME/conf/web.xml. Am I right to interpret this as saying that readonly is [true] by default (hence commented out) for DefaultServlet, so that any DELETE or PUT attempt is rejected? === The default servlet for all web applications, that serves static servlets with servlet mappings (defined either here or in your own web.xml file. This servlet supports the following initialization parameters (default values are in square brackets): ... readonly Is this context read only, so HTTP commands like PUT and DELETE are rejected? [true] So, could I say it's been already disabled in 5.0.28 and nessus's finding is wrong? I need to either correct this problem, or submit an explanation of why it is not necessary, to my security folks, so would appreciate some kind of confirmation from anyone knowledgeable. Thanks, Ben Kim Database Developer/Systems Administrator 434E Harrington Tower / College of Education Texas AM University - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: disable put, delete
If readonly is set to true, then PUT and DELETE are disabled. The scanning tool might be expecting a differnet HTTP status code when trying to exploit PUT and DELETE. -Tim Ben Kim wrote: It should already be disabled. See the configuration of the DefaultServlet in $CATALINA_HOME/conf/web.xml I'd appreciate more advice. I've tested it myself and it didn't work. My nessus also says it could not exploit it but recommends I disable it. Here's my DefaultServlet section, all surrounded by !-- -- line by line, from the $CATALINA_HOME/conf/web.xml. Am I right to interpret this as saying that readonly is [true] by default (hence commented out) for DefaultServlet, so that any DELETE or PUT attempt is rejected? === The default servlet for all web applications, that serves static servlets with servlet mappings (defined either here or in your own web.xml file. This servlet supports the following initialization parameters (default values are in square brackets): ... readonly Is this context read only, so HTTP commands like PUT and DELETE are rejected? [true] So, could I say it's been already disabled in 5.0.28 and nessus's finding is wrong? I need to either correct this problem, or submit an explanation of why it is not necessary, to my security folks, so would appreciate some kind of confirmation from anyone knowledgeable. Thanks, Ben Kim Database Developer/Systems Administrator 434E Harrington Tower / College of Education Texas AM University - 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]
Re: disable put, delete
Thanks. On Fri, 18 Feb 2005, Tim Funk wrote: If readonly is set to true, then PUT and DELETE are disabled. The scanning tool might be expecting a differnet HTTP status code when trying to exploit PUT and DELETE. -Tim Ben Kim wrote: It should already be disabled. See the configuration of the DefaultServlet in $CATALINA_HOME/conf/web.xml I'd appreciate more advice. I've tested it myself and it didn't work. My nessus also says it could not exploit it but recommends I disable it. Here's my DefaultServlet section, all surrounded by !-- -- line by line, from the $CATALINA_HOME/conf/web.xml. Am I right to interpret this as saying that readonly is [true] by default (hence commented out) for DefaultServlet, so that any DELETE or PUT attempt is rejected? === The default servlet for all web applications, that serves static servlets with servlet mappings (defined either here or in your own web.xml file. This servlet supports the following initialization parameters (default values are in square brackets): ... readonly Is this context read only, so HTTP commands like PUT and DELETE are rejected? [true] So, could I say it's been already disabled in 5.0.28 and nessus's finding is wrong? I need to either correct this problem, or submit an explanation of why it is not necessary, to my security folks, so would appreciate some kind of confirmation from anyone knowledgeable. Thanks, Ben Kim Database Developer/Systems Administrator 434E Harrington Tower / College of Education Texas AM University - 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] Regards, Ben Kim Database Developer/Systems Administrator 434E Harrington Tower / College of Education Texas AM University - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
disable put, delete
I'm running 5.0.28 and when I ran nessus scan, it gives me a warning about put and delete methods. I'm not sure how I should take it... It seems it's not applicable but nessus still gives the warning. Could anyone advise whether tomcat configuration needs to be fixed, and then how? (The BID was not straightforward to me.) Regards, Ben Kim Database Developer/Systems Administrator 434E Harrington Tower / College of Education Texas AM University - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
disable put, delete (fwd)
P.S. It's redhat 9 and the warnings come only on 8443 not on 8080. Regards, Ben Kim Database Developer/Systems Administrator 434E Harrington Tower / College of Education Texas AM University -- Forwarded message -- Date: Fri, 18 Feb 2005 01:13:56 -0600 (CST) From: Ben Kim [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Subject: disable put, delete I'm running 5.0.28 and when I ran nessus scan, it gives me a warning about put and delete methods. I'm not sure how I should take it... It seems it's not applicable but nessus still gives the warning. Could anyone advise whether tomcat configuration needs to be fixed, and then how? (The BID was not straightforward to me.) Regards, Ben Kim Database Developer/Systems Administrator 434E Harrington Tower / College of Education Texas AM University - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
