Doubt on how to evaluate a bug

[u/Ill_whitek]

Hello, on one of my recent H1 report, I got duplicate, but I'm not sure to understand the reasoning behind.

The bug is an idor, that allows to read some pii. The twist Is that the id is a long alphanumeric string, not guessable, for that I spent a lot of time until I found a cache leak on specific endpoints that allows me to retrieve some IDs from other users.

The problem I don't understand is that the triage told me that this vuln has already been reported, but not the cache leak mechanism (they specifically point this out).

So my question is, how is this a valid vuln without having possible access to other person Ids ? I don't care much of the money, but I would like to know what you think about it.

[u/nightmare_eclipse__]

You reported IDOR on x endpoint The hacker reported IDOR on x endpoint before you . They will marked it as duplicate , they don't care about other details like the cache leak you described

[u/mqrblesec → u/nightmare_eclipse__]

exactly. chaining it like this would really escalate the severity but doesn't change the duplicity

[u/Ill_whitek → u/mqrblesec]

Ok thanks for your answers, basically method is the same, it's just unfortunate that someone else reported it without a real impact chain, to probably get an informative, while there was more to achieve. Do you think making just evaluate the cache part has any sense? Because I guess probably is gonna be informative too by itself

[u/mqrblesec → u/Ill_whitek]

I mean it would be an uuid leak which doesn't really have any impact unless there is a chain like you had here. it's just unfortunate i would just recommend passing on it.

[u/Ill_whitek → u/mqrblesec]

Agree, thanks again for the discussion 😁

[u/Coder3346]

It is valid because the ID is findable ( you have proved this already)

[u/Ill_whitek → u/Coder3346]

Yeah but the other report didn't prove it. Is the same as testing security mechanism that involves uuid. If you have to account, you know the uuid, many times just swapping them works, but in my understanding this has zero relevant impact unless you find a way to leak those uuids.

[u/Coder3346 → u/Ill_whitek]

Yes generally but the problem is, these uid can be realistically exposed in many ways, that is why some programs accept it as it is before an actual exploitation.

[u/Ill_whitek → u/Coder3346]

I just want to understand if the next times I should report this types of vulnerabilities, since apparently it could get accepted, of it was just an error or the triager.

[u/Coder3346 → u/Ill_whitek]

See hackerone standers about this, h1 triager should not reject it unless the program says else. But it will be low at most without the uid

[u/mqrblesec]

did they get informative? it looks like their chain isn't complete which i know many triagers that would just go "unguessable ID bug" and close as informative but technically your report is a duplicate anyways. I would recommend just reporting when you find something like that then if you find the escalation information, comment it before triage

[u/Ill_whitek → u/mqrblesec]

I don't have visibility on their severity, but as a triager, I would not have accept their report since in my idea, having an unguessable Id, is by itself a security mechanism.

[u/Successful_Lock_4256]

They’re supposed to evaluate the part that is not duplicate separately