On 17/03/2020 23:30, Martynas Jusevičius wrote: > Tomcat does not allow DELETE by default? I’m using 8.0.x with Jersey and I > don’t think I used any config to enable it.
By default, HttpServlet (which pretty much every servlet extends) returns a 405 for a DELETE. The Servlets that Tomcat implements either leave that unchanged or require explicit configuration (DefaultServlet, WebdavServlet) to allow the DELETE method. If an application (or a library / framework) wants to implement DELETE then they are free to do so and Tomcat won't stop them. The assumption is that the developers of that library / framework will either secure access appropriately and/or explain to their users how to do so. The only method Tomcat blocks by default is TRACE. Not because TRACE is insecure, it isn't, but because at least one browser implementation was (may be still is) dumb enough to process the response as HTML rather than plain text. And that creates security issues. Mark > > On Tue, 17 Mar 2020 at 23.50, Mark Thomas <ma...@apache.org> wrote: > >> On March 17, 2020 10:31:06 PM UTC, "James H. H. Lampert" < >> jam...@touchtonecorp.com> wrote: >>> >>> On 3/17/20 3:18 PM, Martynas Jusevičius wrote: >>>> why should DELETE or OPTIONS not be enabled? They are standard HTTP >>> methods. >>> >>> True, but (quoting the audit report) >>>> . . . [DELETE] may allow a remote attacker to delete arbitrary files >>> . . . . >> >> There is a big difference between supporting a method (recognising it is a >> known HTTP method) and allowing it. >> >> Tomcat does not allow DELETE by default. Your app might but one assumes if >> it does the developers know what they were doing and secured it >> appropriately... >> >> Tomcat takes the view that OPTIONS should list all supported methods, not >> just methods allowed, for a given resource. >> >>> and (again quoting the report) >>>> Web servers that respond to the OPTIONS HTTP method expose what other >>>> methods are supported by the web server, allowing attackers to narrow >>>> and intensify their efforts. >> >> That is a security by obscurity argument. The Tomcat devs have never given >> much ,(any?) weight to arguments made on that basis. >> >> The XXS might be valid. I assume the tool provided a sample URL you could >> use to validate the finding. That should point you in the right direction >> but feel free to ask here if more help is required. >> >> Mark >> >> >>> -- >>> JHHL >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
