Re:Hardcoded secrets, unverified tokens, and other common JW...
by jrockway on Saturday June 27, 2020 @02:05PM
(#23663437)
Using something stateless when you want state always leads to problems. It is very convenient, for example, when you give the end-user a token that cryptographically proves that they're a certain user. They provide that to the server, and it doesn't have to access any state to allow access, saving precious milliseconds of latency. The problem comes when someone else steals the token or the user's authorization is revoked. Since you aren't checking any state, you have no way to say "oh we fired them, kill their access" or "their token got leaked, shut it off". This leads to problems where malicious access can persist and you can do nothing about it.
I feel like the problem is generally ignored to some extent. I was writing my own (stateful, one database lookup per request) SSO system and ran into other problems. For example, how do you terminate all TCP connections that the user has open when revoking the token? No proxy I could find had that level of granularity exposed through its control plane API. They are all living in an HTTP/1.1 world where requests were short-lived, and it was acceptable to handle revocation at the next request. I kind of doubt it's ever caused any problems (employees on their last day don't seem to open long-lived gRPC connections to internal infrastructure for whatever reason), but it's one of those things that's going to burn someone someday.
(I seriously considered modifying envoy to keep track of (user, downstream TCP connection) so that they could be forcibly closed via an API when necessary, but decided a global rolling restart of the frontend proxy was acceptable in the extremely rare instance when some sort incident required terminating all of a user's TCP connections. Engineering time vs. security tradeoff. But then there are companies with 100s of developers that will ship you custom software to manage authentication, and they don't have this feature. That seems shady to me. Or maybe not so much shady, just exceedingly lazy, like they haven't really thought much about their product.)
I feel like the problem is generally ignored to some extent. I was writing my own (stateful, one database lookup per request) SSO system and ran into other problems. For example, how do you terminate all TCP connections that the user has open when revoking the token? No proxy I could find had that level of granularity exposed through its control plane API. They are all living in an HTTP/1.1 world where requests were short-lived, and it was acceptable to handle revocation at the next request. I kind of doubt it's ever caused any problems (employees on their last day don't seem to open long-lived gRPC connections to internal infrastructure for whatever reason), but it's one of those things that's going to burn someone someday.
(I seriously considered modifying envoy to keep track of (user, downstream TCP connection) so that they could be forcibly closed via an API when necessary, but decided a global rolling restart of the frontend proxy was acceptable in the extremely rare instance when some sort incident required terminating all of a user's TCP connections. Engineering time vs. security tradeoff. But then there are companies with 100s of developers that will ship you custom software to manage authentication, and they don't have this feature. That seems shady to me. Or maybe not so much shady, just exceedingly lazy, like they haven't really thought much about their product.)