4 ms·

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 th

by ipsin 5y ago

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?

nrmitchi 5y ago
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.
bellyfullofbac 5y ago
It's not a web system but Mac OS messed it up once: https://objective-see.com/blog/blog_0x24.html 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...
- chrisandchris 5y ago
  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
  - bellyfullofbac 5y ago
    It's just an example...
ladon86 5y ago
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.
- formerly_proven 5y ago
  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.
- axiosgunnar 5y ago
  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?
  - pfraze 5y ago
    It could also be that new logins overwrite the cache/global

by ipsin 5y ago

nrmitchi 5y ago

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.

bellyfullofbac 5y ago

It's not a web system but Mac OS messed it up once: https://objective-see.com/blog/blog_0x24.html 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...

chrisandchris 5y ago
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
- bellyfullofbac 5y ago
  It's just an example...

ladon86 5y ago

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.

formerly_proven 5y ago
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.
axiosgunnar 5y ago
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?
- pfraze 5y ago
  It could also be that new logins overwrite the cache/global