On 22.05.2017 20:35, Cai, Charles [COMRES/RTC/RTC] wrote:
Hi there,

Server Specs:
Server version: Apache Tomcat/7.0.54
Server built:   May 19 2014 10:26:15
Server number:
OS Name:        Windows Server 2012
OS Version:     6.2
Architecture:   amd64
JVM Version:    1.8.0_121-b13
JVM Vendor:     Oracle Corporation

I'm currently on the process of trying fix a site vulnerability, basically it is one type 
of the "Improper Input Handling" attack.

Let's say my website is www.mywebsite.com and there is hacker's website 

whenever there is a request send to www.mywebsite.com with modified "Host" 
header point to www.hacker.com, my site will create a redirect to www.mywebsite.com along 
with whatever the url it was. e.g.

Host: www.mywebsite.com
GET  www.mywebsite.com/get/some/resources/
Response 200 ok

Host: www.hacker.com (#been manually modified)
GET  www.mywebsite.com/get/some/resources/
Response 302
Send another Redirect to www.hacker.com/get/some/resources
My website is running on Tomcat 7, I tried some solution with set up the 
virtual host by point the unknown host to a defaultlocalhost which supposed to 
do nothing. but it still send the redirect for some reason.

Here attached is my server.xml host configure:
<Engine name="Catalina" defaultHost="defaultlocalhost" jvmRoute="jvm1">
<Host name="www.mywebsite.com"  appBase="webapps"
         unpackWARs="true" autoDeploy="false" deployOnStartup="true">

     <Valve className="org.apache.catalina.valves.AccessLogValve" 
            prefix="localhost_access_log." suffix=".txt"
            pattern="%h %l %u %t &quot;%r&quot; %s %b" />

   <Host name="defaultlocalhost"  >
So, my question is, Am I on the right track to prevent this kind of attack ? If 
yes, what I did wrong that still not working? (The ultimate goal is, if it is 
not the legit Host that been passed in, the request should be 
discard/ignored/return 404 but not redirect with 302)

The first thing is, as far as I know, Tomcat *by itself* will not generate this redirect response.
But an application deployed inside Tomcat might do that, perhaps.

With the above configuration, this is what happens :

> <Engine name="Catalina" defaultHost="defaultlocalhost" jvmRoute="jvm1">

>    <Host name="defaultlocalhost"  >
>    </Host>

1) Any request coming in to your server, which has a Host: HTTP header which is not "recognised" by Tomcat, will be processed by this "defaultlocalhost" virtual Host.
See :  http://tomcat.apache.org/tomcat-7.0-doc/config/engine.html#Attributes

2) this default virtual Host, as defined above, has an appBase="webapps", just like the other Host which you defined. That is because "webapps" is the *default* value for this attribute, and you did not specify it otherwise in your "defaultlocalhost".
See : http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Attributes

3) thus, if your normal application corresponding to the URI get/some/resources/) is deployed under (tomcat_dir)/webapps, then your application will be called when anyone sends the following HTTP request to your server :

GET get/some/resources/ HTTP/1.1
Host: evil.hackers.com (or whatever is not "www.mywebsite.com")

What your application then does with this call, is up to your application.
If it is some kind of framework, it might very well decide to return a redirect 
But that is not tomcat code.

If you want to protect against this, then you should provide your "defaultlocalhost" with a real appBase, different from the standard "webapps", and maybe put a default application there which returns a lit cluster bomb to the evil hacker. (or more reasonably, a "not found" response; which tomcat will do by itself if there is nothing there that matches the request URI).

Note that in addition, with your above configuration, there should be warnings in the tomcat logfile, because your application will be deployed twice : once for the "defaultlocalhost" Host, and once for the "www.mywebsite.com" Host.

Thank you in advance.

More references about the attack here :

Original Post on stackoverflow:  

Charles Cai | Web Application Developer | RIDGID
Emerson Commercial & Residential Solutions |

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

Reply via email to