Web server

When a client makes an HTTP request to a web server, it sends the request along with several HTTP headers. With the default configuration, some of these headers reveal information that may make the server more vulnerable to attacks.

Therefore, it is strongly recommended to turn off the following headers:

• Server: the software used by the server to handle the HTTP requests. For example: "Microsoft-IIS/7.5".
• X-Powered-By: specifies the technology or framework being run by the web application. For example: "PHP/5.4.0".
• X-AspNet-Version: holds the ASP.NET version. For example: "4.0.303319".
• X-AspNetMvc-Version: specific to ASP.NET and identifies the MVC version. For example: "3.0".

Additionally, we set the X-Content-Type-Options header to nosniff. The nosniff response header is a way to add security to a website. The nosniff response header prevents browsers from trying to mime-sniff the content-type of a response away from the one being declared by the server.

The next sections will explain how these measures are applied.

Server

IIS 10 and above

As of version 10 (shipped with Windows Server 2016), the Server header is removed by updating the web.config file.

Example:

<system.webServer>
  <security>
    <requestFiltering removeServerHeader="true"/>
  </security>
</system.webServer>

Older versions

Older versions do not support removal of the header, but the value has been altered via a rewrite rule.

Example:

<system.webServer>
  <rewrite>
    <outboundRules>
      <rule name="changeServerHeader">
        <match serverVariable="RESPONSE_Server" pattern=".*" />
        <action type="Rewrite"/>
      </rule>
    </outboundRules>
  </rewrite>
</system.webServer>

This overwrites the Server header with an empty value.

X-Powered-By

The X-Powered-By header is also removed via configuration.

Example:

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

X-AspNet-Version

The X-AspNet-Version header is removed by locating the system.web element and adding the line <httpRuntime enableVersionHeader="false"/>.

Example:

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

X-AspNetMvc-Version

The X-AspNetMvc-Version header is removed by adding a bit of code in the global.asax file.

MvcHandler.DisableMvcResponseHeader = true;

X-Content-Type-Options

We added this header by creating a customHeaders element and adding the line <add name="X-Content-Type-Options" value="nosniff"/>.

<system.webServer>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Content-Type-Options"/>
        <add name="X-Content-Type-Options" value="nosniff"/>
      </customHeaders>
    </httpProtocol>
</system.webServer>

X-Frame-Options

To prevent other websites including Content Hub in a frame, we set the X-Frame header:

<httpProtocol>
  <customHeaders>
    <add name="X-Frame-Options" value="DENY" />
  </customHeaders>
</httpProtocol>

The possible values are:

• DENY
• SAMEORIGIN
• ALLOW-FROM https://example.com/

X-XSS-Protection

As an additional protection layer against XSS attacks, we set the X-XSS-Protection header. this one can have the following values:

• 0: Disables XSS filtering.
• 1: Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
• 1; mode=block: Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
• 1; report= : Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report (Chromium only).

<httpProtocol>
  <customHeaders>
    <add name="X-XSS-Protection" value="1; mode=block" />
  </customHeaders>
</httpProtocol>

Secure cookies

To avoid third parties from stealing our cookies, we add Secure/HTTPOnly flags. With the secure flag, cookies are only sent over HTTPS connections. The HTTPOnly flag prevents JavaScript from accessing the cookie, which is an extra protection layer against XSS attacks.

Example:

<system.web>
    <httpCookies httpOnlyCookies="false" requireSSL="true" />
</system.web>