ISAM for Web – Sending Security HTTP Headers

Update 5/08/15: In the ISAM 8.0.1.3 Release, we’ve added a new stanza to the ISAM Reverse Proxy config file. This allows the easy addition of headers to all ISAM responses.

[rsp-header-names]

#
# This stanza is used to define static HTTP headers which will be added
# to every HTTP response from the WebSEAL server.  This will provide the
# administrator with the ability to insert some standard security headers
# into the response, such as strict-transport-security,
# content-security-policy and x-frame-options.
#
# Please note that the headers which are defined in this stanza will replace
# any matching headers which might have been added to the response by a
# junctioned application.
#
# If multiple headers of the same name are specified in this stanza all
# but the last of the matching entries will be ignored.
#
# The format of each entry in this stanza is:
#    <header-name> =  <header-value>
#
# For example,
#   strict-transport-security = max-age=31536000; includeSubDomains
#
# A special <header-value> of '%SESSION_EXPIRY%' can be used to
# designate a header which will contain the remaining length of time, in
# seconds, before the current local session expires.  This value does not
# include the overall session timeout for sessions which are managed by
# the distributed session cache (DSC), but just the length of time before
# the session expires in the local cache.
#
# For example:
#   session-timeout = %SESSION_EXPIRY%
#

 

Update 15/05/15: There are some new features that should be coming in the next ISAM release which will vastly simplify the addition of these security headers. Watch this space!

Modern browsers expose countless numbers of new features to web developers, and it can sometimes be a challenge to ensure that you’re not exposing yourself to additional vulnerabilities because of them. In this post I show you how to add additional security headers to the ISAM for Web (WebSEAL) response in an effort to mitigate some attack vectors.

This is a follow up to a previous article where we used a similar mechanism to hide particular headers returned from junctioned servers here.

HTTP Strict Transport Security Header

The first header I’d like to include is the HTTP Strict Transport Security or HSTS header, this header tells most modern browsers that all traffic to your domain (and optionally sub domains) should be over HTTPS. The header also defines an expiry, such that the browser will remember this setting until the expiry period.

The header itself is fairly simple, and the steps to implement it have already been defined by Patrick Wardrop on his IBM.COM blog.

Note: Keep in mind while testing the HSTS header, that its not possible to make it work with a self signed certificate. It must be a CA signed certificate that is already trusted in your browsers trust store. There are numerous discussions on the reasons implementing the support for it this way, feel free to google it at your leisure, the key take away – is that you will have trouble testing this on a fresh ISAM for Web test instance.

X-Frame-Options HTTP Header to combat clickjacking

The X-Frame-Options header is a security policy header that tells the browser whether or not the page being rendered can be shown in an IFRAME or similar.

It is also also fairly simple, and comes in three varieties:

• X-Frame-Options: DENY
  Pages with this header cannot be framed at all.
• X-Frame-Options: SAMEORIGIN
  Pages with this header can only be framed from the same site.
• X-Frame-Options: ALLOW-FROM http://somesite.com
  Pages can only be framed by the specified pages.

The easiest and most compatible header is the SAMEORIGIN policy, which would require any malicious attack to come from the same domain – limiting the possible attack vectors. You could also choose DENY if you are certain that there is no pages that require framing. (and you can place a specific non-manipulative POP on any resources that are exceptions.) For the purposes of this post, I’ll be using SAMEORIGIN.

Content-Security-Policy HTTP Header

No sooner has the X-Frame-Options header been standardised, has the web come up with a new mechanism to push it towards obsolescence. The Content Security Policy header defines a variety of headers that can be used to restrict and selectively allow advanced features and locations of the content in your pages. CSP 1.1/Level 2 is in various stages of drafting, and it defines a frame ancestry configuration property that performs the same feature. Details here.

Special note: The frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored.

It also has three main varieties:

• Content-Security-Policy: frame-ancestors ‘none’
  Disallow embedding. All iframes etc. will be blank, or contain a browser specific error page.
• Content-Security-Policy: frame-ancestors ‘self’
  Allow embedding of [[same-origin policy|own content]] only.
• Content-Security-Policy: frame-ancestors example.com wikipedia.org
  Allow specific origins to embed this content

 

Adding the headers to the ISAM for Web Response

Using HTTP Transformation rules, we can add these headers to the responses sent back to the clients.

An example HTTP transformation rule is shown here:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:strip-space elements="*" />
<xsl:template match="/">
    <HTTPResponseChange>
        <xsl:apply-templates />
    </HTTPResponseChange>
</xsl:template>

<xsl:template match="//HTTPResponse/Headers">
    <Header name="Strict-Transport-Security" action="add">
        max-age=31536000; includeSubDomains</Header>
    <Header name="X-Frame-Options" action="add">SAMEORIGIN</Header>
    <Header name="Content-Security-Policy" action="add">
        frame-ancestors 'self'</Header>
</xsl:template>
</xsl:stylesheet>

To configure the HTTP transformation rule and make it available for policy use the steps described in a similar post where we used rules to remove a response header.

Such that you create a POP, with the HTTPTransformation extended attribute:

And apply the POP to the root of the WebSEAL server object space:

Conclusion

Staying ahead of hackers can be challenging, so it’s important to take advantage of the protection mechanisms of modern browsers. The headers described in this post are but a few of those available, but they can considerably increase the security on your enterprise website.