BAC -> IDORs in Different impacts

[bsysop]

Hey all,

Something I used to see, is when you find for example an IDOR and an attacker could leak PII, financial data, etc, you can't select the proper priority/impact of the report.

An IDOR leaking PII is clearly a P1, but if you select the VRT IDOR, you will choose an IMPACT NONE, which means it will take more time to triage and properly fix.

My suggestion is to create new IDOR categories.

• IDOR leading to PII / Financial data or critical actions P1
• IDOR leading to medium actions P3
• IDOR leading to non-sensitive data. P4

Thanks.

[jquinard]

Thanks for reaching out! This has actually been a heavily debated topic over the years. Unfortunately, while we agree with you that this granularity would be nice, in practice this wouldn't work. In our experience, researchers almost always pick the highest priority available for a given vuln class, even when the report clearly falls within a well defined lower one. If we introduced a P1 IDOR variant, almost every reported IDOR will be submitted as a P1, which would likely result in even longer triage times for legitimate critical IDOR issues and would certainly delay other critical vuln classes.

[bsysop]

Hey @jquinard, got your point and it makes sense.

What if added to the VRT selectbox, have a simple checkbox Are you able to access other users PII? If the reporter mark the checkbox, then that report needs a bit more attention.

If someone abuses it, then there is the CoC, which could be added a new "Behavior type" (VRT Abuse) and flag it.

[jquinard]

That is a good idea however the amount of work it would take to bake this into the VRT and platform would be too significant at this time. I can't reveal anything however I believe this may be something we will be able to address, through alternative solutions, in the future though.

[bsysop]

Got it, thank you J!