The Sequel of HTTP Headers - Advanced Security Capabilities

The Sequel of HTTP Headers

Advanced Security Capabilities

Michael Schneider
by Michael Schneider
time to read: 11 minutes

Keypoints

You need to know these new HTTP security headers

  • Subresource Integrity protects embedded objects from third parties being changed
  • Feature Policy allows monitoring of browser features
  • Origin Policy provides central management of HTTP headers
  • Applications can be isolated from each other in the same origin by means of suborigins

In the article Response Header Hardening, Andrea Hauser discusses the hardening of HTTP headers. The development of HTTP headers as well as browser and web application security continues to move forward at a steady pace. The relevant control options are also being rolled out for new functions. In this article, we will detail the latest technologies that will be part and parcel of web application security in the future.

Subresource Integrity

Although Subresource Integrity (SRI) is not an HTTP header, it does help protect web applications. Many applications nowadays use content from Content Delivery Networks (CDNs), usually in the form of JavaScript or CSS libraries. Application owner embed these libraries directly from CDNs into their own sites to ensure that they can profit from the CDN’s availability and high-performance connections as well as to save bandwidth. The libraries are embedded in the web applications without verification that they have the required content. However, these libraries can also be changed or even completely replaced. SRI provides a number of workarounds in this regard.

The current version of the Subresource Integrity specification was published by the writers Devdatta Akhawe (Engineer at Dropbox), Frederik Braun (Senior Security Engineer at Mozilla), François Marier (Software Developer at Mozilla) and Joel Weinberger (currently a Security Engineer at Snap and previously a Software Engineer at Google), as a W3C Recommendation on June 23, 2016. With SRI, the browser receives the instruction to carry out an integrity check on the third-party file to be loaded.

During this process, the use of the HTML tags script and link saves the Base64-encoded hash of the requisite file in the integrity attribute. If the verification of this hash value is successful, the file is subsequently loaded by the browser. Otherwise, the loading process is aborted. The security researcher Scott Helme has written a tool for generating SRI hashes. The jQuery library, for example, can be embedded as follows:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8= sha384-tsQFqpEReu7ZLhBV2VZlAu7zcOV+rXbYlF2cqB8txI/8aZajjp4Bqd+V6D5IgvKT sha512-+NqPlbbtM1QqiK8ZAo4Yrj2c4lNQoGv8P79DPtKzj++l5jnN39rHA/xsqn8zE9l0uSoxaCdrOgFs6yjyfbBxSg==" crossorigin="anonymous"></script>

As the example shows, multiple hash algorithms can be used. When this occurs, the browser always selects the strongest algorithm. SRI is already supported by Microsoft Edge, Mozilla Firefox, Google Chrome and Safari web browsers.

Feature Policy

The Feature Policy HTTP header has been recommended by Ian Clelland (Software Engineer at Google) as a way for websites to manage browser features and APIs. By setting the header, a site can control which features can be used and how they are used. The List of browser features controlled by the policy has been published on GitHub.

The definition of Feature Policy shares similarities with the Content Security Policy header. The Header Directive specifies the restrictions for the individual features and the origin from which these can be accessed. The browser default setting for most of these features is self. The directive below, for example, prohibits the use of camera, microphone and geolocation, and only permits the use of speaker for its own context and fullscreen for all origins.

Feature policy: camera 'none'; microphone 'none'; geolocation 'none'; speaker 'self'; fullscreen *

But the directive is also designed to override the policy for individual elements on one’s own site. If an iframe is used on a site, the use of geolocation can be activated for the content displayed in the iframe:

<iframe src="https://example.com" allow="geolocation">

The Feature Policy header will be supported by Google Chrome and Safari from July 2018 onwards.

Origin Policy

Mike West (engineer at Google) drew up the draft recommendation of the Origin Policy on May 30, 2017, in which he defined a method of simplifying the use of a number of security-relevant headers. Previously, a wide range of headers, such as Strict-Transport-Security and Content Security Policy had to be set and rolled out for the individual resources of a web application. The rules then apply for the entire origin of a web application, which means that kilobytes of header information are sent time and time again, with every response. This also happens in certain cases, such as 404 error pages, when the response fails to include the policies in the response header. Should this occur, the settings do not apply for the resource in question.

Mike’s recommendation allows the specific policy that applies for the site to be defined via the Sec-Origin-Policy header. At the start, the client sends a request for the policy using the Sec-Origin-Policy: 1 header. The server responds using the Sec-Origin-Policy: "policy-1" header and communicates which policy is applicable. The client subsequently calls the URL https://example.com/.well-known/origin-policy/policy-1 before proceeding to open the actual website. The policy is cached by the client and from this point onwards applies for the entire site. Such policies can appear as follows:

{
  "headers": [
    {
      "name": "Content-Security-Policy",
      "value": "default-src 'none'; connect-src 'self'; img-src 'self'; style-src 'self'; frame-ancestors 'none';",
      "type": "baseline"
    },
    {
      "name": "Referrer-Policy",
      "value": "strict-origin-when-cross-origin",
      "type": "fallback"
    }
    {
      "name": "Strict-Transport-Security",
      "value": "max-age=63072000; includeSubDomains; preload",
      "type": "baseline"
    },
    {
      "name": "X-Content-Type-Options",
      "value": "nosniff",
      "type": "baseline"
    }
  ],
  "cors-preflight": {
    "origins": "*"
  }
}

If a policy is to be changed at a future point in time, this is communicated to the client by modifying the Sec-Origin-Policy: "policy-2" header. This updates the saved policy accordingly. If the policy is to be completely deleted, the header is set to Sec-Origin-Policy: 0. The client subsequently deletes the information saved in the cache; however, certain settings, including the Strict Transport Security settings, remain in force until the defined period of time (max-age) has expired.

Suborigins

The specification for Suborigins was written by Devdatta Akhawe and Joel Weinberger (both known for drafting Subresource Integrity) as well as Jochen Eisinger (Software Engineer at Google) and published on May 18, 2017. The specification allows for various applications that will run within the physical origin example.com even if there are different applications. Suborigins makes it possible to define a namespace for each HTTP header that can be paired with the origin tuple scheme, host and port (http://example.com:80).

For example, the applications https://example.com/shop and https://example.com/blog will run within the physical origin example.com even if there are a number of different applications. As a result, an XSS vulnerability at https://example.com//blog can also affect https://example.com/shop, even if https://example.com/shop is protected by a restrictive Content Security Policy. Suborigins now offer the possibility of isolating such applications from one another without having to use different physical origins, such as shop.example.com and blog.example.com.

Suborigins are intended for the following purposes:

Although the specification for Suborigins is still in the draft status, it has great potential to further improve the security of web applications through isolation.

Conclusion

Not all the technologies presented above can be used yet, as they are still in their draft versions and therefore not supported by all browsers. Nevertheless, it is worth starting to familiarize yourself with these new possibilities and to plan their implementation. We will be including them in our test catalog for Penetration Tests ourselves and providing our customers with a detailed overview of their benefits.

About the Author

Michael Schneider

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

Are you interested in a Penetration Test?

Our experts will get in contact with you!

×
Reporting and Documenting

Reporting and Documenting

Michael Schneider

Introduction of CVSS v4.0

Introduction of CVSS v4.0

Michael Schneider

Rogue Device

Rogue Device

Michael Schneider

Windows LAPS

Windows LAPS

Michael Schneider

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here