Hi all,
As you certainly know, OWASP recommends testing HTTP methods of remote
servers using nmap "http-methods" script:
https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)
One of the recommandations is to ensure TRACE method is disabled (
let's just omit the recommandation on PUT/DELETE in this discussion..)
For this matter, the 'Security Considerations' documentation of Tomcat
states [1] the following :
"The allowTrace attribute may be used to enable TRACE requests which can
be useful for debugging. Due to the way some browsers handle the
response from a TRACE request (which exposes the browser to an XSS
attack), support for TRACE requests is disabled by default."
http://tomcat.apache.org/tomcat-8.5-doc/security-howto.html#Connectors
And indeed, with the default configuration, the TRACE method is always
refused with the unsupported 405 HTTP status code.
However there is one case where the configuration does not fully apply :
response to OPTIONS request for custom servlet (i.e. any non tomcat
servlet inherting from HttpServlet).
In such case the TRACE methods is incorrectly listed in the Allow header
sent back, even though it is correctly handled as not supported when
executed.
To reproduce:
1. deploy the attached war (containg all sources) in a tomcat instance
listening on port 80 (listing on port 80 is required for proper
validation through nmap https-methods script).
2. run the following unix commands :
** Test of custom Servlet :
$> curl -v -X OPTIONS http://yourIP/test/
BUG : 200 + Allow GET, HEAD, TRACE, OPTIONS
Expected : 200 + Allow GET, HEAD, OPTIONS
$> curl -v -X TRACE http://yourIP/test/
OK : 405 + Allow: GET, HEAD, OPTIONS
$> nmap -p 80 --script http-methods --script-args
http-methods.url-path='/test/' yourIP
BUG : nmap reports "Potentially risky methods: TRACE"
(even though it is correctly locked down)
This leads several security products which relies on the same test to
incorrectly report Tomcat as having a potential security risk, even
though there is none.
Technical explanation for this behavior on custom servlet :
- executing the TRACE method is correctly refused by CoyoteAdapter,
https://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
- but executing the OPTIONS methods is handled by the parent class which
DOES NOT apply the connector "allowTrace" configuration and always sends
the Allow header listing TRACE method
https://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk/java/javax/servlet/http/HttpServlet.java
To be fully complete on this matter, here is the behavior for JSPs and
default servlet :
** Test of JSP :
$> curl -v -X OPTIONS http://yourIP/test.jsp
OK : 405 + HTML message indicating "JSPs only permit GET POST or HEAD"
(unrelated to this bug report, an "Allow: GET, POST, HEAD" header
would be expected here, there is none.
this could be improved while sending
"jsp.error.servlet.invalid.method" message, see
https://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk/java/org/apache/jasper/compiler/Generator.java
)
$> curl -v -X TRACE http://yourIP/test.jsp
OK : 405 + Allow: OPTIONS
(unrelated to this bug report, it seems the "Allow" header is
incorrrect, "Allow: GET, POST, HEAD" header would be expected here)
nmap -p 80 --script http-methods --script-args
http-methods.url-path='/test.jsp' yourIP
OK
** Test of default servlet :
$> curl -v -X OPTIONS http://yourIP/index.html
OK : 200 + Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
$> curl -v -X TRACE http://yourIP/index.html
OK : 405 + Allow: HEAD, DELETE, POST, GET, OPTIONS, PUT
$> nmap -p 80 --script http-methods --script-args
http-methods.url-path='/index.html' yourIP
OK (...) : nmap reports "Potentially risky methods: PUT DELETE"
(this is unrelated to this bug report, but there could be some
improvement there too)
Regards,
Olivier
@OlivierJaquemet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
