TRACE incorrectly advertised as a supported HTTP method for custom servlet

[Olivier Jaquemet <ol...@jalios.com>]

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

Re: TRACE incorrectly advertised as a supported HTTP method for custom servlet

[Olivier Jaquemet <ol...@jalios.com>]

On 05/02/2017 17:29, Olivier Jaquemet wrote:
> [...]
> there is one case where the [allowTrace] 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.
> [...]

I realized that opening a discussion for this matter may not have been 
the best way to process and keep track of the issue.
Therefore I just opened the followng bug report :
https://bz.apache.org/bugzilla/show_bug.cgi?id=60697

I wish I could submit a patch for this, but my knowledge of the Tomcat 
architecture is far from what would be required to properly address the 
issue. Specifically : how could HttpServlet implementation be modified 
to apply the allowTrace settings belonging to connectors implementation, 
while keeping code orthogonality...
I'm sure you will have the answer :)

Thanks
Olivier

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: TRACE incorrectly advertised as a supported HTTP method for custom servlet

[Olivier Jaquemet <ol...@jalios.com>]

On 05/02/2017 17:29, Olivier Jaquemet wrote:

> [...]
>
> 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).
The simple test webapp :
https://www.dropbox.com/s/qkv6eayy4nnn8u8/trace.war?dl=0



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org