IHS Vulnerability reports

Handling specific CVEs in IHS, Apache, or related software

First, Search the web for the CVE number and "IBM HTTP Server" to determineif an APAR and/or interim fix has been issued.

Read the body of the CVE to see if it refers to an Apache module that is either not used in IHS (for example, mod_ssl, mod_auth_digest, or mod_session) or only affects a configuration you don't use.

If you cannot find any information on the CVE, contact IBM support.

If it appears your server should not be affected, review the scan result more closely to determine if an issue was actively detected, and on what URL.

Handling non-CVE application level suggestions from scanners

General guidance on scan and pentest reports

IBM support cannot assist with interpreting the output of scanning tools or penetration tests. The scan should be reviewed by security specialists and application owners (of affected URLs) and sent to IBM when they are either in IBM components or resulted from bad input from IBM components.

If the scan includes a CVE number that has a realistic chance of being part of IHS, and a search of the web turns up no results, include both the CVE number and the observations of your report in plain text to IBM in a PMR.

If the scan describes some objectionable output on your website, include the request, response, why the response is objectionable, and articulate why you believe an IBM component either generated the objectionable output (as opposed to your application) or provided invalid input to your application.

Non acute vulnerabilities

Some security reports will highlight things that are not acute vulnerabilities, but relate more to secure web application design principles. For example, a scanner might flag a cookie used by your application for not carrying the "SECURE" property, but it doesn't know the semantics of your use of the cookie. Other examples include setting non-standard headers like X-Content-Type-Options=nosniff or X-Frame-Options. Middlware support cannot advise you on if or when to set these headers, only how to set them.

These issues require detailed scrutiny by the owners of the affected application. This may be the enterprise application running on WAS, WAS itself, or IHS. The primary indicator of where to start is the affected URL and the content/behavior that the scanner found objectionable.

Improper input handling of the HTTP Host: header

A security scan may flag "Improper input handling" of the HTTP Host: header as a vulnerability. This can mean that the system not only responds when addressed with an unexpected hostname, but some returned HTML or Location header (in a redirect) reflected the supplied hostname.

By default, most servers use the Host header to generate self-referential URLs in HTML and in redirects. Whether this is "improper" is disputed.

Scanners test this issue by connecting to your servers IP address but sending some unrelated "Host" header in the HTTP request. With HTTPS requests, a malicious third party cannot do this same substitution, so the practical impact is debateable.

A malicious third party can supply a link with a malicious hostname that shares an IP address of a non-malicious hostname. In this case, a user who clicks a link that begins with https://evil.example.com might see the content of https://www.example.com.

If you don't want this behavior, or to silence the scan result, you can address it at several levels by enumerating acceptable hostnames:

Configure IHS to only respond positively on allow-listed hostnames.

Configure WAS to only execute your web modules (application) only on specific hostnames.

WAS applications are deployed to virtual hosts. Each virtual host has a list of hostname and port combinations. Only requests that match the virtual host your application is associated with will reach your application.

Typical use deploys web applications to the "default_host" virtual host. This virtul host is managed by WAS to respond on all hostnames, standard HTTP and HTTPS ports, and all listening ports in the cluster.

Less commonly, a custom virtual host is created and the application is explicitly configured to use the custom virtual host by name.

Complete the following steps to reconfigure WAS virtual hosts to respond only on a prescribed list of hostnames:

Liberty

  1. Determine which virtual host is in use by your application

    • If there are no virtual hosts explicitly defined in server.xml, your applicaton uses "default_host"

    • If there are virtual hosts explicitly defined in server.xml, check the following to determine the virtual host in use by an application:

      1. Your applications ibm-web-bnd.xml

      2. The web-bnd element of webApplication in server.xml

      3. If no match, your application uses "default_host"

  2. Reconfigure the virtual host determined above to include only expected hostnames:

    <virtualHost id="default_host">
<!-- canonical http/https ports when accessed through a proxy-->
  <hostAlias>www.example.com:80</hostAlias>
  <hostAlias>www.example.com:443</hostAlias>
<!-- list the listening ports too -->
  <hostAlias>www.example.com:9443</hostAlias>
  <hostAlias>www.example.com:9080</hostAlias>
<!-- ... repeat above with other acceptable hostnames (no-www, no domain, internal hostnames, etc) ... -->
</virtualHost>
traditional WebSphere Application Server

  1. Determine which virtual host is in use by your application

    For a deployed application, check the administration console under All Applications > your-war > Virtual hosts

  2. Reconfigure the virtual host determined above to include only expected hostnames

    In the WebSpheres administrative console under Environment->Virtual Hosts, replace any wildcard host aliases in the virtual host determined in the preceding step with expected hostnames.

    Note: Changes to virtual hosts require a restart of the application server JVMs.

CORS

If a security scan advises you about missing CORS headers on a particular URL, you'll need your application developer to review the CORS spec and their deployment requirements to determine what the content of the CORS header should be.

If the application cannot issue its own CORS header using basic servlet API's, the header can be added by IHS via the Header directive. IHS/WAS support doesn't know the cross-origin requirements of your application and can't suggest a value.

More details are available here: https://www.ibm.com/support/pages/node/6348518

Web Server Internal IP Address/Internal Network Name Disclosure

If a security scanner reports something alluding to the webservers internal name/port being disclosed, review httpd.conf and make sure the following are all satisfied:

  • Each <VirtualHost> should have a ServerName set

  • ServerName should be set once globally (outside of VirtualHost context)

  • The argument for the ServerName directive should be the externally visible hostname and port. The port should be omitted if it's 80 or 443.

If the scanner continues to report the problem, you'll need to figure out what piece of software is revealing the internal info. The first step in doing this is figuring out the affected URL and the actual response data that showed the internal name. mod_net_trace is one simple way to capture the response if the scanner doesn't provide it.

HTTP Security Header Not Detected

If a security scanner reports something similar to 'HTTP Security Header Not Detected' you will have to work with your web/application developers and security standards team to determine which headers you'd like to set and how you'd like to set them.

The report may reference specific headers by name, for example:

  • X-XSS-Protection

  • X-Content-Type-Options

  • Content-Security-Policy

These headers can be set or edited in IHS with mod_headers, but usually the ideal place to set customized headers is at the source in the application.

IBM middleware support doesn't recommend setting any of these headers to any particular value and can only assist with the mechanics of translating your requirements into mod_headers syntax if needed.

HTTP request smuggling

Many scanners report "possible" HTTP request smuggling problems and suggest impractical and unnecessary solutions. The evidence provided often uses ancient, fully resolved issues and then shows little or questionable evidence that any request was misinterpreted.

The guidance from these scanners often suggests reconfiguring servers to reject "ambiguous" requests, such as those including both Transfer-Encoding and Content-Length headers. But this has been non-ambiguous since at least RFC 7230, published in 2014. Even the 2014 specification updates reflects a industry-wide consensus around from years prior about the correct precence of these two headers.

If no particular CVE is identified by the scan, IBM support cannot review any report that doesn't include the following:

  • A description of the full topology including any proxies in front of IHS involved in the scan

  • mod_net_trace output see mustgather

  • http_plugin.log w/ LogLevel="DEBUG see mustgather"

If any exploitable mismatch between the HTTP parsing in IHS and WAS were found, IBM would issue a unique CVE and align the processing.