Security: Tradeoffs

Created on November 12, 2023 at 11:25 am

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 ORG (like all engineering) is a story of tradeoffs. Tradeoffs commonly take place across multiple dimensions:








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 ORG 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 PERSON , WebBluetooth PERSON , 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 ORG considers whether to disable these APIs via Group Policy ORG , 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 GPE , type in the desired information, manually grant the website permission to use WebUSB GPE , and then update the info on the device. The overall attack surface is dramatically reduced by WebUSB GPE , because my task no longer requires running unsandboxed GPE /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 DATE , I bought a cheap clock from Alibaba in China GPE .

Setting the time on the clock requires configuration via Bluetooth ORG . 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 ORDINAL -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 CARDINAL -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 ORG over HTTP in Edge ORG as a part of following the Edge ORG security baseline:

However, this customer had hundreds CARDINAL 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 ORG such that these devices’ IPs would load in Internet Explorer Mode. The customer treated this as a workaround for the Security Baseline ORG . This only worked because they hadn’t also enabled the equivalent WinINET PERSON policy that blocks Basic-over-HTTP in IE.

Thus, the customer could claim compliance with the Edge ORG security baseline, but their workaround put the organization at far greater overall risk, because IE Mode ORG represents a huge attack surface. Allowing that attack surface to be combined with MiTM GPE -able HTTP networking means that any network-based attacker could easily exploit vulnerabilities in the legacy IE code, outside of the strong Chromium ORG sandbox in which Edge ORG 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!


Connecting to Connected... Page load complete