←back to thread

'123456' password exposed chats for 64M McDonald's job applicants

(www.bleepingcomputer.com)
111 points nan60 | 1 comments | 11 Jul 25 21:48 UTC | HN request time: 0.224s | source
Show context
bsuvc ◴[11 Jul 25 22:54 UTC] No.44537604[source]▶
It sounds like there were two separate problems:

The first was that 123456 was the credentials for the admin panel.

The second was an insecure direct object reference, where the lead_id querystring parameter can be changed on an API call to retrieve another applicant's data.

replies(3): >>44537968 #>>44538121 #>>44538299 #
hardwaresofton ◴[11 Jul 25 23:48 UTC] No.44537968[source]▶
A third problem that senior engineers might recognize: using numeric IDs on an outward facing object. UUIDs would have made this impossible as well
replies(3): >>44538043 #>>44538169 #>>44538538 #
lelandbatey ◴[12 Jul 25 00:24 UTC] No.44538169[source]▶
Using numeric IDs on an outward facing object is, for the most part, totally fine. It's a serious tradeoff to ditch the nice properties of numerical IDs and the legibility they provide in order to cargo-cult a "we must reveal nothing" approach, as you would here via UUID. It also misses the point of the actual security lesson: no matter the identifier, you need to be applying access controls to your data. Even if your UUIDs were generated via 100% airtight cryptographically random sources, you have to, y'know, communicate with them. That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs). If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way. Don't stress about the theoretical benefits of something like an opaque identifier and then completely neglect the necessary real world access control.

Can you tell I've been scarred by discussing designs with folks who focus on the "visible" problems without thinking about the fundamental question of "is this secure"?

replies(3): >>44538381 #>>44538590 #>>44539947 #
1. overfeed ◴[12 Jul 25 06:57 UTC] No.44539947[source]▶
> If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way.

Defense in depth is a thing, so even if you make a mistake in one place, and the attacker gets complete access - as what happened with the McApplicaton here - they won't be able to download your entire db within minutes. Even with zero authentication, non-guessable identifiers will slow down the exfiltration by several factors from dozens/hundreds of records per second to one record per $MANY_DAYS, with lots of 404s for the defenders to look at.

> That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs)

The additional friction of acquiring the UUIDs from a different channel is beneficial to defenders, compared to decrementing or incrementing IDs, which is trivial to do, and doesn't need RCE. It's the difference between "All users' data was exfiltrated" and "Only a couple/handful of accounts were affected", and this can make or break the breached company.