Re: How to disable PUT, DELETE http methods etc if not using container managed security?

2005-03-03 Thread Bill Barker
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?

2005-03-01 Thread Ted Anagnost
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?

2005-02-26 Thread Tim Funk
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?

2005-02-26 Thread Bill Barker
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?

2005-02-25 Thread Ted Anagnost
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