Everyone understands the benefit of pervasive HTTPS. But it seems odd when you realize it only secures a direct connection to the least trusted server-side component -- the frontend web server.
1
1
Is there a standard web framework or design pattern for encrypting data at the client that is intended for consumption by a backend system (as opposed to the frontend)?
4
1
You can use Web Crypto with public key to encrypt data in browser, then use private key in backend system to decrypt it. If frontend system is compromised, won’t have private key, but attacker could subvert web page and cause browser to send in plaintext.
1
1
So yeah, heh... 1) You _have_ to trust the frontend because it's entirely in control of the content being served. 2) Frontends are universally horrible.
2
1
So I guess like @Gok was saying, there would need to be a new kind of browser UI at the client involved in any solution. ...and there would need to be a way for the user to authenticate to it independently of the frontend.
1
1
Perhaps signed widget that comes out of the backend signed, preventing the frontend from modifying it (could omit it though), then the client can verify signature. Probably a million ways to subvert though...
1
You can't trust the frontend for authing the client though, that needs to be solved too.
2
Replying to @randomdross @Gok
If backend-signed widget is delivered to client, client can send back encrypted creds that only backend can decrypt. Or use FIDO / WebAuthn.

Apr 4, 2019 · 4:29 AM UTC

1