←back to thread

475 points danielstocks | 9 comments | | HN request time: 0.204s | source | bottom
1. ipsin ◴[] No.27303148[source]
What are the ways you can implement "log in as anyone accidentally"?

I'm imagining it was a case of an SQL-based password check where "TRUE OR" got added to the WHERE clause, and the code takes the first result instead of expecting only 0 or 1 row.

Are there other easy ways to do this?

replies(3): >>27303178 #>>27303237 #>>27303253 #
2. nrmitchi ◴[] No.27303178[source]
From a quick glimpse on twitter, people couldn't make changes to any of the accounts they were seeing.

This points in the direction of this being a caching bug; you request your homepage, and get the homepage of whichever user was placed in the cache last.

Most of the time in these situations it's not an application-code issue (per-se), as much as a "shared global state" issue.

3. bellyfullofbac ◴[] No.27303237[source]
It's not a web system but Mac OS messed it up once: https://objective-see.com/blog/blog_0x24.html

Caching could be an issue, if they added a cache for a microservice call of /get/user?id=$USER and ignored the id parameter, /get/user?id=ipsin fetches data for the user ipsin, the system sees the next call /get/user?id=bellyfullofbac and thinks, "Wait, I have the results of /get/user in cache" and returns the data for ipsin again...

replies(1): >>27303283 #
4. ladon86 ◴[] No.27303253[source]
1) Caching: a cache is used in front of the API for things like product listings, it uses a pattern match like /api/products/*, and caches routes which match. Someone accidentally configures it to cache /api/*, and thus login responses from /api/session return another recent user session, potentially including the cookie such that subsequent requests are authenticated as that user.

2) Mentioned elsewhere in this thread, a variable with global scope within an application server. This is very possible in node.js, which uses a long-running single thread - if you have a function like handleRequest(), you might inadvertently write to a global variable outside it, and that variable will persist across requests from different users. I've seen this exact bug in a PR - luckily we caught it before production, but if it had slipped through code review and integration tests and actually shipped, the result would have been exactly like the one in the tweet.

replies(2): >>27303498 #>>27303576 #
5. chrisandchris ◴[] No.27303283[source]
Besides having the HTTP verb in the URL (GET -> /get/), why would you put the id in the query? Why not just use GET /user/1234 instead of duplicating things by using GET /get/user?id=1234 . What does GET /get/user then even return, all users, no user, ...?

Edit: typo

replies(1): >>27303850 #
6. formerly_proven ◴[] No.27303498[source]
It can be a bug in the application server as well, I recall uwsgi having issues where the request (or response, not sure) dictionaries were recycled between requests, and some corner cases didn't clear those between handling different requests, or something to that tune.
7. axiosgunnar ◴[] No.27303576[source]
Why do users get multiple other users instead of one then, if it's a global variable? I assume because Klarna is running on many servers?
replies(1): >>27303815 #
8. pfraze ◴[] No.27303815{3}[source]
It could also be that new logins overwrite the cache/global
9. bellyfullofbac ◴[] No.27303850{3}[source]
It's just an example...