Disabling PUT and DELETE methods in Tomcat 5 standalone
Running Nessus against our server (Debian Woody + standalone Tomcat 5.0.18) produces a security warning that the PUT and DELETE http methods are enabled in Tomcat. Although these warning were not exploitable, I really need to ensure that these 2 methods are completely disabled. I've spent a good while looking into this, and this is where I'm at so far - I've placed the following in $CATALINA_HOME/conf/web.xml Disable Methods /* PUT DELETE I was under the impression that by not including a value, then all PUT and DELETE method requests are disabled since the security constraint cannot be linked to a role. However, the fact that it doesn't work yet means I'm doing something wrong somewhere! Any guidance is very much appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling PUT and DELETE methods in Tomcat 5 standalone
On 03/08/2004 10:15 AM funkster wrote: Disable Methods /* PUT DELETE I was under the impression that by not including a value, then all PUT and DELETE method requests are disabled since the security constraint cannot be linked to a role. However, the fact that it doesn't work yet means I'm doing something wrong somewhere! Well, you haven't disabled it. You have protected it. As far as I can tell, you would be required to login first, and then you would be denied access. (When tomcat finds out that you are not in no roles?!) Adam -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling PUT and DELETE methods in Tomcat 5 standalone
So, how would I go about actually prevent PUT and DELETE for all users, logged in or otherwise? I've been hitting my head against this one for some time, with no luck. The solution needs to allow anonymous users to access the site (i.e. no login) and still prevent PUT and DELETE methods. Thanks, James > On 03/08/2004 10:15 AM funkster wrote: > > > > > > Disable Methods > > /* > > PUT > > DELETE > > > > > > > > > > > > > > I was under the impression that by not including a value, then > > all PUT and DELETE method requests are disabled since the security > > constraint cannot be linked to a role. However, the fact that it doesn't > > work yet means I'm doing something wrong somewhere! > > Well, you haven't disabled it. You have protected it. As far as I can > tell, you would be required to login first, and then you would be denied > access. (When tomcat finds out that you are not in no roles?!) > > Adam > -- > struts 1.1 + tomcat 5.0.16 + java 1.4.2 > Linux 2.4.20 Debian > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling PUT and DELETE methods in Tomcat 5 standalone
What I was implying is that you have effectively disabled it already this way. Or are you able to do PUTs and DELETEs despite the security constraint? I'd be surprised. Adam On 03/08/2004 11:24 PM James Agnew wrote: So, how would I go about actually prevent PUT and DELETE for all users, logged in or otherwise? I've been hitting my head against this one for some time, with no luck. The solution needs to allow anonymous users to access the site (i.e. no login) and still prevent PUT and DELETE methods. Thanks, James On 03/08/2004 10:15 AM funkster wrote: Disable Methods /* PUT DELETE I was under the impression that by not including a value, then all PUT and DELETE method requests are disabled since the security constraint cannot be linked to a role. However, the fact that it doesn't work yet means I'm doing something wrong somewhere! Well, you haven't disabled it. You have protected it. As far as I can tell, you would be required to login first, and then you would be denied access. (When tomcat finds out that you are not in no roles?!) Adam -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Disabling PUT and DELETE methods in Tomcat 5 standalone
You've disabled it in the sense that no matter what you type in, you will not be allowed in, but it's not a blackhole or tarpit situation (ie: the server does NOT respond in ANY way to a PUT or DELETE request). In the case of configuring a null role, the server still responds with an authorization request. > -Original Message- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Monday, March 08, 2004 4:40 PM > To: Tomcat Users List > Subject: Re: Disabling PUT and DELETE methods in Tomcat 5 standalone > > > What I was implying is that you have effectively disabled it already > this way. > > Or are you able to do PUTs and DELETEs despite the security > constraint? > I'd be surprised. > > Adam > > On 03/08/2004 11:24 PM James Agnew wrote: > > So, how would I go about actually prevent PUT and DELETE for all > > users, logged in or otherwise? I've been hitting my head > against this > > one for some time, with no luck. The solution needs to allow > > anonymous users to access the site (i.e. no login) and > still prevent > > PUT and DELETE methods. > > > > Thanks, James > > > > > > > > > >>On 03/08/2004 10:15 AM funkster wrote: > >> > >>> > >>> > >>>Disable Methods > >>>/* > >>>PUT > >>>DELETE > >>> > >>> > >>> > >>> > >>> > >>> > >>>I was under the impression that by not including a > value, > > > > then > > > >>>all PUT and DELETE method requests are disabled since the security > >>>constraint cannot be linked to a role. However, the fact that it > >>>doesn't work yet means I'm doing something wrong somewhere! > >> > >>Well, you haven't disabled it. You have protected it. As > far as I can > >>tell, you would be required to login first, and then you would be > >>denied access. (When tomcat finds out that you are not in > no roles?!) > >> > >>Adam > >>-- > >>struts 1.1 + tomcat 5.0.16 + java 1.4.2 > >>Linux 2.4.20 Debian > >> > >> > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > struts 1.1 + tomcat 5.0.16 + java 1.4.2 > Linux 2.4.20 Debian > > > - > 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: Disabling PUT and DELETE methods in Tomcat 5 standalone
There's no implementation of the servlet doPut() and doDelete() methods so nothing can actually be put or deleted, but that's true before even creating the security constraint. Yet, testing for PUT and DELETE methods still show that they're enabled. Our security scanners still flag these methods as being available, albeit not exploitable. Is there any way to prevent the server from responding to these methods? I ran the same scan tests on one of our Apache boxes and it can back complete dead on the PUT and DELETE methods i.e. it didn't respond in any way - that's the behaviour we're looking for. Would the same not be possible on Tomcat standalone? Thanks, David - Original Message - From: "Adam Hardy" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Monday, March 08, 2004 11:39 PM Subject: Re: Disabling PUT and DELETE methods in Tomcat 5 standalone > What I was implying is that you have effectively disabled it already > this way. > > Or are you able to do PUTs and DELETEs despite the security constraint? > I'd be surprised. > > Adam > > On 03/08/2004 11:24 PM James Agnew wrote: > > So, how would I go about actually prevent PUT and DELETE for all users, > > logged in or otherwise? I've been hitting my head against this one for some > > time, with no luck. The solution needs to allow anonymous users to access > > the site (i.e. no login) and still prevent PUT and DELETE methods. > > > > Thanks, James > > > > > > > > > >>On 03/08/2004 10:15 AM funkster wrote: > >> > >>> > >>> > >>>Disable Methods > >>>/* > >>>PUT > >>>DELETE > >>> > >>> > >>> > >>> > >>> > >>> > >>>I was under the impression that by not including a value, > > > > then > > > >>>all PUT and DELETE method requests are disabled since the security > >>>constraint cannot be linked to a role. However, the fact that it doesn't > >>>work yet means I'm doing something wrong somewhere! > >> > >>Well, you haven't disabled it. You have protected it. As far as I can > >>tell, you would be required to login first, and then you would be denied > >>access. (When tomcat finds out that you are not in no roles?!) > >> > >>Adam > >>-- > >>struts 1.1 + tomcat 5.0.16 + java 1.4.2 > >>Linux 2.4.20 Debian > >> > >> > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > struts 1.1 + tomcat 5.0.16 + java 1.4.2 > Linux 2.4.20 Debian > > > - > 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: Disabling PUT and DELETE methods in Tomcat 5 standalone
Hi, >Is there any way to prevent the server from responding to these methods? I >ran the same scan tests on one of our Apache boxes and it can back complete >dead on the PUT and DELETE methods i.e. it didn't respond in any way - >that's the behaviour we're looking for. Would the same not be possible on >Tomcat standalone? Please define "completely dead" more specifically: did your scans time out? Return with a 404 error? Another HTTP response code? You can do a variety of things, depending on how portable you want to be. I like the security-constraint approach. Another possibility is a simple filter (javax.servlet.Filter, portable) or Valve (tomcat-specific, but earlier in the request processing pipeline which might be key for you, and also slightly more performant), which simply checks the request method (HttpServletRequest#getMethod) and rejects the request if needed in whatever way you prefer. Going further down the customization path would be modifying the Coyote connector itself to reject requests with certain methods. This would be a generalization of the current allowTrace functionality. If you do a nice patch for this feel free to suggest it back to us as an enhancement ;) Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
