Why Was issue #150 merged into the VRT?

Issue We merged Copy/Paste on Sensitive content. The specific issue that brought this up, Issue #150 ends with a comment about why adding this entry is a bad idea. It also links to discussions for why OWASP also did not add this.

The end result here is that users are encouraged to always some how type out their passwords. Regardless if it’s possible to copy something from an App. The actual attack is that a random malicious app is able to read the clip board. We allow pasting to the sensitive content though. Okay that would mean the malicious app already has the sensitive data. For a password manager it would make sense the user would naturally being coping data out of it. When does a user normally copy sensitive data out of an app??? Personally I don’t remember a need to copy CC# or SSN from one app to another. For passwordsIf I copy it from an alternative source already. A malicious app would get the same access to the data regardless if I can copy the data out of the random app.

Github Issue Comment from OWASP Users will copy their password or other information only to find that they cannot paste it. So the recommendation we are having is not helping and only making the user experience worse and you are right saying that users might choose simple passwords because of that. So it actually has a bad side-effect to other security controls (password strength).

Recommendation We should remove this from the VRT as it does not actually help protect mobile apps specifically.

[plr0man]

Hi Everyone,

P5 VRT entries are there for a few important reasons, mostly disincentivizing reports of corresponding types of issues as well as providing the ASE’s with a guideline. If you look at current P5 entries you will see a broad spectrum of issues ranging in severity from what could be considered N/A to not enough to be a P4 in most situations. With how the bounties are currently run having those is essential so we can reduce noise on our side and help the researchers better spend their time. That being said whether we agree if or when this issue could be informational or if it is a firm N/A, we need to document our decision in the VRT.

[dapperrobotbear]

From a UX perspective I strongly agree. Disabling paste functionality for secure entry fields does not increase security in a form, as the act of copying has already occurred when the user discovers that pasting is not possible. This increases friction and we should not be encouraging developers/organizations to “fix” this issue under the guise that it makes them more secure.

If there is in fact a vulnerability in the paste board allowing actors to access it outside of the app context when a user access it, then the report should be on that component instead.