[bsuvc]

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.

[thaumasiotes]

> It sounds like there were two separate problems:

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

No. 123456 was the credentials for the test setup, which contained nothing. But you could use the IDOR to access data from the test setup.

If 123456 had been the credentials to the admin panel, there would have been no point in exploiting an IDOR - as an admin, you can just look at whatever you want.

[hardwaresofton]

A third problem that senior engineers might recognize: using numeric IDs on an outward facing object. UUIDs would have made this impossible as well

[lelandbatey]

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"?

[jszymborski]

Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical IDs but also the secrecy of UUIDs by using an HMAC ?

With HMAC, you can still ask for some sequential IDs

SipHash128(0, KEY) = k_0

SipHash128(1, KEY) = k_1

You get the same number of bits as a UUID.

You can't, however, sort by IDs to get their insertion sequence, however. For that you'd need something like symmetric encryption but this is already a bad idea, no reason to make it worse.

[bsuvc]

Not impossible, just more difficult to guess.

"Security through obscurity" isn't really good enough.

[Natsu]

123456 was both the username & password, they were hit by CWE-1392 because someone failed to change the default credentials.

[thaumasiotes]

The writeup never claimed that 123456:123456 were default credentials?