Timeline for Asymmetric encryption of user's data
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 28, 2022 at 18:13 | comment | added | Polynomial |
This is also why SRI exists for enforcing the integrity of static JS/CSS resources, particularly those hosted on third party CDNs. CSP can also frustrate client-side exfiltration if you've got a restrictive connect-src directive, as long as the attacker doesn't reconfigure the CSP headers being sent by the server. You can also specify content hashes in the CSP source value for script-src, style-src, etc. directives, to further enforce SRI. Having CSP headers (re)applied at a frontend load balancer (e.g. Cloudflare Workers / AWS Lambda) is a useful form of defence in depth here.
|
|
| Oct 28, 2022 at 18:00 | comment | added | Polynomial | If users interact with the system via a web page, the attacker doesn't necessarily need to modify the server-side code, either. They could modify a static resource such as a JavaScript library or HTML template file to inject malicious JS that sends login credentials, decrypted sensitive information, and/or session token information to a third party server over XHR. This kind of post-exploitation technique isn't uncommon, either. A common tactic for compromised web stores is for attackers to redirect the checkout flow to a cloned site for payment harvesting and PAN/PII collection. | |
| Oct 28, 2022 at 17:53 | comment | added | Polynomial | I focused on the sysadmin insider threat because it was a risk that you mentioned repeatedly in your question. You're correct that E2EE modifies the temporal requirements of an attack. However, your assumption about needing additional access (e.g. to memory) is not the case; an attacker who is in a position to read the encrypted data files (in most cases this means interactive access to the server) can also trivially modify the server-side web application code/binaries to save every login credential to a file or send it to a third party server via a HTTP request. No memory dumping needed. | |
| Oct 28, 2022 at 17:41 | comment | added | Eloff | The point is not to make something secure from system admins, it's to raise the bar for both employees and hackers alike. It's not that easy to grab the key out of memory on the server during a request. It goes from needing just access to the disk + key, to needing disk + memory + at the right time. That time requirement really raises the odds of detection and limits the scope of a potential breach. | |
| Oct 27, 2022 at 20:38 | history | answered | Polynomial | CC BY-SA 4.0 |