Leverage Browser Security Features to Secure Your Website
Learn how the Ticketmaster UK data breach can serve as an example to browser security features in this post on building more secure web applications.
Join the DZone community and get the full member experience.Join For Free
Given the increasing number of data breaches, you won't be surprised to read another article about yet another data breach. However, this time the looting did not involve a database. The hackers used a different, perhaps more dangerous, trick instead.
In this blog post, we will use the Ticketmaster UK data breach as an example to explain how your developers can use the browser security features to build more secure web applications.
What Happened in the Ticketmaster UK Data Breach?
On June 27, 2018, Ticketmaster UK announced a data breach incident that didn't directly affect the Ticketmaster server. It was actually a different company, Inbenta, that was affected. However, Inbenta provided the live chat systems used on the Ticketmaster website.
Using SRI to Ensure External Website Files Are not Tampered With
The answer is yes, and the method is by adopting Subresource Integrity (SRI). SRI ensures that these third-party resources are loaded without modifications. You can validate the integrity of the external files hosted on the website by encoding one or more of their SHA-256, SHA-384, or SHA-512 hashes in base64 in an integrity attribute added to script or link tags. SRI compares these expected hash values with those of the loaded resources. If there's a mismatch, the browser throws an error in its debugging console and halts the loading of the affected resource.
What Happens if There Is a Mismatch in the Hash Values?
If the hash values do not match, the script or style files won't be loaded. It's important to note that this verification and denial process only happens in browsers that support SRI. This is what an SRI error looks like:
Subresource Integrity (SRI) Could Have Stopped Ticketmaster's Data Breach
Had Ticketmaster implemented SRI for their third-party script and style resources, the browsers would have stopped the loading of the scripts, therefore, preventing malicious code from being executed.
For a detailed explanation of SRI, see Subresource Integrity (SRI) for Validating Web Resources Hosted on Third Party Services (CDNs). When you scan your website with Netsparker, it checks if your website has SRI configured and recommends remedial actions.
Safelisting Sources With Content Security Policy (CSP)
Since the release of its first version in November 2012, CSP has acted as an additional client-side security layer that defends websites against vulnerabilities, such as Cross-Site Scripting, Clickjacking, Protocol Downgrading, and Frame Injection.
CSP prevents the execution of any unexpected code and inline scripts by safelisting trusted external sources, as demonstrated in the following example:
Content-Security-Policy: script-src 'self' https://apis.google.com
However, it's also possible to safelist a hash value instead of a URL, as we've already seen when we discussed SRI.
Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='
Using the Connect-Src Directive
The connect-src: directive restricts the resources that can be loaded via interfaces, such as XHR, WebSockets, and EventSource.
Content-Security-Policy: connect-src 'self' https://thirdparty.com/end-point;
If the report-URI directive is passed together with the connect-src directive, the browser will not only block the unexpected request but will also report the violation to the specified URL in report-URI. This report will be sent in the JSON format and will include:
- The page on which the violation occurred
- The requested source that triggered the block
- The data that the malware attempted to transfer
Content-Security-Policy: connect-src 'self' https://thirdparty.com/end-point; report-uri https://www.example.com/report-uri
"violated-directive": "connect-src 'self' https://apis.google.com",
"original-policy": "connect-src 'self' https://apis.google.com; report-uri
For further information on how to implement CSP on your website, refer to our guide to Content Security Policy (CSP) on our blog.
Using Browser Security to Enhance Website Security
No protocol, policy, or system is perfect. But, as this article highlights, by using a collection of browser security features and protocols, such as the Subresource Integrity (SRI) and Content Security Policy (CSP), you will make your websites more secure and less prone to hack attacks and data breaches.
Published at DZone with permission of Ziyahan Albeniz, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.