As with all of my blog posts, the views and opinions expressed within do not explicitly represent the views or opinions of my employer.
This will be a two-part post about script and HTTP header integrity and associated tamper detection/prevention controls. I will focus the discussion on content security policy (CSP) and sub-resource integrity (SRI) and equivalent controls; what, who, why, and a little bit of how. We will discuss these two important security configuration settings first at a high level and then examine in just a bit more detail. If you’re an assessor looking for guidance, a new cloud/software engineer looking for clarification, or a CISO seeking to better understand this technology, these two posts will hopefully be useful for you.
If you already understand what CSP and SRI are then, head on over to part 2 for the compliance discussion.
What are the threats and risks?
You’ve heard of them over and over by now. Injection of malicious scripts, malicious JSON injection, click-jacking, and the good-ole fashioned cross site scripting (XSS) name only a few of the threat vectors applicable to public pages rendered by web applications with transactional capabilities. (In this post, when I speak of “transactional capabilities” I mean where the client browser would GET and then POST back information to the web service as an expected use case.) These vectors are most easily described by the attacker manipulating web pages with transactional capabilities within the user’s browser at the time the page is presented to the user, and injecting their own script or object in place of the original which was delivered by the web service. The risks associated with successfully executing such an attack include exactly what we’d expect: compromised user credentials, download or activation of malware, unauthorized access to session information, and ultimately; unauthorized access to sensitive information.
What is Content Security Policy?
In this post and the part follow-up, I intend to focus on CSP and SRI, as these methods are basic and fundamental. There’s certainly many other extravagant methods to achieve the same level of mitigation, and I welcome that discussion in the comments.
CSP is a security feature that is part of the http response header information sent by the server and interpreted by client browser. Put very simply, CSP is a set of instructions (called “directives”) which set prescriptive parameters specifying where the content in the pages served by the http service may originate from, what kind of content may be served, and what other pages can be directed into the session. The uses for such policy directives should be very obvious; correct implementation of CSP will help mitigate cross-site scripting (XSS) attacks, injection, and click-jacking. In fact this was the original intent of CSP, which was first implemented in 2010 by Firefox v4 and then quickly adopted by the browser forum.
What Does CSP Actually Look Like?
Actually seeing what CSP looks like and how it is rendered is important for assessors, software engineers, site administrators, and even general users to understand. There’s a few ways we can examine http response headers. Let’s walk through a couple of ways to do that.
How should I configure CSP?
This depends on the services offered on your web application and the depth to which you intend to monitor/protect content on your pages. An excellent minimal example can be found at CSP Evaluator (click “Example safe policy”). This will typically achieve most compliance goals and satisfy your auditors/examiners that you’ve taken steps to ensure integrity of information your organization presents in its web applications. Additional reading on Foundeo’s CSP page should be considered mandatory if you’re looking to go deeper here. It’s important to remember that as you turn CSP directives on and off, the behavior of your web application will most certainly change, possibly in unpredictable ways. As always, test all changes in lower environments within the boundaries established by your organizational change management program before proceeding. If you don’t believe me, take it from the experts.
Viewing HTTP Headers in Postman
Postman is a free-to-use API viewer and builder. It’s super useful for many things and this case is no exception. I use the downloadable/compiled version but there is also a web-browser only version. Once you launch Postman, it’s simple to check the HTTP headers. Just type (or copy/paste) the URL you’re testing into the ‘GET’ bar. In this case, you’re quite literally sending a ‘GET’ request to the HTTP server. The server should then return all of the response headers that we can explore. Using the tabs in the response section (the bottom part), we should see a tab that says “headers”. Look for content-security-policy, and select the text in that field. Here’s a GET request I just ran against this site:
Take note of the red rectangular highlighted sections here. We can easily see that this site has CSP enabled! Screenshot from Postman.
Most modern browsers will also allow a look at the headers through developer tools included within the browser advanced settings. Depending on what browser you are using, your mileage may vary. Personally, I recommend the Chrome console as a good place to start.
Using CSP-Evaluator
A far easier (and quicker) way to check up on a site’s CSP is to simply use the CSP-Evaluator site. As I noted above, I really love this tool because not only is it easy to use, but it has samples of what a “good” CSP might look like. For now, check out the results of running this site against the CSP-Evaluator.
Using Burp Suite Extension
If you’re a Burp Suite user, it’s likely you’re already using the CSP Auditor extension. It’s super useful for taking a deeper look into CSP. I won’t cover the details here, but head on over to the linked GitHub repository to check it out.
What is Sub-Resource Integrity?
SRI has been identified by PCI DSS and other frameworks as a potentially effective way to prevent the most common vulnerabilities associated with loading external resources in an endpoint browser. Just a few vulnerabilities include supply chain attacks, man in the middle (MITM), code tampering, and XSS/XSRF. SRI is pretty simple in its most basic implementation: a developer includes a cryptographic hash of a resource, and the browser compares its rendered hash to that which was provided by the host/service. If there is a mismatch, most browsers simply fail to present the content associated with that particular object. Pretty nifty, and its been around since 2016 having been first introduced as a W3C spec.
What Does SRI Actually Look Like?
Again, seeing SRI will simplify understanding how it works and ease of use.
<script
src="https://example.com/example-framework.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
In this example from Mozilla, we can see where a script element is invoked, followed by the “integrity” value. We also see the “sha384” algorithm used, followed by the actual hash. So, the browser would compare the hash in the code to a hash it creates of the script at the time the page is read. Mismatches result in rejected content. Easy to implement in a simplistic web architecture.
What if We Can’t Implement SRI and CSP Within Rendered Pages?
This question has become quite common with entities who have compliance burden but due to technical constraints cannot enable CSP and/or SRI without impacting the functionality of their solution. So, then what are the alternatives? Thankfully, there are options available. I will highlight a few that I am aware of below, although I am sure there are many others I am not aware of.
I have seen Akamai CSP demonstrated a few times, and it’s an interesting solution. At its core, it works by injecting client-side JavaScript into all page code and the script then monitors the client-side activity rendered in the browser. Not necessarily completely without flaws as some known malware can block and redirect browser scripting, but certainly a very good mitigation.
While I am not as familiar with the Jscrambler Client-side Protection and Compliance platform and products, their website contains a great deal of documentation, which I have had the chance to browse through. Again, this solution seems like it may be in an excellent position to meet the compliance and technical burden of script and page integrity. Possibly a good fit based upon what one’s organization might need.
As I note earlier, there are most likely many other solutions available, including open source options. If you’re aware of one or more, tell me about them in the comments; I will check them out and happily add them here. As always with any solution, your requirements should be the foundation for selection.
Summary and Call to Action
CSP and SRI are emerging as not only a necessity for compliance, but an important mitigation for client-side attacks. While the cost of re-architecting your web application to accommodate these controls may be steep, I think it should be weighed against the risk of compromise as we would in any basic cost-benefit analysis. Things to consider should include your compliance burden, the transactional profile of your web application (i.e. credit cards, collecting PII, collecting PHI, etc), the volume of transactional data, and the potential reputation costs of leaking that information because of client-side attacks. In part 2, I will summarize some of the compliance burden that should be examined to determine applicability.
Generative Artificial Intelligence Disclosure
Generative AI was not used to directly facilitate the writing of this post. Validate this statement.
Generative AI was used only to verify the factual components of this blog post. The ChatGPT prompt used was:
Can you verify the factual components of this blog post and highlight inaccuracies based upon the citations?As a result, slight corrections were made to dates regarding CSP implementation (2010 instead of 2011) and guidance from PCI DSS for SRI adoption. No other changes resulted from generative AI analysis.