Our newly released Vulnerability Rating Taxonomy is a resource outlining Bugcrowd’s baseline priority rating for vulnerabilities that we see often.
We use this living document internally, and hope that by communicating our rating externally, we can bolster communication and transparency between researchers and program owners across all programs.
Download the full VRT with accompanying use cases, considerations and implications, and give us your thoughts.
Hi Bugcrowd folks and fellow bug hunters out there, I’m not sure where else to ask this question – been choosing between posting it here or raising an issue on Github but decided to post here because of the recent shout from @samhouston on Twitter. I am wondering if there are any channels where people can discuss the actual descriptions of the VRT entry. While most of the items in VRT entry are pretty straight-forward, some have room for confusion.
For example, there is this VRT entry – “Broken Authentication and Session Management > Failure to Invalidate Session > On Password Change” – what exactly is the scenario for this VRT entry?
Here are 2 possible options:
Option 1. Only invalidate other sessions apart from the currently active session
Option 2. Invalidate all sessions including the currently active session
Some would choose option 1, some would choose option 2 – we just need to be consistent.
Take the following scenario:
An attacker has stolen a user’s active session through session fixation or cookies hijacking. This means that the attacker has the exact same session as the user. By invalidating the current user session, it makes sure no one else is on the account who is not meant to have access.
Now, the user know that something is fishy with their account, they decided to change their password, thinking that this protected them from attackers. But, if it is option 1, they are still under attack because the attacker is having the same session as him/her, which does not get invalidated on password change. Now, the user has been tricked by the web application that they trust, thinking that they are safe after changing their account password.
Some said that option 2 has some usability problem because people may not want to enter their password twice. Well, I find it perfectly fine since the actual user changed the password, it should not be an issue for him/her to log in again immediately. I have already seen many applications that do it this way and I don’t think there is any problem with it. Alternatively, if there is really usability problem with option 2, you can assign a new session ID to the user while terminating the previous session ID - this will be transparent to the user and will not affect usability.
Any thoughts from the community on this? Will love to hear from you folks on this.
Hey @kongwenbin! Thanks for posting the question. I pinged the sec eng team at Bugcrowd about this and they’d like to have this conversation (at least the side of the convo w/bugcrowd’s sec eng team) on their Github project, that way they can keep everything there.
If you don’t mind, please feel free to post a question or discussion on the Github project here: https://github.com/bugcrowd/vulnerability-rating-taxonomy/issues
Hi @samhouston, sure I’ll start a discussion over there shortly on the same topic 
UPDATE: here’s the link: https://github.com/bugcrowd/vulnerability-rating-taxonomy/issues/154