Content Security Policy
Regular readers will need no introduction to CSP, a powerful application security defence mechanism that I've talked about extensively. CSP nonces are a feature within CSP that allows you to tackle serious problems like Cross-Site Scripting (XSS) in a much easier way. I've talked about how we do CSP nonces the easy way with Cloudflare Workers and how Report URI is now using CSP nonces in an enforced policy, and it's our use of CSP nonces that drew some attention.
Hack Yourself First
For those not familiar with the Hack Yourself First Workshop, it's a 2-day, hands-on workshop tackling some pretty serious application security issues. We spend most of our time hacking into a demo application and walking through the remediation steps. Originally created by Troy Hunt, I've since teamed up with him and even found genuine security issues in other applications during the workshop. There's also that time that someone hacked a car...
I love delivering these workshops because, alongside getting to play around with security issues for 2 days, I get to meet awesome people at various organisations and hear from them about what's actually impacting them. Whilst working through the XSS section and demonstrating how CSP and CSP nonces could save you, it was during a recent delivery of the workshop that someone noticed something.
There's a pattern
As Report URI is using an enforced CSP with nonces, I often demo the site as I can also show how we do it and provide more detailed answers to questions. It was during this demo section that a couple of attendees, Jon Are Rakvåg from SpareBank 1 and Johannes Aaram Ringstad from Fremtind, noticed that there was a pattern emerging in our CSP nonces across page loads. It didn't take too many refreshes of the page to see that they were right. I fired up Burp and grabbed 1,000 CSP nonces from our home page. Here's the first 20 and I think you can already see the pattern emerging.
Looking at our code to see how we generate our CSP nonce values, remembering we do this in a Cloudflare Worker, you can see where the pattern is coming from.
let cspNonce = btoa(crypto.getRandomValues(new Uint32Array(2)))
I have a demo worker here in the playground that you can try out, but the problem is that we're base64 encoding a numeric value. This means that, due to how close together values are in ASCII, we can explain the pattern at the beginning of the nonce.
btoa(0) >> MA==
btoa(1) >> MQ==
btoa(2) >> Mg==
btoa(3) >> Mw==
btoa(4) >> NA==
btoa(5) >> NQ==
btoa(6) >> Ng==
btoa(7) >> Nw==
btoa(8) >> OA==
btoa(9) >> OQ==
Here's a worker to demo it, but the base64 is basically saying 'this always starts with a digit', which is correct. We did go a little bit deeper though, because it was a room full of technical people and we love geeking out on this stuff!
Jon showed that using Burp we could grab a selection of nonces and do some analysis on them. I took this one step further and retrieved 1,000 nonces, just to make sure we had a good sample, and ran the same analysis which I'm providing here. It seems that Burp was estimating we only had 38 bits of entropy in our nonces, when the specification recommends 128 bits.
What was even more interesting was looking at how much entropy there was for each bit and character in the nonce itself. There's a low value for the start of the string given the base64 pattern explained above, and that Burp pads tokens that are shorter than the expected size. There's also a lack of entropy in the middle of the string where the comma separates the two different 32bit numbers.
Just to really drive the final nail into the coffin, we looked at the Shannon Entropy score using CyberChef.
It's safe to say that the observation was 100% correct, and we didn't really need to do any investigation to confirm that. With regards to the problem itself, we have to look at how nonces work to understand if this presents a real issue, but for me, we were going to fix this regardless. With ~38bits of entropy in the nonce I doubt that any attacker could leverage this in a useful way but that's not the point, it shouldn't be this way and it's an easy fix, so we fixed it!
After a brief discussion on the issue, we had a ticket open and Michal got to work on improving our nonce generation code. It took only a matter of minutes for him to have the PR up and ready for review, with the new nonce generation code looking like this.
let cspNonce = btoa(String.fromCharCode(...crypto.getRandomValues(new Uint8Array(18))))
I setup a worker in the playground here so you can see the new code in action but the trick is the
String.fromCharCode. As we were previously base64 encoding only digits, there were only 10 possible values that could be present in the string, 0-9. Now that we're switching to characters from the
Uint8 there are 255 possible characters that could be present in the string. Michal also switched us up to using "18 bytes because 16 bytes would have two trailing
==, so we can as well use those positions." As you can see in a sample of 1,000 nonces using the new code, things are looking much better! Here's the top 20.
I also ran the analysis again in Burp and things are looking considerably better with ~130bits of entropy estimated from our 144bits.
We also managed to improve the entropy of all bits across the nonce as we no longer have the common starting characters and the comma in the middle of the string.
Finally, the Shannon Entropy now seems much better and more aligned with what we'd like!
You can now head over to Report URI and view the source on our page to see the CSP nonce, or check the header itself, and observe our newer, more random nonces!