Given the increasing number of data breaches, you won’t be surprised to read that this blog post is about yet another data breach. Unusually, 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
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.
<script src="http://my2cdn.com/myscript.js" integrity="sha256-0URT8NZXh/hI7oaypQXNjC07bwnLB52GAjvNiCaN7Gc=" crossorigin="anonymous"></script>
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).
Whitelisting 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 whitelisting trusted external sources as in the following example.
Content-Security-Policy: script-src 'self' https://apis.google.com
However, it’s also possible to whitelist 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.
*** This is a Security Bloggers Network syndicated blog from Netsparker, Web Application Security Scanner authored by Ziyahan Albeniz. Read the original post at: http://feedproxy.google.com/~r/netsparker/~3/KfAGZA2E0kQ/