Closed cybercybercyber closed 7 years ago
cybercybercyber
commented
7 years ago Might be worth to also mention not to put sensitive information into temporary files, or to use temporary files safely (e.g. https://developer.apple.com/library/content/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html#//apple_ref/doc/uid/TP40002585-SW10)
muellerberndt
commented
7 years ago I think this section is suffering from not having "sensitive data" defined. If "sensitive data" is referring to credentials only, then I guess most of the requirements make sense. If sensitive data is supposed to be any "private" information, I think they are way overreaching.
"Sensitive data" is purposely not defined in the MASVS, as what constitutes data must be defined for each particular app. IMHO this is something that's missing from V1 - a data security policy must be defined that in accordance with business/compliance requirements, etc.
2.1: Maybe turn this around and say that for sensitive data such as credentials or keys, the appropriate credential storage facilities provided by the platform have to be used.
Isn't that what it already says?
2.3: I don't agree with this requirement, or at least I think it's way too broad. On the one hand, sensitive data is ill-defined, on the other hand it doesn't specify what kind of cloud storage this refers to. E.g. an application may come with it's own cloud-based backend and it may be core to the application's functionality to synchronize the user's mobile data (e.g. any application that has a web and a mobile interface comes to mind).
Good point. How about making this requirement more specific. Currently, the test case in the MSTG deals with backups to the cloud - I've raised an issue there as well.
2.4: Again, this seems to interfere with basic functionality of applications, and I don't think the standard should postulate requirements that prevent large classes of use cases. To give an extreme example, say my backend runs on AWS. Can my mobile application send sensitive data to my own back end considering AWS is a 3rd party? Mashups are impossible as well - if you consider an address sensitive information (which depending on the context it can be), an application using a map service to show the location is sending sensitive data to a 3rd party.
The intention behind this requirement is to prevent involuntary leakage of sensitive data to external services, such as Analytics. This can perhaps be addressed in the same way as 2.3. It all hinges on having a better definition of "sensitive data" and "external services".
2.7: This can be necessary functionality for two cooperating applications. Pretty much any application that provides a "share via hangouts" or "share via whatsapp" feature would violate this requirement. I think it would be better to either require user consent (e.g. in the sharing case), or properly authenticated IPC mechanisms.
Pretty much any application that provides a "share via hangouts" or "share via whatsapp" feature would violate this requirement.
That's an unexpected way to read this requirement but I see what you mean. It is meant to say "don't export sensitive activities / content to other apps via IPC". AFAIK sharing via Whatsapp or other apps would work the other way round.
2.8: A common feature in mobile applications is to allow the user to view the password they just entered. Entering cc#s through password fields also seems impractical from a UX perspective.
Classical security vs. usability tradeoff. IMHO it's best practice to mask passwords being entered. Credit card numbers should generally be masked in the UI. Credit card numbers just being entered is an edge case - yes, that would be a bit crappy from an UX perspective.
2.9: What is backups referring to?
Backups that are automatically generated by the OS. Note that the test cases in the OMTG provide more context and details for each of the requirements, e.g.:
As we're now working on the test cases in the MSTG, we're discovering that some requirements that sounded like a good idea at first don't work in practice, and we're gonna scrap those that don't.
2.11: on the one hand: what's the threat model this is designed to protect against? A rooted phone? Someone disassembling the phone and reading the memory chip directly? In both cases the attacker will have access to the credential even if it's stored properly in the platform's credential store. On the other hand: Do all mobile platforms support this via official API calls? If not, I doubt that it would be very effective. For example, AFAIK in java strings are immutable, so even if you try to overwrite the string that has the credential, Java will instead just create a new string (and the previous one will be garbage collected, and potentially overwritten/zero'ed out later-on, but the developer has no control over when that happens). IMO, this is only useful if supported by the platform with a guarantee that the data is in fact removed from memory.
Defense-in-depth measure. In Java, you can use byte arrays instead of Strings an "nullify" them after use.
In both cases the attacker will have access to the credential even if it's stored properly in the platform's credential store.
Ultimately, an attacker with physical/root access always wins, we just want to raise the bar by a certain amount (see also MASVS-R).
2.12: Maybe encourage (but not require) a remote locking mechanism where appropriate?
We could add this to V1?
2.13: I'm a bit torn on this one. Of course it would be great if everyone had their phone locked, but the question is if it's the application's job to force users to do so. It may also quickly become complicated, e.g. if two applications have conflicting device access policies (e.g. consider one application requiring a password, and another one requiring finger print auth).
I think it's a good control. Sometimes, it's forcing the user to do stuff for their own good is necessary :) Think about regular password policies in web apps, etc. Don't see the potential conflict as I assume you'd require a minimum policy. Also note that all these "hardcore" controls are MASVS-L2 controls, which is the "defense-in-depth" level. Agreed that it's a bold requirement though!
muellerberndt
commented
7 years ago 2.4: Again, this seems to interfere with basic functionality of applications, and I don't think the standard should postulate requirements that prevent large classes of use cases. To give an extreme example, say my backend runs on AWS. Can my mobile application send sensitive data to my own back end considering AWS is a 3rd party? Mashups are impossible as well - if you consider an address sensitive information (which depending on the context it can be), an application using a map service to show the location is sending sensitive data to a 3rd party. The intention behind this requirement is to prevent involuntary leakage of sensitive data to external services, such as Analytics. This can perhaps be addressed in the same way as 2.3. It all hinges on having a better definition of "sensitive data" and "external services".
I think it is fair to say that in contexts where location is considered highly sensitive, it should not be sent to third-party map services.
It probably also hinges on what you consider a "third-party" - that's a difficult one. I'm unsure whether hosting a back-end on AWS fall into this category. You're using a third part for hosting but you do have a certain level of control. On the other hand, if I'd be storing credit card numbers of client I'd probably not use AWS for hosting.
muellerberndt
commented
7 years ago I think I have addressed all issue now. Please check out the current version in cyberx3.
commjoen
commented
7 years ago Hi all, first of all: @cybercybercyber thank you for so much feedback, it is good to sharpen up indeed! Given the new version in master/cyber3x I was wondering: maybe we
Alternatively we could state something about "authentication information" "high-sensitive" information (E.g. credit card numbers, large set of PII details) or "sensitive" (PII, emailadresses, etc.) and then revisit this part? Would that help?
For 2.3: If a proper risk assessment & process has been applied on the architecture, then there should not be any problem to store teh data on a service such as AWS right? As long as the right controls are taken when sharing the information.
sushi2k
commented
7 years ago @commjoen As the description of the test case for 2.4a and 2.4b in the MSTG would be the same, I would say we keep the requirement as one. We can still differentiate in the test case to look for both. Need to look into detail if on Android and iOS the keyboard cache is deactivated by default for passwords. Not sure about that.
commjoen
commented
7 years ago @sushi2k that is true, but the data under test would be different i guess
sushi2k
commented
7 years ago @commjoen Yes, so we could focus on both in one test case.
commjoen
commented
7 years ago @sushi2k true :)
muellerberndt
commented
7 years ago Again, references to the MSTG test cases are needed. I'll add placeholders for now.
muellerberndt
commented
7 years ago Also changed 2.8 to:
"No sensitive data is included in backups generated by the mobile operating system. "
muellerberndt
commented
7 years ago Issues have been addressed & no more comments incoming so I'm closing this.
I think this section is suffering from not having "sensitive data" defined. If "sensitive data" is referring to credentials only, then I guess most of the requirements make sense. If sensitive data is supposed to be any "private" information, I think they are way overreaching.
2.1: Maybe turn this around and say that for sensitive data such as credentials or keys, the appropriate credential storage facilities provided by the platform have to be used.
2.3: I don't agree with this requirement, or at least I think it's way too broad. On the one hand, sensitive data is ill-defined, on the other hand it doesn't specify what kind of cloud storage this refers to. E.g. an application may come with it's own cloud-based backend and it may be core to the application's functionality to synchronize the user's mobile data (e.g. any application that has a web and a mobile interface comes to mind).
2.4: Again, this seems to interfere with basic functionality of applications, and I don't think the standard should postulate requirements that prevent large classes of use cases. To give an extreme example, say my backend runs on AWS. Can my mobile application send sensitive data to my own back end considering AWS is a 3rd party? Mashups are impossible as well - if you consider an address sensitive information (which depending on the context it can be), an application using a map service to show the location is sending sensitive data to a 3rd party.
2.7: This can be necessary functionality for two cooperating applications. Pretty much any application that provides a "share via hangouts" or "share via whatsapp" feature would violate this requirement. I think it would be better to either require user consent (e.g. in the sharing case), or properly authenticated IPC mechanisms.
2.8: A common feature in mobile applications is to allow the user to view the password they just entered. Entering cc#s through password fields also seems impractical from a UX perspective.
2.9: What is backups referring to?
2.11: on the one hand: what's the threat model this is designed to protect against? A rooted phone? Someone disassembling the phone and reading the memory chip directly? In both cases the attacker will have access to the credential even if it's stored properly in the platform's credential store. On the other hand: Do all mobile platforms support this via official API calls? If not, I doubt that it would be very effective. For example, AFAIK in java strings are immutable, so even if you try to overwrite the string that has the credential, Java will instead just create a new string (and the previous one will be garbage collected, and potentially overwritten/zero'ed out later-on, but the developer has no control over when that happens). IMO, this is only useful if supported by the platform with a guarantee that the data is in fact removed from memory.
2.12: Maybe encourage (but not require) a remote locking mechanism where appropriate?
2.13: I'm a bit torn on this one. Of course it would be great if everyone had their phone locked, but the question is if it's the application's job to force users to do so. It may also quickly become complicated, e.g. if two applications have conflicting device access policies (e.g. consider one application requiring a password, and another one requiring finger print auth).