3 ms·
I doubt anyone left something that logged the plaintext password. No reasonable architecture necessitates holding onto a plaintext password for more than one li
by chatmasta 9y ago
I doubt anyone left something that logged the plaintext password. No reasonable architecture necessitates holding onto a plaintext password for more than one line of code.
One possibility is an HTTP server on the request path after TLS termination. But then why is an HTTP server logging the request body?
My guess would be some sort of instrumentation process was blindly reading data in memory without distinguishing what the data was, but produced logs that incidentally included passwords.
- miragle 9y agomany reasonable architectures funnel the request body through multiple middlewares before it reaches the code that actually needs the password. there are so many places that request data can be logged in any reasonable system. this is completely ordinary. it's not like there's a special HTTP mechanism for transmitting passwords that keeps it out of the normal code flow. it's in the request. if you log requests, you're probably going to end up accidentally logging something you're not supposed to at some point.
- testplzignore 9y agoIn my experience, I've seen both of the following scenarios: POST request comes in from the client. Full URL and request body is logged. Sometimes for simply troubleshooting, sometimes for security reasons (e.g., wanting to know all data coming in so that it's possible to identify security holes after they've been exploited). POST request comes in from client. Frontend server makes a GET request to a backend server, and the password ends up in the standard request logs. In one case, I've seen this happen because the developer thought path variables were cool, so every API they wrote looked like /a/b/c/d/e. Sigh.