Absolute security is simple– put your PC in a well-guarded vault, and never power it on. But that’s not what PCs are built for, and good luck finding a job that would pay you for such advice. Security Engineering (like all engineering) is a story of tradeoffs. Tradeoffs commonly take place across multiple dimensions:
- Security
- Compatibility
- Performance
- Ease-of-use
- Privacy
- Productivity
- Cost
As I’ve written recently, the ease-of-use/security tradeoff in the HTML5 Full-screen API leads to a major risk of tech scams. On the other end, the ease-of-use/security tradeoff in the OnBeforeUnload API means that legitimate web applications are harder to use because the platform wants to limit the possibility of abuse.
Recently, an admin reached out to ask about the recommendations in the Microsoft Security Baselines for Edge. In particular, they were curious about why the baselines don’t mandate the disablement of the WebSerial, WebBluetooth, and WebUSB platform APIs, as each of these represents attack surface against devices from the browser, and the Filesystem Access API which could be used to abuse files on the user’s disk.
When an enterprise Security Admin considers whether to disable these APIs via Group Policy, it’s important to consider the full context to decide whether blocking browser APIs will reduce attack surface, or actually increase it.
In this case, these powerful APIs enable browsers to perform tasks that previously required downloading native applications. For example, instead of needing to download some random full-trust native code application to program my kid’s “smart” teddy bear with his name, favorite song, and favorite food:
… I can just go to a website that supports WebUSB, type in the desired information, manually grant the website permission to use WebUSB, and then update the info on the device. The overall attack surface is dramatically reduced by WebUSB, because my task no longer requires running unsandboxed/full-trust code from a teddy bear vendor, who may or may not have good secure development and deployment practices. At worst, I may have to reset my bear, but the browser sandbox means that my PC is not at risk.
Similarly, a few years back, I bought a cheap clock from Alibaba in China.
Setting the time on the clock requires configuration via Bluetooth. Instead of downloading some random full-trust program from an overseas vendor I’ve never heard of, I can use a trivial web app that uses Web Bluetooth to program the device.
Again, there’s no dangerous third-party code running on my PC, and no access to any device is granted unless I specifically choose to allow it.
Ultimately, all features represent attack surface. The key question for security engineers (whether platform engineers or security admins) is whether or not a given feature reduces or improves overall security — its net security impact.
My position is that these APIs, on the whole, improve the security posture of an environment to the extent that they are able to displace higher-risk alternatives (native apps).
Threat Models Aren’t Universal
As we’ve discussed before, however, threat models aren’t one-size-fits-all.
Security Admins must keep in mind that the security baselines are just that, baselines. If their environment is such that they’ve locked down their PCs such that users cannot run native apps of their choosing, then blocking advanced Web APIs probably will not harm their security posture, even if it might harm their users’ productivity.
Follow the Spirit of the Baseline
Admins should further take care to ensure that their use of the baselines maximizes their overall security posture. We recently encountered a customer who had disabled Basic Authentication over HTTP in Edge as a part of following the Edge security baseline:
However, this customer had hundreds of legacy devices that require Basic authentication and are only accessible over HTTP. To enable them to keep working in the face of the baseline’s restriction, the customer configured Edge such that these devices’ IPs would load in Internet Explorer Mode. The customer treated this as a workaround for the Security Baseline. This only worked because they hadn’t also enabled the equivalent WinINET policy that blocks Basic-over-HTTP in IE.
Thus, the customer could claim compliance with the Edge security baseline, but their workaround put the organization at far greater overall risk, because IE Mode represents a huge attack surface. Allowing that attack surface to be combined with MiTM-able HTTP networking means that any network-based attacker could easily exploit vulnerabilities in the legacy IE code, outside of the strong Chromium sandbox in which Edge loads content. The customer would be far more secure if they simply ignored the “No Basic over HTTP” requirement for their unique environment.
Stay safe out there!
-Eric
text/plain 