There’s nothing quite like an actual proof-of-concept to make everyone listen. I was pleased by the PoC released by Google security engineers Stephen Röttger and Artur Janc earlier this month – in a nutshell, they showed how the Spectre vulnerability can be used to exfiltrate cross-origin data from any website.
The Spectre vulnerability, which stems from vulnerabilities at the CPU design level, has been known for over 3 years now. What’s so interesting about this PoC is that its feasibility for leaking the end-user’s data has now been proven for web applications, meaning that it’s no longer just theoretical.
The attacker could use the web supply chain, for instance, presenting itself as a useful library so that victims voluntarily add it to their webpages, or deliberately compromise a third-party library as a way to attack websites that use it. Another vehicle would be to find an injection vulnerability on the website and combine that with the Spectre exploit.
Searching for better solutions
Because the vulnerability is hardware-based, it can’t be completely mitigated without changes at the hardware level, which will take years. In the meantime, while it’s true that Google and other browser vendors are putting in place some measures to minimize the effectiveness of this threat, much of the heavy lifting in this regard is left to website owners.
The main recommendations, for now, have been to combine multiple application-level mitigations, such as Cross-Origin Resource Policy, Cross-Origin Opener Policy, Cross-Origin Embedder Policy, and Fetch Metadata. But this still may not be enough. As Google security engineers pointed out, these mechanisms do not prevent the Spectre exploit, but rather “protect sensitive data from being present in parts of the memory from which they can be read by the attacker.”
In my view, there’s an entire protection layer missing – one that protects from within the application code itself. To further reduce the risk of data leakage, website owners should add an extra line of defense to protect the actual data in memory in the event that all other security controls. For example, they should use built-in application defenses that encrypt sensitive data in memory and only decrypt it when the application needs access to it (just-in-time access). This minimizes the time that sensitive data sits in memory in cleartext. The benefit here is that, even if attackers still manage to leak data, it will likely be encrypted and therefore, completely useless to them.
But what about the impact of this measure on performance? Doing this for all data structures in a program will probably be too impactful, but strategically applying it to a few, sensitive data structures – such as keys or authorization tokens – seems to be a good idea as the overall performance impact will likely be negligible. This approach can be made so that it has zero development cost for the development team, as it can be applied automatically during the build process of the web application.
As with all other application-level mitigations for the Spectre exploit, this memory protection technique does not completely deter the scraping of sensitive data from memory. Just-in-time access is still access – but it is a drastic reduction of the window of attack and a very good complement to all the other browser-native mitigations.
Plus, encrypting data in memory is already a requirement for high-risk applications, so it’s only natural that it becomes recommended for web applications as well in the context of Spectre mitigation – especially those that handle sensitive data such as PII, PHI, or payment information.
In the end, PoCs like these incentivize defense innovation and new forms of mitigation, especially when it is something that could potentially translate into a data leak that may universally affect all devices across the globe.
Of course, putting the final nail in Spectre’s coffin will require hardware changes – but responsible website owners cannot afford to wait for such a fix to happen when their users’ private data could be at stake. For now, their best bet is to adopt a defense-in-depth approach at the application level and protecting data in memory can bring a much-needed extra line of defense with almost zero effort involved.
As I usually say, if there’s something easy and cheap that you can do that greatly reduces the risk of data leakage in your web application, don’t wait too long to do it.