4
ctnqhk
1y

Someone didn’t properly set the httpcookies domain for our staging and production websites. Yep, this was a C#/.NET site. The cookie domain for the staging site was set to the production domain instead of the staging domain (which was a subdomain). So if someone logged into the staging admin, that would also grant them access to production admin if they also had an account in the production site.

The staging site technically had an additional login to enter the site, but the username and password weren’t too hard to guess. It was like that for years until I was hired to be an in-house dev (the role was previously outsourced to a software development company).

The admin side of the website wasn’t very sophisticated. But there was enough personal identifying info for a hacker to do something with.

I don’t know how they weren’t hacked yet. Honestly, I’d tell my employer to go back to that software agency and ask for a refund and cite the shotty work.

Comments
  • 2
    I dont get this, even with staging/prod cookie mixup, and assuming the staging cookie-auth is sent to the prod, the point of staging is that the auth DBs between staging/prod differ
    So the cookie's JWT/RT would be rejected by the prod and all you'd have annoyed users who get auto-logged out coz cookie sessions fucked up
  • 0
    @azuredivay The staging site was setting the cookie to the main domain. When I was doing real life testing, logging into my staging account gave me access to my prod account.

    I’ve had a similar thing happen with a different employer’s products. One of their apps on a subdomain issued an auth cookie that was set to the main domain. So users who came to the main site after getting an auth cookie visiting the subdomain app were treated like they were authorized for the main site. It caused a lot of chaos for orders because these users weren’t asked to login or create an account. So we had lots of orders with mailing addresses but no email addresses to contact the customer.
Add Comment