Revise weak P4 entries

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:

• Server Security Misconfiguration > Lack of Password Confirmation > Change Email Address
• Server Security Misconfiguration > Lack of Password Confirmation > Change Password
• Server Security Misconfiguration > Unsafe File Upload > No Antivirus
• Server Security Misconfiguration > Unsafe File Upload > No Size Limit
• Sensitive Data Exposure > Sensitive Token in URL split up into P4 (in address bar) and P5 (in background, like API calls etc., also add a P5 on password reset)
• Cross-Site Scripting (XSS) > IE-Only > Older Version (IE 10/11) remove in favor of Cross-Site Scripting (XSS) > IE-Only > Older Version (< IE11) P5
• Broken Authentication and Session Management > Failure to Invalidate Session > On Logout split up into broken invalidation client side (e.g. in browser) P4 and broken invalidation server side P5

And one P4 merge:

• Broken Authentication and Session Management > Failure to Invalidate Session > On Password Change merge with Broken Authentication and Session Management > Failure to Invalidate Session > On Password Reset since these issues usually share the same root cause, one entry should prevent double reports

All feedback is appreciated!

[jstnkndy]

• 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.

[plr0man]

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