4 ms·
Reminds me of an ancient Roblox hack I heard about, where they had a non-production staging version of the website that users could sign up for (with accompanie
by chc4 3y ago
Reminds me of an ancient Roblox hack I heard about, where they had a non-production staging version of the website that users could sign up for (with accompanied "nothing here is permanent" banner). A new administrator user account was added to production, and someone was able to register the same staging site username and use it's cookies and tokens in order to hijack the production account and compromise the site. I can't imagine these types of problems are that uncommon: if you generate cryptographic tokens based off username or user ID that doesn't have a different secret for production/staging, if your staging site talks to other external services that mix up permission grants for production, etc.
- Guillaume86 3y agoI once implemented delivery APIs for e-commerces, DHL etc... We did deliveries for months with labels printed from a test api (forgot to switch to prod servers), the packages did get delivered but we weren't billed. We came clean as soon as we realized what happened :).
- hrrsn 3y agoSome years ago, I was working at a small retail store and we built a new site, going live with Stripe in test mode. That one took a few months to notice.
- nikau 3y agoThis is why audience fields exist in tokens
- hsbauauvhabzb 3y agoAs trivial as your statement sounds, thanks for finally explaining something which to me never made sense under most conditions :-)
- satya71 3y agoBut most auth implementations don’t bother checking it.
- quickthrower2 3y agoThis attack must rely on secrets being the same in prod and test. They should also solve that problem!