RE: Disabling PUT and DELETE methods in Tomcat 5 standalone

2004-03-09 Thread Shapira, Yoav

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]



Re: Disabling PUT and DELETE methods in Tomcat 5 standalone

2004-03-08 Thread Adam Hardy
On 03/08/2004 10:15 AM funkster wrote:
security-constraint
web-resource-collection
web-resource-nameDisable Methods/web-resource-name
url-pattern/*/url-pattern
http-methodPUT/http-method
http-methodDELETE/http-method
/web-resource-collection
auth-constraint
role-name/role-name
/auth-constraint
/security-constraint
I was under the impression that by not including a role-name 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

2004-03-08 Thread James Agnew
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:
  security-constraint
  web-resource-collection
  web-resource-nameDisable Methods/web-resource-name
  url-pattern/*/url-pattern
  http-methodPUT/http-method
  http-methodDELETE/http-method
  /web-resource-collection
  auth-constraint
  role-name/role-name
  /auth-constraint
  /security-constraint
 
  I was under the impression that by not including a role-name 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

2004-03-08 Thread Adam Hardy
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:

   security-constraint
   web-resource-collection
   web-resource-nameDisable Methods/web-resource-name
   url-pattern/*/url-pattern
   http-methodPUT/http-method
   http-methodDELETE/http-method
   /web-resource-collection
   auth-constraint
   role-name/role-name
   /auth-constraint
   /security-constraint
I was under the impression that by not including a role-name 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

2004-03-08 Thread Mike Curwen
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:
 
 security-constraint
 web-resource-collection
 web-resource-nameDisable Methods/web-resource-name
 url-pattern/*/url-pattern
 http-methodPUT/http-method
 http-methodDELETE/http-method
 /web-resource-collection
 auth-constraint
 role-name/role-name
 /auth-constraint
 /security-constraint
 
 I was under the impression that by not including a 
 role-name 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

2004-03-08 Thread James Agnew
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:
 
 security-constraint
 web-resource-collection
 web-resource-nameDisable Methods/web-resource-name
 url-pattern/*/url-pattern
 http-methodPUT/http-method
 http-methodDELETE/http-method
 /web-resource-collection
 auth-constraint
 role-name/role-name
 /auth-constraint
 /security-constraint
 
 I was under the impression that by not including a role-name 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]



Disabling PUT and DELETE methods in Tomcat 5 standalone

2004-03-08 Thread funkster
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

security-constraint
web-resource-collection
web-resource-nameDisable Methods/web-resource-name
url-pattern/*/url-pattern
http-methodPUT/http-method
http-methodDELETE/http-method
/web-resource-collection
auth-constraint
role-name/role-name
/auth-constraint
/security-constraint

I was under the impression that by not including a role-name 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]