Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

I\'m primarily an ASP.NET developer but this question really applies regardless

ID: 651141 • Letter: I

Question

I'm primarily an ASP.NET developer but this question really applies regardless of language. So obviously it is a good idea to prevent external attacks that arise from session hijacking and csrf attacks as well. But what about internal attacks when the data involved is temporary, needed for the entire session but also sensitive and worth stealing? There is the naturally just only hire trustworthy people route, but lets say that doesn't apply.

Say it is a given you already have code reviews and strict production data access permissions to prevent theft by developers. The application encrypts sensitive data before storing to prevent theft by dbas.

How do you protect your temporary sensitive data against web server admins? It seems that they could retrieve information by inspecting web server logs, traffic sniffing and inspection of process memory contents. Naturally I would say production web server admins do not have access to the raw source code.

Explanation / Answer

If you cannot trust your own sysadmins with your servers, almost all is lost. The only way to protect sensitive data from somebody with root / administrator access to a production machine is to encrypt it against a key inaccessible to the sysadmin; for example, if the data is only ever used on the client, you could consider client-side encryption. But even then, there is nothing stopping a rogue sysadmin from just changing the server-side code that causes client-side encryption to, well, not encrypt anymore, or use a compromised encryption key. You gain little, but you sacrifice a lot of convenience and performance.

That doesn't mean you shouldn't consider temporary data from a security point of view: often, there are many users with nonprivileged access to a server; even if those can't log in directly (e.g. service accounts), an attacker who exploits other vulnerabilities may very well gain a shell with such a user. Naive use of memcache is easily exploited - you just need to connect to memcache locally, find the key you're interested in, and read the data. Tempfiles are slightly harder to get to, but certainly not impossible.

As with all things security: define your threats, find possible mitigations, and make a cost/benefit analysis.