Revising 'External Authentication Injection' Subcategory about vulnerability-rating-taxonomy HOT 6 CLOSED

Actually I tend to agree with the @EgiX , we probably should mark it as p5 for a consistent triaging process. The chrome fully mitigates this issue, and it'd be really hard to trick the user to write the credentials in firefox, given that it clearly shows testtest.com is requesting your name and password. It even shows a warning message, so this could be considered as an accepted risk in my opinion and the client should have the right to not pay for it.
Happy to hear others thoughts.

from vulnerability-rating-taxonomy.

There's still a good phishing potential in Safari and IE as I see in @EgiX's examples. Let's consider that the attacker is capable of injecting HTTP authentication into bugcrowd.com. Assuming that the attacker controls buqcrowd.com (q instead of g or something similar) and the victim is using Safari or IE the prompt will say something along these lines: "Login on buqcrowd.com:80 - Password will be sent in clear". That is still a valid issue. Also lets not underestimate how users ignore dialog messages, which would be a good enough risk factor in Firefox.

I do feel that this is more a P5 than P4 because it is often a feature to allow the users to paste image tags. Since there's no trivial fix (correct me if I'm wrong here) this kind of issues would be see as won't fix by the clients. The mitigation would be not so much disabling this type of features but monitoring abuse.

from vulnerability-rating-taxonomy.

My vote goes for P5. Yes you get prompted, but most users will click away, and the ones that don't will probably read instead of blindly typing their password anywhere

from vulnerability-rating-taxonomy.

This is what the victim will see in Safari (my actual screenshot) and IE (potentially) if the malicious server uses HTTPS (domain masked by me as it's not important) :

It is not a matter of 'if', but rather how many user accounts will get compromised. Let's look back at the historical data for this type of issues and see if they present any value to the customers before we take any steps.

from vulnerability-rating-taxonomy.

I agree that it needs to be downgraded with P5. It's also like Content Spoofing. Based on what @EdisK said that it has been mitigated in Chrome then that's a good point too.

from vulnerability-rating-taxonomy.

Closing this Issue as agreed during today's vulnerability roundtable

from vulnerability-rating-taxonomy.