search

bugcrowd / vulnerability-rating-taxonomy

Bugcrowd’s baseline priority ratings for common security vulnerabilities
https://bugcrowd.com/vrt
Apache License 2.0
443 stars 84 forks source link

Revise weak P4 entries #133

Closed plr0man closed 6 years ago

plr0man commented 6 years ago

We are in the process of reconsidering what is seen as noise/accepted risk, based on our experience with the majority of our customers, their expectations and minimal security risk. At the same time if any customer does find those findings valuable, they are offered the option to accept some or all P5 issues or redefine default priorities in the brief. Please see the list of proposed P4 to P5 downgrades:

And one P4 merge:

All feedback is appreciated!

DarkieDuck commented 6 years ago

These changes look good to me but there are two entries that might be up for disccusion

Personally I think these are just best practice and should be placed in P5 but others might think they are actually P4 worthy. Without any other bug in the chain(like CSRF) the two mentioned entries are useless anyway?

jstnkndy commented 6 years ago
abdullah-bigshow commented 6 years ago

Totally agree with sir Justin Kennedy!

On 22 February 2018 at 19:50, Justin Kennedy notifications@github.com wrote:

-

I think the Lack of Password Confirmations should remain at P4. It's important to confirm the person is who they say they are when making important account changes.

I would be fine with Unsafe File Upload being moved to a P5.

Sensitive Token in URL looks mostly fine, but I would keep password reset token at P4 if it's not invalidated.

XSS on older versions of IE should remain a P4 in my opinion, there are a number of people who are unable to properly upgrade their browsers due to other application requirements. It's unfortunate, but it's true, and technically it's still a problem with the application that we are testing.

Failure to invalidate session on logout - can you explain why client would remain a P4 while server-side would be a P5? Isn't it a bigger deal that the session isn't invalidated on the server where it needs to be?

Failure to Invalidate Session On Password Change - these should remain a P4. As a user, if my account is compromised and I change my password, that should be assurance that any previous sessions were invalidated. As an attacker, if I compromise someone's account, and I now have a valid session, if that session isn't invalidated when they change their password, I still have access to that account with my valid session.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bugcrowd/vulnerability-rating-taxonomy/issues/133#issuecomment-367694877, or mute the thread https://github.com/notifications/unsubscribe-auth/AeicRVqAGCPNy8GPjJr_MXnwQSHdGtdwks5tXXezgaJpZM4SLDDv .

plr0man commented 6 years ago

I think the Lack of Password Confirmations should remain at P4. It's important to confirm the person is who they say they are when making important account changes.

Since the session has to be compromised first in this case, it is often considered as best practice rather than an actual vulnerability.

XSS on older versions of IE should remain a P4 in my opinion, there are a number of people who are unable to properly upgrade their browsers due to other application requirements. It's unfortunate, but it's true, and technically it's still a problem with the application that we are testing.

Can you elaborate on this problem? Would it only refer to IE 10 or even older / other browsers?

but I would keep password reset token at P4 if it's not invalidated

Yes, you would be referring to P4 Insufficient Security Configurability->Weak Password Reset Implementation->Token is Not Invalidated After Use, which remains unchanged. We would be adding a P5 for sensitive token present in password reset URLs

Failure to invalidate session on logout - can you explain why client would remain a P4 while server-side would be a P5? Isn't it a bigger deal that the session isn't invalidated on the server where it needs to be?

To clarify the client side should actually be "client + server side" P4 and "server side" P5. The former would be a completely broken logout function and the latter is more of a best practice as the attacker does not have access to sessions stored on the server (unless there's a breach). Let us know you disagree.

Failure to Invalidate Session On Password Change - these should remain a P4. As a user, if my account is compromised and I change my password, that should be assurance that any previous sessions were invalidated. As an attacker, if I compromise someone's account, and I now have a valid session, if that session isn't invalidated when they change their password, I still have access to that account with my valid session.

Agreed, looks like this one might be unclear, sorry for that, I will correct it there. It would not be a downgrade, but a merge with "On Password Reset" and as a one entry they would remain P4

jstnkndy commented 6 years ago

Since the session has to be compromised first in this case, it is often considered as best practice rather than an actual vulnerability.

The same could be said for authentication over cleartext protocols such as HTTP. An attacker has to be in a privileged position first before they can actual steal the credentials. In itself, login over http is not a vulnerability, but rather a best practice.

Can you elaborate on this problem? Would it only refer to IE 10 or even older / other browsers?

Older browsers as well. At the end of the day, the application is still developed in a vulnerable way.

To clarify the client side should actually be "client + server side" P4 and "server side" P5.

The only thing that matters is the server side. If I click a "logout" button and the server properly invalidates on the server side, my session token no longer works, even if the cookie is deleted on the client.

plr0man commented 6 years ago

Since the session has to be compromised first in this case, it is often considered as best practice rather than an actual vulnerability.

The same could be said for authentication over cleartext protocols such as HTTP. An attacker has to be in a privileged position first before they can actual steal the credentials. In itself, login over http is not a vulnerability, but rather a best practice.

I don't believe we're talking about the same risk:

To clarify the client side should actually be "client + server side" P4 and "server side" P5.

The only thing that matters is the server side. If I click a "logout" button and the server properly invalidates on the server side, my session token no longer works, even if the cookie is deleted on the client.

Correct. What is the risk if server side is not invalidated but client side is (cookies being purged)?

plr0man commented 6 years ago

General question: do you believe that login over HTTP in staging environments should have the same VRT severity rating as in production? Please explain if you have an opinion and note that we're talking about a VRT baseline, not a particular situation

truemongo commented 6 years ago

Hi @plr0man,

In my opinion, login over HTTP on staging environments should be less severe (same way that "use of default credentials" is currently less severe on staging than production). Additionally, with login over HTTP on a production site, you still have a reasonable chance to catch someone logging in over public Wi-Fi (if its a large target); with staging, that chance is very small, with maybe 10 people in the world having access to staging. :)

In the context of "weak entries" I'd like to suggest reconsidering issue #120. With Flash being blocked by default by most modern browsers, I find it is almost equivalent to the "Older Version of IE" issue being discussed here, though in the case of Flash I'd probably still consider it P4 for a bit longer, not P5.

jhaddix commented 6 years ago

In my opinion, login over HTTP on staging environments should be the same severity. Most often these systems are staging so that employees of a company can test features. Credential theft of these systems is highly valuable.

jstnkndy commented 6 years ago

But the likelihood of that is much much much lower. Should the VRT cover worst possible impact for every entry?

truemongo commented 6 years ago

@jhaddix ,

In my opinion, login over HTTP on staging environments should be the same severity. Most often these systems are staging so that employees of a company can test features. Credential theft of these systems is highly valuable.

Okay, but then "use of default credentials" on a staging system should also be the same severity as "use of default credentials" on a production system, if we're being consistent. Ultimately the impact is exactly same as for login over HTTP - attacker gains access to the system.

plr0man commented 6 years ago

We reopened the Flash related Issue #120 for further discussion. Regarding login over HTTP in staging environments let's communicate in #135 (I shouldn't have asked this question here to begin with).

@jstnkndy looks like there's last question from you that remains unanswered here:

Can you elaborate on this problem? Would it only refer to IE 10 or even older / other browsers?

Older browsers as well. At the end of the day, the application is still developed in a vulnerable way.

We do not recognize PoCs that can't be performed on modern browsers as a general rule. If that was not the case entires like RFD or JSON Hijacking wouldn't have P5 baselines. Regarding IE 10, it is no longer supported by Microsoft https://www.microsoft.com/en-us/windowsforbusiness/end-of-ie-support and this change would get the VRT up to date