You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Stephan Fletcher <sf...@bohrensmoving.com> on 2014/01/23 15:57:28 UTC
Deny Put & Delete
Can anyone tell me how to fix the following in my Tomcat config. I'm using Apache Tomcat 7.0.30 and I'm failing on the following PCI Security scans.
1. Title: Web server allows PUT: /
Impact: An attacker may be able to upload files onto the web server.
Data Received: Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
Resolution: Configure the web server not to accept PUT requests. If you require the functionality of PUT for web publishing, use a put script which can only be run by authorized users, which ensures that the script can update only web content files, and which ensures that users can only update their own pages
2. Title: Web server allows HTTP method DELETE
Impact: The HTTP DELETE method may allow an attacker to delete arbitrary content from the Web Server.
Data Received: Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
Resolution: Disable the DELETE method in the Web Server configuration. If this is not an option, use one of the following workarounds:
Apache: Disable the DELETE method by including the following in the Apache configuration:
<Limit DELETE> Order Deny, Allow Deny from All& lt;/Limit>
Any help would be greatly appreciated
Stephan Fletcher
Manager of Information Services
Bohren's Moving & Storage
Docusafe Records Management
3 Applegate Drive South
Robbinsville, NJ 08691
O: 609.208.1470
F: 609.208.1471
W: www.bohrensmoving.com<http://www.bohrensmoving.com/>
W: www.docusafe.com<http://www.docusafe.com/>
________________________________
Important Notice: This email is copyright of Bohrensmoving.com, and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. This footnote also confirms that this email message has been
swept for the presence of computer viruses.
Re: Deny Put & Delete
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Stephan,
On 1/23/14, 9:57 AM, Stephan Fletcher wrote:
> Can anyone tell me how to fix the following in my Tomcat config.
> I'm using Apache Tomcat 7.0.30 and I'm failing on the following PCI
> Security scans.
>
>
> 1. Title: Web server allows PUT: /
>
> Impact: An attacker may be able to upload files onto the web
> server.
>
> Data Received: Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
>
> Resolution: Configure the web server not to accept PUT requests. If
> you require the functionality of PUT for web publishing, use a put
> script which can only be run by authorized users, which ensures
> that the script can update only web content files, and which
> ensures that users can only update their own pages
>
>
> 2. Title: Web server allows HTTP method DELETE
>
> Impact: The HTTP DELETE method may allow an attacker to delete
> arbitrary content from the Web Server.
>
> Data Received: Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
>
> Resolution: Disable the DELETE method in the Web Server
> configuration. If this is not an option, use one of the following
> workarounds:
>
> Apache: Disable the DELETE method by including the following in the
> Apache configuration:
>
> <Limit DELETE> Order Deny, Allow Deny from All&
> lt;/Limit>
>
>
> Any help would be greatly appreciated
IIRC, Tomcat-compiled JSP scripts used to respond to every kind of
HTTP verb, including things that weren't standard at all (like
HELLO!). I believe that was fixed a while back -- not sure when... I
can't seem to find anything in the change log for Tomcat 7, so maybe
that was a long long time ago.
I just tried OPTIONS on 7.0.47 to a random JSP and it responded by
actually running the JSP in standard "GET"-style mode. Actually... I
ran it like this:
$ openssl s_client -connect myhost:443
HELLO /path/test.jsp HTTP/1.1
Connection: close
Host: myhost
[CRLF]
... and my JSP ran. That's a little surprising but definitely not
dangerous. PUT and DELETE do the same thing: just run the JSP as usual.
Mark's response is probably the more accurate: your vulnerability
scanner is just too lazy to find an actual vulnerability but just
reports that you are insecure because of a zero-research response it
got to a single request.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS4TdVAAoJEBzwKT+lPKRYLw4QAKt2hvJdEHsIf6isho9aDijx
WwdDaZftdKll6KSPo7uosQ46aQ8SdNnl2+ZVCxzj09J1PM85lIky6Uit719cRtvi
8tP2X+NaiZkj/AqwVZtOi9qawgavwtbch3GW8rB9LPiCzZeimOvpUzcGaevGYoRp
tgsW9ZwMlY2bmJg2rxwxxqNyPJJ8iphtPz6+Kj6wTufU7pcU1wc8JtSasMw/C5rV
izCxIpNtnKcNQ8IEwky3epTAvaP9iEJIyVj9AUziUqZbNDVCm3IslSo5HpUQfjJR
4zVZHOpyL+fl9M5tghp632x9MuC7XtEnPxOW9ScOYe+6vqxac6hcQ2gw0nyc04n9
Yd2t5T/R47UkMwVZ7GCYiI6Ry/Gsnxl7Cly3W9REKC2Nlu5shCrlOANLXSAfEOoh
TbVMTUbOnp4bb4FS97Kq8eDtuffcVmEDotcewaLSvZtIvKBiuUTESdjUT7/mEUsA
ucgtNHv/OTY1LUw/B9uNJeoGD7+Srw5do2sD6nI+UV1vTmV/YGZoX/L1kbEN6uHP
qiOaQKdkJbwK8kgZPOYAeTevW7D4gaz0AU49ED3QBCSdEQaI9g0RdnumaiZqB65o
34sm6XLoIso5qKfH7HU6iBK9EL19KUsoCfW2CMOGVjFCkg1iKNjoiHvt96kCXxID
2F9z9bM7+vyfslH6aQVw
=ZdEc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Deny Put & Delete
Posted by André Warnier <aw...@ice-sa.com>.
Stephan Fletcher wrote:
> It's a third party that is running the scan.
On this list, please do not top-post.
Maybe another response :
There are regular reports on this list of similar "security scanners" which find what they
deem to be "security vulnerabilities". Consult the list archives for more info.
It turns out that in about 99% of the cases, the problem is with the security scanner
software, and not with any real vulnerability in Tomcat.
That explains the kind of responses that you have seen so far.
Such reports mostly cause a lot of worries and jumping around, to end up generally with
nothing to really worry about, apart from time lost for everyone.
That's why people get jumpy at such posts.
If you are in the middle, there is not much you can do about it, except be confident
enough to tell the originators of the report to please check their data, and explain why
they think that there is a security issue.
If it turns out that there is a real security issue, explained in more detail than just
claiming that there is one, it will be tackled with urgency by the Tomcat developers.
>
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> Sent: Thursday, January 23, 2014 10:05 AM
> To: Tomcat Users List
> Subject: Re: Deny Put & Delete
>
> On 23/01/2014 14:57, Stephan Fletcher wrote:
>> Any help would be greatly appreciated
>
> <rant>
> Buy a better vulnerability scanner. Specifically, one understands that an OPTIONS request returns the methods that are *available* not the methods that are *permitted*.
> </rant>
>
> Assuming you haven't changed Tomcat's default configuration any attempt to actually PUT or DELETE a resource will be denied.
>
> I have a recollection that we changed the implementation of the OPTIONS request to try and help with this sort of thing. Scratch that. That was for TRACE which won't be included in an OPTIONS response unless Tomcat can confirm that it has been explicitly enabled in the Connector.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ________________________________
>
> Important Notice: This email is copyright of Bohrensmoving.com, and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
>
> This email and any files transmitted with it are confidential and
>
> intended solely for the use of the individual or entity to whom they are
>
> addressed. This footnote also confirms that this email message has been
>
> swept for the presence of computer viruses.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Deny Put & Delete
Posted by Vicky B <vi...@gmail.com>.
Thanks neven,mark
On Sun, Jan 26, 2014 at 4:00 PM, Neven Cvetkovic
<ne...@gmail.com>wrote:
> On Sun, Jan 26, 2014 at 12:32 AM, Vicky B <vi...@gmail.com> wrote:
>
> > if I have a privilege to ask a question on this topic if can anyone help
> me
> > on how an user fire a put request or delete request ( I am not a hacker)
> > .All my life I just used post and get I never thought about these put and
> > delete, so if someone helps I would appreciate
> >
> >
> PUT and DELETE type of requests are regularly used in RESTful applications.
> So, any REST client would be able to send these type of requests, e.g.
> POSTER extension for Firefox, POSTMAN extension for Chrome, etc...
>
> Also, Mark mentioned CURL command line "URL client", e.g.
> curl -X "DELETE" http://www.somewebsite.here/page
> curl -X "PUT" http://www.somewebsite.here/page
>
> Good luck!
> Neven
>
--
*Thanks & Regards Vickyb*
Re: Deny Put & Delete
Posted by Neven Cvetkovic <ne...@gmail.com>.
On Sun, Jan 26, 2014 at 12:32 AM, Vicky B <vi...@gmail.com> wrote:
> if I have a privilege to ask a question on this topic if can anyone help me
> on how an user fire a put request or delete request ( I am not a hacker)
> .All my life I just used post and get I never thought about these put and
> delete, so if someone helps I would appreciate
>
>
PUT and DELETE type of requests are regularly used in RESTful applications.
So, any REST client would be able to send these type of requests, e.g.
POSTER extension for Firefox, POSTMAN extension for Chrome, etc...
Also, Mark mentioned CURL command line "URL client", e.g.
curl -X "DELETE" http://www.somewebsite.here/page
curl -X "PUT" http://www.somewebsite.here/page
Good luck!
Neven
Re: Deny Put & Delete
Posted by Mark Eggers <it...@yahoo.com>.
On 1/25/2014 9:32 PM, Vicky B wrote:
> if I have a privilege to ask a question on this topic if can anyone help me
> on how an user fire a put request or delete request ( I am not a hacker)
> .All my life I just used post and get I never thought about these put and
> delete, so if someone helps I would appreciate
>
>
> On Fri, Jan 24, 2014 at 4:29 PM, Johan Compagner <jc...@servoy.com>wrote:
>
>>>
>>>
>>> I've dealt with similar nonsensical "compliance scans" before, and
>>> my response was:
>>>
>>> "You believe you can PUT or DELETE files on this installation?"
>>>
>>> ** makes popcorn **
>>>
>>> "Please proceed. I'll sit here and watch. Take your time."
>>>
>>> Morons. Bane of productive peoples' existence.
>>>
>>> Also, a special place in hell for the writers of these "scanners"...
>>> </rant>
>>> --
>>>
>>>
>> Maybe even more stupid with this scanner could be that it only test for the
>> options request to see what it returns but does not do an actual test of it
>> really works?
>> Maybe i can have a server that only replies that it accepts a "GET" but
>> when i actually do fire a PUT or a DELETE the code does do something...
>>
>> johan
>>
>
>
>
1. install curl
2. man curl
Curl exists for Windows as well.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Deny Put & Delete
Posted by Vicky B <vi...@gmail.com>.
if I have a privilege to ask a question on this topic if can anyone help me
on how an user fire a put request or delete request ( I am not a hacker)
.All my life I just used post and get I never thought about these put and
delete, so if someone helps I would appreciate
On Fri, Jan 24, 2014 at 4:29 PM, Johan Compagner <jc...@servoy.com>wrote:
> >
> >
> > I've dealt with similar nonsensical "compliance scans" before, and
> > my response was:
> >
> > "You believe you can PUT or DELETE files on this installation?"
> >
> > ** makes popcorn **
> >
> > "Please proceed. I'll sit here and watch. Take your time."
> >
> > Morons. Bane of productive peoples' existence.
> >
> > Also, a special place in hell for the writers of these "scanners"...
> > </rant>
> > --
> >
> >
> Maybe even more stupid with this scanner could be that it only test for the
> options request to see what it returns but does not do an actual test of it
> really works?
> Maybe i can have a server that only replies that it accepts a "GET" but
> when i actually do fire a PUT or a DELETE the code does do something...
>
> johan
>
--
*Thanks & Regards Vickyb*
Re: Deny Put & Delete
Posted by Johan Compagner <jc...@servoy.com>.
>
>
> I've dealt with similar nonsensical "compliance scans" before, and
> my response was:
>
> "You believe you can PUT or DELETE files on this installation?"
>
> ** makes popcorn **
>
> "Please proceed. I'll sit here and watch. Take your time."
>
> Morons. Bane of productive peoples' existence.
>
> Also, a special place in hell for the writers of these "scanners"...
> </rant>
> --
>
>
Maybe even more stupid with this scanner could be that it only test for the
options request to see what it returns but does not do an actual test of it
really works?
Maybe i can have a server that only replies that it accepts a "GET" but
when i actually do fire a PUT or a DELETE the code does do something...
johan
Re: Deny Put & Delete
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hassan,
On 1/23/14, 11:08 AM, Hassan Schroeder wrote:
> On Thu, Jan 23, 2014 at 7:09 AM, Stephan Fletcher
> <sf...@bohrensmoving.com> wrote:
>> It's a third party that is running the scan.
>
> I've dealt with similar nonsensical "compliance scans" before, and
> my response was:
>
> "You believe you can PUT or DELETE files on this installation?"
>
> ** makes popcorn **
>
> "Please proceed. I'll sit here and watch. Take your time."
>
> Morons. Bane of productive peoples' existence.
>
> Also, a special place in hell for the writers of these
> "scanners"... </rant>
We should recommend that these folks file bugs against the scanner
software they use. That way, the customer can sit back and make
popcorn while the vendor fixes the bug.
Meh, they'll probably ignore it. They get paid whether the scan is
useful or not. I called-around looking for pen-testing outfits and
their prices were insanely low. I asked about their methodology and
they basically said they have a pen testing suite -- an automated
tool. I told them thanks for their time and never bothered engaging
any of them... I can run automated tools myself. Nessus just ain't
that expensive.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS4VHtAAoJEBzwKT+lPKRY8bIQAKiE3WQKH2Db/O/OYxsKGj9Q
2XmlJu0LPAwHrDxyvdHKZRbnHcqNimpoa04Ce5Gw6t/x+CSnmzCJ6Mzi7J0OPun6
xkTAV3dcMF6E/tp8lygeNzCpqiPexCjT0LBTWg1t+SkpeXJFcgck14ySEf2XwZfX
bym+wp33v6K899Qtmq9mdHEdtTpFpwsmDXIlieYBN0sFTmsquDv+OQC4wE1aSCdH
vaha+6TaUK6ua0mp//bOD9AkpPLYUp/N6OaxezfLxKo0vgk/iYeQ/eTiXhGI6Ngs
BsRLvwl4PX3QSkkje7YXvALbbPnOPik9/4/WBdtQYzYd70oVreWfoPKmg2jOA5Dw
aZuZxvOGM1shRmZ6nGEnLpTjhRedPDCs+/RpLDRfsG66qg+jy6IwSP916B+cUDF7
SPUA+cqBM/tMYHKMm5bDx5zrsyrlLZs1mh48iA6oC1awLl+XXDjN6il7gF657y0P
0jTCMuokR6Gyd/MPo/06MqPY7J2dRV/NPsSHk7ZkjII8BWcQq3a3m2xsjX0g9CD/
Bde6xgFtDV+lKA+SsOLUyrvbeFlLu96CQEvVmb9dKCr3frQ5Z8dOITvzYKo8+Kif
N1jlVIv6+1lymHJ9Yk8XFGyO7hKY50X9xTGbQQ6J7H9Fk9a0X78zcXzSuFCNrlfn
OfRMlLQQSqgmyUhUjaax
=B8vG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Deny Put & Delete
Posted by Hassan Schroeder <ha...@gmail.com>.
On Thu, Jan 23, 2014 at 7:09 AM, Stephan Fletcher
<sf...@bohrensmoving.com> wrote:
> It's a third party that is running the scan.
I've dealt with similar nonsensical "compliance scans" before, and
my response was:
"You believe you can PUT or DELETE files on this installation?"
** makes popcorn **
"Please proceed. I'll sit here and watch. Take your time."
Morons. Bane of productive peoples' existence.
Also, a special place in hell for the writers of these "scanners"...
</rant>
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Deny Put & Delete
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Stephan,
On 1/23/14, 10:09 AM, Stephan Fletcher wrote:
> It's a third party that is running the scan.
Then *they* need to verify that the problem is a false-positive (or
not.. it's certainly possible that your are open to a "DELETE /"
attack, but probably not.
- -chris
> -----Original Message----- From: Mark Thomas
> [mailto:markt@apache.org] Sent: Thursday, January 23, 2014 10:05
> AM To: Tomcat Users List Subject: Re: Deny Put & Delete
>
> On 23/01/2014 14:57, Stephan Fletcher wrote:
>> Any help would be greatly appreciated
>
> <rant> Buy a better vulnerability scanner. Specifically, one
> understands that an OPTIONS request returns the methods that are
> *available* not the methods that are *permitted*. </rant>
>
> Assuming you haven't changed Tomcat's default configuration any
> attempt to actually PUT or DELETE a resource will be denied.
>
> I have a recollection that we changed the implementation of the
> OPTIONS request to try and help with this sort of thing. Scratch
> that. That was for TRACE which won't be included in an OPTIONS
> response unless Tomcat can confirm that it has been explicitly
> enabled in the Connector.
>
> Mark
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ________________________________
>
> Important Notice: This email is copyright of Bohrensmoving.com, and
> any files transmitted with it are confidential and intended solely
> for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system
> manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named
> addressee you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately by e-mail from your
> system. If you are not the intended recipient you are notified that
> disclosing, copying, distributing or taking any action in reliance
> on the contents of this information is strictly prohibited.
>
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed. This footnote also confirms that this email
> message has been swept for the presence of computer viruses.
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS4TkVAAoJEBzwKT+lPKRY8+QP/2itb792qFZcI6MQxlc+Ds4P
PW0kV+h8+u9V1maTrosIDyzxL9EClmhnUUJ3LZgNO3s6XJn6XEzibQU6jPyrijs9
o2d9q1MTt/OQmml5MYK1OMMqaiOyNIu72/zpRXcRO6yX5Ddne/9RByRck6vjU2Za
EpeLKs49xe46eRTtcTYSrDQjH0DJmZfcqHApF7yi3Gb7CUAbZXB+SrYnTTGlTsvs
NmpltiN5T0pdts6VNkf6L34jSJi7n9961aAQbCv/3XvKvSR0nxVvKY7+x1b6DmYn
izORt55NymzdEz+P+eLHyAff+I7HOul+V41ImYr707RgtRLrANUfqdh29wJi0bbl
F7bTT5/lg8kgijeoQt8ls5ME9cfANvij8/R4XO8cTRtXR8nA3QfHMYpRlHOVjW0Z
1EBcKE73aymmyfB0PPq6zdqy6n2YqS91kRn7hUxzs3jpxEWw2u/Z/fIVE7xHsOKJ
ElABDO3ORtfiR1MpwNQTcjlB8s8zlzJT8pVkUEdlWEZ7E9H+ikFD/q/LXxTjjGGa
EYazOCpIdO2+q9qH0OZnrC14wTogtmstyQKTZykvEOWfsU+OFxl7CbD66/WRQvi2
dRsJkDDbrQDRYb8wb8QqPp9tTSpm/I03pjA7q0QK2tydRkOsH/irpHmQq8RDXJf+
9p7NCSV3v98Wi9WSoJLR
=oPQj
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Deny Put & Delete
Posted by Stephan Fletcher <sf...@bohrensmoving.com>.
It's a third party that is running the scan.
-----Original Message-----
From: Mark Thomas [mailto:markt@apache.org]
Sent: Thursday, January 23, 2014 10:05 AM
To: Tomcat Users List
Subject: Re: Deny Put & Delete
On 23/01/2014 14:57, Stephan Fletcher wrote:
> Any help would be greatly appreciated
<rant>
Buy a better vulnerability scanner. Specifically, one understands that an OPTIONS request returns the methods that are *available* not the methods that are *permitted*.
</rant>
Assuming you haven't changed Tomcat's default configuration any attempt to actually PUT or DELETE a resource will be denied.
I have a recollection that we changed the implementation of the OPTIONS request to try and help with this sort of thing. Scratch that. That was for TRACE which won't be included in an OPTIONS response unless Tomcat can confirm that it has been explicitly enabled in the Connector.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
________________________________
Important Notice: This email is copyright of Bohrensmoving.com, and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. This footnote also confirms that this email message has been
swept for the presence of computer viruses.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Deny Put & Delete
Posted by Mark Thomas <ma...@apache.org>.
On 23/01/2014 14:57, Stephan Fletcher wrote:
> Any help would be greatly appreciated
<rant>
Buy a better vulnerability scanner. Specifically, one understands that
an OPTIONS request returns the methods that are *available* not the
methods that are *permitted*.
</rant>
Assuming you haven't changed Tomcat's default configuration any attempt
to actually PUT or DELETE a resource will be denied.
I have a recollection that we changed the implementation of the OPTIONS
request to try and help with this sort of thing. Scratch that. That was
for TRACE which won't be included in an OPTIONS response unless Tomcat
can confirm that it has been explicitly enabled in the Connector.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org