Real painful that it's a business intelligence platform that leaked this. The optics of the tool you use for tracking users getting exploited ain't great.
Companies need to be taking this stuff seriously yesterday. If this is indicative of the next few years, we need client side certs and simple, vetted, trusted HTTP proxies in front of all web facing services immediately. The technical overhead for this on employee machines has always been marginal, but annoying. It absolutely has to be paid now.
Pretty glad I didn't pull the trigger on one of these, but admittedly this isn't the worst data leak imaginable.
Interesting but not surprising to see that it's due to the /api/session/reset_password endpoint probably having some faulty logic. Important, yet not commonly used enough or interesting enough, business-wise, that it receives attention after it's been deployed.
Agreed. This is the sort of thing which gets cranked out at POC and hardly anyone looks at, unless you do an audit or hire a security team. Which I can't imagine these folks did.
At least their devs will be able to justify frequent audits now, but it's unfortunate that many companies need to relearn these lessons.
kacey | a day ago
Here's the metabase blog post. Thoughts:
[OP] Liru | a day ago
Interesting but not surprising to see that it's due to the
/api/session/reset_passwordendpoint probably having some faulty logic. Important, yet not commonly used enough or interesting enough, business-wise, that it receives attention after it's been deployed.kacey | 23 hours ago
Agreed. This is the sort of thing which gets cranked out at POC and hardly anyone looks at, unless you do an audit or hire a security team. Which I can't imagine these folks did.
At least their devs will be able to justify frequent audits now, but it's unfortunate that many companies need to relearn these lessons.
moonwalker | 2 hours ago
I got a similar email from Tally so it seems this wasn't targeted at Framework specifically