Disable Excessive headers – Apache

Methods

1. To remove the Server header, follow these steps:

  • Load the hread module in the Apache httpd.conf file, by adding the following line:
LoadModule headers_module modules/mod_headers.so

  • After headers_module is loaded, set the following lines in httpd.conf:

ServerTokens Prod
ServerSignature Off

ServerSignature removes the version ifnp from the page generated by apache web server (e.g. 403, 404, 502, etc.)
ServerTokens changes Header to production only, i.e. Apache

  • Restart apache service.

2. To remove X-Powered-By header, include following lines in the httpd.conf.

<IfModule mod_headers.c>
   Header unset X-Powered-By
</IfModule>

3. For Apache Coyote, edit the server.xml configuration file found at: CATALINA_HOME/conf/server.xml

<Connector 
     port="8080"
     ... 
     server="Apache"
/>

4. For JBoss 6.0, JBoss 7.0, JBoss 7.1, modify the catalina.properties file located in: ${jboss.home}/server/${server.instance.name}/deploy/jbossweb.sar/.

Set the property org.apache.catalina.connector.X_POWERED_BY to false.

References

https://httpd.apache.org/docs/2.2/mod/core.html#serversignature
https://httpd.apache.org/docs/2.2/mod/mod_headers.html#header
http://docs.jboss.org/jbossweb/7.0.x/sysprops.html
https://tomcat.apache.org/tomcat-8.0-doc/security-howto.html
https://www.owasp.org/index.php/Securing_tomcat

Disable Excessive headers – IIS

Methods

1. Remove the Server header by adding the following code to the Global.asax.cs file in your project:

 protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
 {
    Response.Headers.Remove("X-AspNet-Version");
    Response.Headers.Set("Server","FooServer");
 }

2. To remove the X-AspNet-Version header set the following, in the Web.config:

<configuration>
  <system.web>
    <httpRuntime enableVersionHeader="false" />
  </system.web>
</configuration>

3. To remove X-AspNetMvc-Version, add the following line in the Application_Start event in Global.asax:

protected void Application_Start()
{
    MvcHandler.DisableMvcResponseHeader = true;
}

4. To remove the X-Powered-By header set the following in the Web.config file:

<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

5. To suppress all the other headers ensure that the Web.config contains the following xml:


<configuration>
  <nwebsec>
    <httpHeaderModule>
      <suppressVersionHttpHeaders enabled="true" />
    <httpHeaderModule>
  </nwebsec>
</configuration>

6. Alternatively, follow the following instructions of IIS configuration:
https://blogs.msdn.microsoft.com/varunm/2013/04/23/remove-unwanted-http-response-headers/

Fingerprint Web Application Framework

Description

If a framework version number is being disclosed by the application in the response header, an attacker can use this information to find and exploit known vulnerabilities, specific to the used framework(s). This increases the likelihood of anattack and also allows an attacker to launch a more focused attack on the application.

Such headers might include: Server, X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version and others.

For example:

excessive_headers

See how to fix it!

Read more

Case study – Open Redirect

Most of us are familiar with the ‘Open Redirect’ vulnerability; an OWASP top 10 vulnerability that takes advantage of a situation in which the application receives a parameter from the client and uses it to build the URL location to which the user is redirected, without performing sufficient validation on the received input.

Typically, attackers can exploit vulnerable applications in order to perform phishing attacks, redirecting the victims to phishing sites that look exactly (or partially) like the vulnerable application. The victims tend to believe they are still in the original website, and provide their credentials in order to perform the required login. Unfortunately, these credentials are sent directly to the attacker.

A Classic Open Redirect Scenario

The following image demonstrates a vulnerable website (victim-site.com), which is vulnerable to the common open redirect scenario; a login page that will redirect the user to the page specified in the ‘returnURL’ parameter after successful login (the rectangle outlines the URL of the index page):

Read more