Update VRT language to remove ambiguity between subcategories

[danzajork]

Background

The forward slash (/) has historically indicated "or" when selecting a VRT category.

For example, the VRT Server Security Misconfiguration > Username/Email Enumeration > Brute Force can be read as a security misconfiguration allowing an attacker to brute force usernames or email addresses. This has been the case for most VRT language to date and is the correct way to interpret it.

Issue

With the introduction of the new IDOR variants, the forward slash seems to imply "and" instead of "or". Upon further review of the more recent VRT changes, there are now additional ambiguities resulting from inconsistent forward slash usage throughout the VRT.

Examples:
Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > Modify/View Sensitive Information(Iterable Object Identifiers)

Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > Modify/View Sensitive Information(Complex Object Identifiers GUID/UUID)

Application-Level Denial-of-Service (DoS) > High Impact and/or Medium Difficulty

in some cases, the forward slash does not seem to imply either:

Cross-Site Scripting (XSS) > Stored > CSRF/URL-Based

To focus the discussion on a single ambiguity resulting from the forward slash in the above examples, I'm going to use the following VRT values from recent IDOR changes:

Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > Modify Sensitive Information(Iterable Object Identifiers)

Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > Modify/View Sensitive Information(Iterable Object Identifiers)

Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > View Sensitive Information(Iterable Object Identifiers).

If I have an IDOR that only allows for modification of sensitive information, It is unclear which VRT value to select when making the assumption that the forward slash means "or" as it typically does in English writing.

Additionally, if I have a critical or high impact IDOR that only allows for viewing of sensitive information, the current VRT implies I should select:

Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > Modify/View Sensitive Information(Iterable Object Identifiers) which is a P1

and not the following

Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > View Sensitive Information(Iterable Object Identifiers) which is a P3.

I have been told by Bugcrowd Triage that Modify/View Sensitive Information(Iterable Object Identifiers) is not the correct variant to assign for critical or high impact view-only IDORs. In my last example of a critical or high impact view-only IDOR report, Triage will remove the P1 IDOR variant from the report and reclassify the report as a P3 pushing the priority down and triage time back for both the customer and the hacker.

The Merriam-Webster Dictionary defines a slash as

a mark / used typically to denote "or" (as in and/or), "and or" (as in straggler/deserter), or "per" (as in feet/second)
https://www.merriam-webster.com/dictionary/slash

My suggestion is to standardize the usage of the forward slash to mean "or". This needs to be updated throughout the entire VRT. This should also be documented in a VRT style guide for those looking to contribute to the project, or for those looking to understand the typographical and punctuation conventions as well as common terminology used within the VRT.

An alternative to standardizing the use of the forward slash throughout the VRT, the text could be modified to not use a slash when a phrase would be clearer. For example, the VRT could be updated to use:

Server Security Misconfiguration > Username or Email Enumeration > Brute Force

in place of the current text:

Server Security Misconfiguration > Username/Email Enumeration > Brute Force

Additional example:

Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > Modify and View Sensitive Information(Iterable Object Identifiers)

in place of the current text:

Broken Access Control (BAC) > Insecure Direct Object References (IDOR) > Modify/View Sensitive Information(Iterable Object Identifiers)

Note: I had previously reported this issue and it was closed without action. I am hoping that I have added some additional information here which will bring clarity to the issue so it can get addressed.