On 23/07/2026 09:15, Anushka sur wrote:
Hi Mark,

1.It is https

OK.

These is the settings for server.xml

No, those are part of the settings from server.xml. Since you are using HTTPS then all of the Connector elements are relevant as well.

I did ask for the contents of server.xml, not part of it.

2.

I'm surprised that even started.

To repeat what I said previously:

Set up one virtual host for the correct host name(s) and deploy your application to that host.

Set up the default host with a ROOT that returns a 4xx response to all requests.

That means you need TWO host elements. You only have one. And a reference to a default host that doesn't exist.

The basics are:

<Engine name="Catalina" defaultHost="other">
  <Host name="other" appBase="webapps-other" />
  <Host name="hblacsuat.hdfcbankuat.com" appBase="webapps" />
</Engine>

Deploy your web application(s) to webapps as usual.

Deploy a ROOT web application to webapps-other that rejects all requests with a 4xx response of your choice. I'd do that with a servlet mapped to "/". YMMV.

Additional configuration may be required for TLS but since you haven't provided your connector information...

Mark


<!-- An Engine represents the entry point (within Catalina) that processes
every request. The Engine implementation for Tomcat stand alone
analyzes the HTTP headers included with the request, and passes them
on to the appropriate Host (virtual host).
Documentation at /docs/config/engine.html -->

<!-- You should set jvmRoute to support load-balancing via AJP ie :
<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
-->
<Engine name="Catalina" defaultHost="localhost">

<!--For clustering, please take a look at documentation at:
/docs/cluster-howto.html (simple how to)
/docs/config/cluster.html (reference documentation) -->
<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->

<!-- Use the LockOutRealm to prevent attempts to guess user passwords
via a brute-force attack -->
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>

<Host name="hblacsuat.hdfcbankuat.com" appBase="webapps"
       unpackWARs="true" autoDeploy="true">

<Valve className="org.apache.catalina.valves.RemoteIpValve"
       remoteIpHeader="x-forwarded-for"
       proxiesHeader="x-forwarded-by"
       protocolHeader="x-forwarded-proto" />

<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->

<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
prefix="localhost_access_log" suffix=".txt"
pattern="%h %l %u %t &quot;%r&quot; %s %b" />

</Host>
</Engine>


Thanks & Regards,
Anushka Sur


On Tue, 21 Jul, 2026, 19:27 Mark Thomas, <[email protected]> wrote:

On 21/07/2026 11:15, Anushka sur wrote:
Hi Mark,

As you suggested, we created a dedicated virtual host in the |
server.xml| file. However, even after adding the virtual host
configuration, the issue still persists.

For example, when we access the application using:

|https://sdcoradb5.hdfc.com:8083/ORDS <https://sdcoradb5.hdfc.com:8083/
ORDS>|

and replace |sdcoradb5.hdfc.com:8083 <http://sdcoradb5.hdfc.com:8083>|
with |bing.com <http://bing.com>|, the request is still being
redirected
instead of being rejected.

Which is it? http or https?

Could you please confirm whether our |server.xml| configuration is
correct, or if there are any additional settings or configurations that
need to be added to ensure only the intended host is accepted?

I could, if you had provided details of your settings. Screenshots will
get rejected by the mailing list. It would be better to simply paste the
contents of server.xml into a plain text email.

Mark



Any guidance would be greatly appreciated.

Thank you, Anushka Sur

In the screenshot..we have taken other instance for testing

   Screenshot for your reference:--




On Thu, 16 Jul, 2026, 11:40 Anushka sur, <[email protected]
<mailto:[email protected]>> wrote:

     Sorry for the confusion..We are using tomcat version 9.0.110

     On Thu, 16 Jul, 2026, 11:26 Anushka sur, <[email protected]
     <mailto:[email protected]>> wrote:

         Hi everyone,

         Thanks for the feedback. You are right — Tomcat 9.0.110 is very
         old, and we will treat the upgrade as the first remediation step.

         We will check the issue on a newer supported Tomcat release and
         verify whether the redirect problem is still reproducible there.
         If it is fixed by the upgrade, we will proceed with the newer
         version

         if not, as suggested by mark thomas we will create virtual host.

         Thanks for pointing this out.

         Best regards,
         Anushka Sur

         On Thu, 16 Jul, 2026, 01:33 Christopher Schultz,
         <[email protected]
         <mailto:[email protected]>> wrote:

             Mark,

             On 7/15/26 9:56 AM, Mark Thomas wrote:
              > 15 Jul 2026 11:10:41 Anushka sur <[email protected]
             <mailto:[email protected]>>:
              >
              >> We have identified a VAPT issue in our Oracle APEX
             application
              >> deployed on
              >> ORDS 24.1.11 running on Apache Tomcat 9.0.11.
              >
              > That is horribly out of date. You might want to check the
             list of
              > published CVEs for 9.0.x

             +1

             The real VAPT issue should be "holy @#$%&* your Tomcat
             version is *how*
             old?"

             -chris



  ---------------------------------------------------------------------
             To unsubscribe, e-mail: [email protected]
             <mailto:[email protected]>
             For additional commands, e-mail: users-
             [email protected] <mailto:[email protected]>



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]





---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to