First of all, my apologies if this sounds a bit rambly. To be clear, my intentions are not to criticize. I’m only looking to further my understanding and find a suitable solution to the these two questions:
- A: What items should be checked off to create a malware-proof web
application? Where malware-proof is defined as preventing all use
of credentials by a party other than the one the credentials were
issued to, and hardware attacks being out of scope.
- B: Are there public projects addressing A?
In an attempt to answer those myself I’ve looked around a litte bit, however, at the time of writing, and to my understanding, this goal is impossible to reach with existing tools. Below is my current understanding.
All the literature I can find on MDN, Chrome Dev Blog, Chromium Security, and elsewhere seem assume a trusted execution environment*1. Any malware that can access browser system files can compromise user credentials before they expire, if they expire. eg: with Chrome you just have to wait for the sqlite db containing cookies to hit the disk and scrape everything off it.
Naively, If one were to require the user to authenticate on every interaction, that could work, however that would be bad UX. An alternative it seems would be to have the credentials stored in a location that is inaccessible to any process, and to any identity*2 other than the one which has been authorized to use them.
That would imply some OS/Kernel level facilities to enforce process+identity authentication, and in the context of a web browser, per-origin*3 isolation and denying any cross-origin access as well. The latter may be possible using an incantation of HSTS, CORS, XFO, COEP, COOP, CSP, CORP, and CORB.
For the former however, to my knowledge there’s no secure storage type of registry in either linux or windows. It might be achievable using an hypothetical browser that is identity aware that would create a user per identity+origin, restrict all OS-level objects of that identity+origin combo to only that user, spawn at least one process using the dedicated user. That way only a malware with super user access would be able to perform unauthorized actions, but that’s not enough for the original use case. I can think of additional requirements to achieve credentials protection, even against super-user malware:
- Per identity+origin drivers and io: even with an hypothetical secure storage, if a super user can update drivers, it can install keyloggers, highjack input and redirect output to capture any and all the information in those processes.
- Hardware storage of credentials: The only surface of attack in the OS/kernel should be the process authentication, no other systems should be exploitable to capture credentials. (Eg: Storing root/key-encryption keys in a TPM)
- There are very likely other requirements.
*1 Let me know if this is wrong, I’m not sure if the Web Authentication API fits that category as this document lists it as vulnerable, (Page 22) https://icmconference.org/wp-content/uploads/A33a-Corella.pdf
*2 Business using platforms like Azure often require multiple accounts per employees to mitigate some security risks. Any isolation for those platforms would have to not only be per-origin, but per-account as well to prevent a compromised non-administrative account to exploit a vulnerability in the browser or program to get a hold of credentials of other identities stored for that same origin.
*3 To prevent the usual web attacks.