Closed ay-kay closed 5 years ago
Hi @ay-kay , thank you for your ticket. we will pick this up soon during one of the requirements meetings.
Meeting notes:
6.11 | MSTG‑PLATFORM‑11 | Verify that the app prevents usage of custom third-party keyboards whenever sensitive data is entered. | | ✓ |
Fixed in #317
I miss a requirement in MASVS that apps with sensitive data should not support third-party keyboards. Now that a bug in iOS 13 and iPadOS can result in keyboard extensions being granted full access without approval, it's time to make this proposal for an additional MASVS requirement ("
MSTG-PLATFORM-X: The app prevents usage of custom third-party keyboards.
").So far, MSTG covers this topic slightly in the MSTG-PLATFORM-4 section, when it comes to app extensions in general, however, dealing with third-party keyboards is not mentioned there. I would suggest adding an explicit L2 requirement that support for third-party keyboards should be disabled.
This was recently discussed in #303 and closed given the complexity of the measure. However, at least in iOS, third-party keyboards can be disabled by implementing a single delegate method only. That's not very costly and actually already best practice? In Android the effort is probably higher. Obviously one has to consider whether it is worth the effort to create a custom keyboard, however, this is a case-by-case decision depending on the processed data. I do not think it is good to completely ignore that risk just because the measure is burdensome to implement sometimes.
MASVS had this requirement in the past (see 6.11:
Verify that the app provides a custom keyboard whenever sensitive data is entered.
). I would suggest changing the wording toprevent usage of custom third-party keyboards
. The measure for iOS is then simple by implementing the respective delegate. In Android one has to consider whether the effort for implementing a custom keyboard (including all the drawbacks discussed in #86) would be worth it.After all, we then clarified this risk and those responsible for the security of the respective app can decide for themselves whether they want to implement the measure or accept the remaining risk. And we don't omit a simple measure for iOS apps just because Android doesn't offer an equivalent solution.