read-only IDOR P3 requires differentiation

[foobar7]

With the new update, VRT considers all read-only IDORs P3.

But that's a really broad category of issues. It might be a same-tenant IDOR with semi-sensitive info, in which case P3 is a good fit.

It might also be a cross-tenant IDOR with access to highly sensitive info. Assuming open registration, that's CVSS High CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, so imho P3 is too low.

You could add a differentiation regarding same or cross tenant (P3 vs P2 or even P1), but that's still painting with a large brush. This might be a case for Varies, where the impact really depends on the data that is leaked.

[TimmyBugcrowd]

Hi @foobar7

I understand that IDOR can be broken down in many categories. What we've tried with these categories is to cover as much as possible. In this case, don't you think this category can cover it?
Sensitive Data Exposure > Disclosure of Secrets > PII Leakage/Exposure - Varies

This category does not specify how the sensitive information is being leaked, meaning, it could be IDOR or whatever.

Let me know what your thoughts are.

[foobar7]

Hi @TimmyBugcrowd,

What we've tried with these categories is to cover as much as possible.

I think in some aspects, that works well (eg I like that UUID IDORs are now standardized). But here it imho doesn't work.

This category does not specify how the sensitive information is being leaked, meaning, it could be IDOR or whatever.

For me, there are two issues:

1. there's a lot of sensitive data that can leak that isn't PII, but that is still well above P3.
2. when an issue fits into two categories, it's a 50-50 chance what triage will do. And if you have to eg self-register an account, IDOR is the more obvious choice.

Point 2. could be resolved by 1) assigning the category I prefer myself when opening the report and 2) educating triage. But I'd still be worried about mistakes and inconsistencies.

The more important issue is 1. An example would eg be an online forum or chat. Even if no PII leaks, all messages of all users leaking would at least be P2 in my eyes. P3 would definitely be too low. Another example would eg be the leakage of all reports on bugcrowd. P3 would just not be appropriate. And those aren't isolated examples, it's the case for a lot of data (probably most cross-tenant IDORs).

At the very least, I would separate this into:

P2 Read Highly Sensitive Information and/or cross tenant (Iterable Object Identifiers)
P3 Read semi-sensitive Information and/or same tenant (Iterable Object Identifiers)

I think it makes sense to differentiate by cross/same tenant and sensitivity of the data. I'm not quite sure about combining them into one, though having 4 different categories might be overkill. Maybe something like this could also work:

P1 Read Highly Sensitive Information - cross tenant (Iterable Object Identifiers)
P2 Read Sensitive Information - cross tenant (Iterable Object Identifiers)
P3 Read Information - same tenant (Iterable Object Identifiers)

Or maybe it's best to just stay with varies Read Sensitive Information (Iterable Object Identifiers). But imho a blanket P3 is just not the right choice.

Best,
Foobar7

[danzajork]

I just want to echo @foobar7's concerns.

A blanket P3 severity does not work for Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > Read Sensitive Information/Iterable Object Identifiers.

Preferably, the researcher should be able to set the severity when selecting Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > Read Sensitive Information/Iterable Object Identifiers. A read-only IDOR allowing access to cardholder data is very different from an IDOR allowing access to first name, last name, etc. In fact, taking the environmental score into account using CVSS 3.1, this issue (self-sign up allowing read-only IDOR with access to cardholder data) would be rated critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N/CR:H/IR:H/AR:H/MAV:X/MAC:X/MPR:X/MUI:X/MS:X/MC:X/MI:X/MA:X).

I also agree that Sensitive Data Exposure > Disclosure of Secrets > PII Leakage/Exposure - Varies does cover these use cases. Not only is the category inaccurate for the discussed use case, it also doesn't allow the researcher to select an appropriate severity to convey impact. Additionally, it allows too much wiggle room for the reviewer or customer to downgrade the severity by selecting a more appropriate VRT category.