Securing IBM HATS Web Application (Using HTTP Header)

What are HTTP security headers?

HTTP Security Headers are a set of key-value pairs that are added to the headers of an HTTP response to provide enhanced security for web applications and websites. They are a subset of HTTP headers that are explicitly related to security. These headers control how browsers and other clients interact with web pages and resources and help to protect against various security threats.

Why do we need them?

Implementing security headers helps to protect sensitive data, such as user login credentials, and prevents the theft of user data or the manipulation of web pages. This helps to stop some of the most common hacker attacks, malware injections, clickjacking, malicious script injection, etc. They provide an extra layer of protection by restricting some activities between the server and the web browser while the web application is running. Additionally, security headers help a website or web application comply with regulatory requirements and industry best practices.

Important HTTP security headers to implement

Here are some of the most important and common HTTP security headers you must implement on your web applications to enhance security and enable an extra layer of protection.

·        X-XSS-Protection

·        X-Content-Type-Options

·        Content-Security-Policy

·        Strict-Transport-Security

For more other security related considerations:

Other Security Considerations - IBM Documentation

HTTP security headers in HATS

IBM HATS provides provisions to protect against ‘X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy’. In the HATS web.xml file, update the ' param-value' under the filter ‘HatsHeaderSecurityFilter’ section from “NO” to “YES”. Additionally, you can add URLs that should be secured using these features.

X-XSS-Protection

X-XSS-Protection (applied to IE, Chrome, and Safari) is a response header to configure the built-in anti-XSS (Cross-Site Scripting) protection in web browsers. This header can be used to enable or disable the protection, as well as configure its behavior. The most used values for this header are:

" X-XSS-Protection: 1; mode=block"
Enables XSS protection and will block the page if a potential XSS attack is detected.

“X-XSS-Protection 0"
Disables XSS protection.

“X-XSS-Protection: 1; report=<reporting-uri>"
Enables XSS protection and will send a report if a potential XSS attack is detected. The <reporting-uri> value should be replaced with the URI that the report should be sent to.

To enable X-XSS-Protection in the HATS project, go to file web.xml and change the param-value from ‘NO’ to ‘YES’. The default X-XSS-Protection value will be ‘1; mode=block’.

For more information, refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

NOTE: This header is deprecated, and support is removed from most browsers. To overcome this challenge, HATS provides a custom filter which sanitizes the malicious script. To enable this filter, add below filter in web.xml.

Content Security Policy (CSP)

CSP is a security feature that helps to prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by giving website owners control over the resources a web page can load and execute. For example, a website owner can use CSP to specify that a web page can only load scripts from the website's server, not other third-party servers.

To enable the HATS project’s CSP feature, go to file web.xml and change the param-value from ‘NO’ to ‘YES’. The default CSP value will be “frame-ancestors ‘self’”.

The frame-ancestors directive can be used in a Content-Security-Policy HTTP response header to indicate whether a browser should be allowed to render a page in a <frame> or <iframe>. Sites can avoid Clickjacking attacks by ensuring their content is not embedded into other sites. This is the same as using ‘X-FRAME-OPTIONS’.

Common uses of CSP frame-ancestors:

Content-Security-Policy: frame-ancestors 'none';
This prevents any domain from framing the content. This setting is recommended unless a specific need has been identified for framing.

Content-Security-Policy: frame-ancestors 'self';
This only allows the current site to frame the content.

Content-Security-Policy: frame-ancestors 'self' *.somesite.com
This allows the current site, any page on somesite.com (using any protocol), and only the page myfriend.site.com, using HTTPS only on the default port (443).

For more information, refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

X-Content-Type-Options

X-Content-Type-Options is an HTTP response header that prevents Internet Explorer and Google Chrome from trying to mime-sniff the content type of a response away from the one declared by the server. When this header is set to ’nosniff’, the browser will not attempt to change the response’s content type. This can help to protect against certain types of attacks, such as cross-site scripting (XSS).

To enable X-Content-Type-Options in the HATS project, go to file web.xml and change the param-value from ‘NO’ to ‘YES’. The default X-Content-Type-Options value will be ‘nosniff’.

For more information, refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

HTTP Strict Transport Security (Only for HTTPS-enabled sites)

HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows a web server to declare that it should only be accessed using a secure HTTPS connection and not via the insecure HTTP protocol. This helps to protect against man-in-the-middle attacks and makes it harder for attackers to intercept sensitive information. The server declares the HSTS policy using the Strict-Transport-Security HTTP response header.

max-age=<expire-time>
The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS.

includeSubDomains (Optional)
This rule applies to all the site's subdomains if this optional parameter is specified.

preload (Optional Non-standard)
When using preload, the max-age directive must be at least 31536000 (1 year), and the includeSubDomains directive must be present. Not part of the specification.

Application servers implement HSTS in the web.xml or server configuration file.

E.g., if you are using IBM Websphere, here is how you can enable HSTS using web.xml:

Note: The browser ignores the Strict-Transport-Security header when your site has only been accessed using HTTP. Only when the site is accessed over HTTPS will the browser follow the Strict-Transport-Security header.

For more information, refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

Enable HTTP security headers using the Java filter class

If you need to add new headers or change the default values of the above-described headers, you can create a filter class and add the security headers in the HTTP response. Filters intercept the client’s requests before it tries to access HATS resources.

Note: If changes are done to existing headers, the new changes overwrite the default value set by web.xml.

In web.xml, add ‘<filter>’, ‘<filter-mapping>’, and ‘<url-pattern>’ to the newly created filter. In ‘url-pattern’, define application URLs on which the filter should be applied.

Final Output

When you enable the security mentioned above in the HATS application, you will find the relevant values in the HTTP calls.

Here is a sample output captured from the browser network console.Bottom of Form