Re: We can't do that...
It's the only place where you have to run untrustable code from untrusted sources.
Unless you have a computer that runs programs in different security domains, as the vast majority of general-purpose computers do.
As a non-privileged system user, I write a Rowbleed process that runs in the background, attacking NTLM hashes. Then I use a bit of social engineering to get a domain admin to log on to my machine to investigate some mysterious "problem" I'm experiencing. I hijack the session and create a new domain admin account for myself.
My organization has some internal HTTPS servers that host applications from different departments. I have access for a lowly HR app, but I use it to run a Rowbleed attack on the private key for the server certificate. Then I impersonate the server on another machine, and with a bit of DNS cache poisoning I MITM a finance app.
We run a variety of applications on an in-house VM farm. My "test" program for some innocuous app is actually a Rowbleed attack against sensitive applications, hijacking ... oh, whatever. You should get the picture.
We run sensitive applications in a public cloud. Could untrusted code possibly be running on the same hardware? Inconceivable!
And, of course, we have the problem of untrustworthy code installed by users in vast numbers, because they have no expertise in evaluating whether they should trust it. And exploitable BOFs and other bugs in applications that process untrusted data such as image and document files. And malware injected into the software supply chain.
In short (yes, yes, too late), the idea that browsers are the only hives of scum and villainy on the typical general-purpose computer is laughably wrong.
Biting the hand that feeds IT
