Which HTTP response header should be used to prevent attackers from displaying their content on a website?

Setting up HTTP Response Headers for Zeppelin

Apache Zeppelin can be configured to include HTTP Headers which aids in preventing Cross Site Scripting (XSS), Cross-Frame Scripting (XFS) and also enforces HTTP Strict Transport Security. Apache Zeppelin also has configuration available to set the Application Server Version to desired value.

Setting up HTTP Strict Transport Security (HSTS) Response Header

Enabling HSTS Response Header prevents Man-in-the-middle attacks by automatically redirecting HTTP requests to HTTPS when Zeppelin Server is running on SSL. Read on how to configure SSL for Zeppelin here. Even if web page contains any resource which gets served over HTTP or any HTTP links, it will automatically be redirected to HTTPS for the target domain. It also prevents MITM attack by not allowing User to override the invalid certificate message, when Attacker presents invalid SSL certificate to the User.

The following property needs to be updated in the zeppelin-site.xml in order to enable HSTS. You can choose appropriate value for "max-age".

<property>
  <name>zeppelin.server.strict.transport</name>
  <value>max-age=631138519</value>
  <description>The HTTP Strict-Transport-Security response header is a security feature that lets a web site tell browsers that it should only be communicated with using HTTPS, instead of using HTTP. Enable this when Zeppelin is running on HTTPS. Value is in Seconds, the default value is equivalent to 20 years.</description>
</property>

Possible values are:

• max-age=<expire-time>
• max-age=<expire-time>; includeSubDomains
• max-age=<expire-time>; preload

Read more about HSTS here.

Setting up X-XSS-PROTECTION Header

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari Web browsers that initiates configured action when they detect reflected cross-site scripting (XSS) attacks.

The below property to set X-XSS-Protection header is enabled with default value of "1; mode=block" in the zeppelin-site.xml

<property>
  <name>zeppelin.server.xxss.protection</name>
  <value>1; mode=block</value>
  <description>The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. When value is set to 1 and a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).</description>
</property>

You can choose appropriate value from below to update the configuration if required.

• 0 (Disables XSS filtering)
• 1 (Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page.)
• 1; mode=block (Enables XSS filtering. The browser will prevent rendering of the page if an attack is detected.)

Read more about HTTP X-XSS-Protection response header here.

Setting up X-Frame-Options Header

The X-Frame-Options HTTP response header can indicate browser to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites in a <frame>,<iframe> or <object>.

The below property to set X-Frame-Options header is enabled with default value of "SAMEORIGIN" in the zeppelin-site.xml

<property>
  <name>zeppelin.server.xframe.options</name>
  <value>SAMEORIGIN</value>
  <description>The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a frame/iframe/object.</description>
</property>

You can choose appropriate value from below to update the configuration if required.

• DENY
• SAMEORIGIN
• ALLOW-FROM uri

Setting up X-Content-Type-Options Header

The HTTP X-Content-Type-Options response header helps to prevent MIME type sniffing attacks. It directs the browser to honor the type specified in the Content-Type header, rather than trying to determine the type from the content itself. The default value nosniff is really the only meaningful value. This header is supported on all browsers except Safari and Safari on iOS.

The below property to set X-Content-Type-Options header is enabled with default value of "nosniff" in the zeppelin-site.xml

<property>
  <name>zeppelin.server.xcontent.type.options</name>
  <value>nosniff</value>
  <description>The HTTP X-Content-Type-Options response header helps to prevent MIME type sniffing attacks.</description>
</property>

Setting up Server Header

Security conscious organisations does not want to reveal the Application Server name and version to prevent finding this information easily by Attacker while fingerprinting the Application. The exact version number can tell an Attacker if the current Application Server is patched for or vulnerable to certain publicly known CVE associated to it.

The below property to mask Jetty server version is enabled by default and configured with value of " " (one whitespace char) in the zeppelin-site.xml

<property>
    <name>zeppelin.server.jetty.name</name>
    <value> </value>
    <description>Hardcoding Application Server name to Prevent Fingerprinting</description>
</property>

The value can be any "String". Removing this property from configuration will cause Zeppelin to send correct Jetty server version.

Also, it can be removed the from response headers and from 300/400/500 HTTP response pages.

<property>
    <name>zeppelin.server.send.jetty.name</name>
    <value>false</value>
    <description>If set to false, will not show the Jetty version to prevent Fingerprinting</description>
</property>

Which HTTP response header should be used to prevent attackers from displaying?

What are some parts of the HTTP header and why is this important as a security analyst?

What are the security headers?

What is missing security headers?