Some questions about Tomcat ISAPI Connector and its documentation

[Konstantin Preißer <ve...@t-online.de>]

Hi all,

I have some questions about the documentation of the ISAPI Connector 1.2.32 (and about the connector itself).


1. In the Reference Guide for IIS (http://tomcat.apache.org/connectors-doc/reference/iis.html), the registry options are listed. For the option "enable_chunked_encoding" which controls if chunked encoding is used, there is the note:

"This option is considered experimental and its support must be compile time enabled. Use isapi_redirect.dll with chunked support enabled."

Is enabling chunked encoding still considered experimental? I'm using it since one year or so on IIS 7 and never encountered any problems with it (besides one or two bugs which I reported and got fixed). Also, I'm not sure if the phrase "its support must be compile time enabled" currently still applies, as it seems that the binaries are always compiled with support for chunked encoding since 1.2.30 or so.


I would consider chunked encoding support as a requirement for optimal performance, because without supporting it, each time a response is sent to a client without knowing the Content-Length in advance, the TCP connection has to be closed (and re-opened when another request should be performed), which is why I always enable chunked encoding in the ISAPI connector.

If there are no problems with the chunked encoding reported, maybe the docs could be changed to remove the "experimental" note? Maybe even the default value for  "enable_chunked_encoding" in the connector itself could be changed from "false" to "true"? 


2. I observed that when a request is made to IIS which is mapped to Tomcat, and the request path contains the string "WEB-INF", like
http://www.example.com/test/asdf/blahblah/blah/WEB-INF/blahbla/asdf
then the ISAPI connector logs a statement like this:

[Sat Mar 10 22:34:58.030 2012] [11744:10792] [emerg] handle_notify_event::jk_isapi_plugin.c (1997): [/test/asdf/blahblah/blah/WEB-INF/blahbla/asdf] points to the web-inf or meta-inf directory. Somebody tries to hack into the site!!!

If I remember correctly, in some earlier versions of the ISAPI connector (or IIS), in such cases the TCP connection from IIS to the client would also be closed without any reply; however, in the current version, a 404 reply is sent from the ISAPI connector.

I'm wondering why the ISAPI redirector checks if "WEB-INF" is occurring in the path, because Tomcat seems to already check if a request is made to the WEB-INF or META-INF directory of an web application, and if so, sends back a normal 404 response. Is this a kind of relict from earlier times? Because I would expect that the ISAPI redirector just passes the request to Tomcat and let Tomcat decide how requests to forbidden directories are handled, without writing an "emergency" log entry. 


Thanks!

Regards,
Konstantin Preißer


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

RE: Some questions about Tomcat ISAPI Connector and its documentation

[Konstantin Preißer <ve...@t-online.de>]

Hello Konstantin Kolinko and André Warnier,

thank you both for your replies.


> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Sunday, March 11, 2012 12:14 AM
> To: Tomcat Users List
> Subject: Re: Some questions about Tomcat ISAPI Connector and its
> documentation
> 
> That is probably what isapi_redirector does anyway (forward the request
> to Tomcat, and let
> Tomcat send the 404 response (which may be customised)).

In such a case, the ISAPI connector seems to sends its own 404 error message (which can't be customized I think).


> But perhaps the log message in the isapi_redirector log is there for
> the following reason
> : when Tomcat is hosted on a separate host, it may be nice, on the
> IIS/isapi_redirector
> host, to have a log entry recording this.  Just in case the IIS-side
> logs are being
> watched closely, and the Tomcat logs less so.
> After all, someone using a URL including WEB-INF or META-INF, is quite
> likely to be
> someone who /is/ trying to hack the system.
> 
> That kind of overlaps the warning in red text that is present on the
> connectors "how-to"
> pages, like :
> 
> However, you should be very careful when you implement the following
> configuration style,
> because by doing so you are in fact providing a "back-door" to IIS, and
> allowing it to
> serve files out of a Tomcat context without Tomcat's knowledge, thus
> bypassing any
> security restrictions which Tomcat itself and the Tomcat context
> (webapp) may place on
> those files.

That's right; however, it seems that the warning only appears when the request is actually mapped to the ISAPI connector - if it is not mapped to it, it does not prevent accessing directories called "WEB-INF" (e.g. when trying to have IIS serve the static files and Tomcat serve only Servlets/JSPs).

> Does this log message bother you ? why would you want to /not/ have it
> ?
> 

It does not bother me - I just wondered why the ISAPI would to this checks, when Tomcat already does it. :)


Regards,
Konstantin Preißer


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

Re: Some questions about Tomcat ISAPI Connector and its documentation

[André Warnier <aw...@ice-sa.com>]

Konstantin Preißer wrote:
...
> 
> 2. I observed that when a request is made to IIS which is mapped to Tomcat, and the request path contains the string "WEB-INF", like
> http://www.example.com/test/asdf/blahblah/blah/WEB-INF/blahbla/asdf
> then the ISAPI connector logs a statement like this:
> 
> [Sat Mar 10 22:34:58.030 2012] [11744:10792] [emerg] handle_notify_event::jk_isapi_plugin.c (1997): [/test/asdf/blahblah/blah/WEB-INF/blahbla/asdf] points to the web-inf or meta-inf directory. Somebody tries to hack into the site!!!
> 
> If I remember correctly, in some earlier versions of the ISAPI connector (or IIS), in such cases the TCP connection from IIS to the client would also be closed without any reply; however, in the current version, a 404 reply is sent from the ISAPI connector.
> 
> I'm wondering why the ISAPI redirector checks if "WEB-INF" is occurring in the path, because Tomcat seems to already check if a request is made to the WEB-INF or META-INF directory of an web application, and if so, sends back a normal 404 response. Is this a kind of relict from earlier times? Because I would expect that the ISAPI redirector just passes the request to Tomcat and let Tomcat decide how requests to forbidden directories are handled, without writing an "emergency" log entry. 
> 
That is probably what isapi_redirector does anyway (forward the request to Tomcat, and let 
Tomcat send the 404 response (which may be customised)).
But perhaps the log message in the isapi_redirector log is there for the following reason 
: when Tomcat is hosted on a separate host, it may be nice, on the IIS/isapi_redirector 
host, to have a log entry recording this.  Just in case the IIS-side logs are being 
watched closely, and the Tomcat logs less so.
After all, someone using a URL including WEB-INF or META-INF, is quite likely to be 
someone who /is/ trying to hack the system.

That kind of overlaps the warning in red text that is present on the connectors "how-to" 
pages, like :

However, you should be very careful when you implement the following configuration style, 
because by doing so you are in fact providing a "back-door" to IIS, and allowing it to 
serve files out of a Tomcat context without Tomcat's knowledge, thus bypassing any 
security restrictions which Tomcat itself and the Tomcat context (webapp) may place on 
those files.

Does this log message bother you ? why would you want to /not/ have it ?


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