muellerberndt
commented
7 years ago Hi Cybercybercyber,
Thanks for the extensive feedback. You're probably the first person ever to read the whole thing :)
Line 17: "Virus scanners don't make sense on modern mobile OSes, and attackers rarely exploit buffer overflows and XSS vulnerabilities in mobile apps (rare exceptions exist)."
I think many people will argue that even on classic desktop OSes virus scanners don't make much sense and in fact just increase the attack surface. I guess the main reasons they're maybe (even) less needed for mobile OSes is the default software distribution model (...)
The main thought behind this was that typical signature-based virus scanners don't work in today's mobile architectures, because the scanner (if distributed as a regular app) would be restricted to its own sandbox. When talking about malware in the following paragraph, I'm refering to auto-root malware. In that context, does it makes sense to say that "classical" virus scanners are not viable, even though malware is a threat? I agree that the point doesn't really come across the way it is written, I'm gonna rephrase it.
Also, I'd argue that buffer overflows and XSS are still a significant problem. For frameworks that use primarily javascript (Cordova) XSS essentially equals RCE, and Stagefright was an integer overflow.
Agreed that these issues are still are a problem (and they are covered in the mobile standard and testing guide), however I would still argue that both types of vulnerabilities have little relevance in the majority of run-of-the-mill mobile app development, except in some special scenarios. In the back of my mind, I was thinking of consultants mindlessy reporting "missing X-XSS-Protection headers" in HTTPS endpoints that are never accessed with a web browser (just an example).
IMO an application is (only) secure if despite being easily reversed
I guess the big question is, does software protection add to data protection? Ultimately, it boils down to semantics, such as the meaning of the word "secure". I agree that software protections are not security controls. With that in mind, the last major change we made to the MASVS was moving them into a separate, optional set of controls (MASVS-R). This was meant to address exactly the point you brought up. I also tried to make it clear that software protections must never be used as a replacement for security controls.
Re "Finding the right requirements [is] unique to mobile security". I don't think that's true. Standard client software is very similar in that regard.
True. Would it make sense to say that it is more relevant in mobile security though (because it is easier for adversaries to gain physical access to a device)?
Line 29: "Our goal is therefore to provide software protection requirements in the higher verification levels"
See above, this refers to the old model, and has (hopefully) been addressed with the recent change. Again, thanks for all the feedback, I'll have another go at the introduction later to try and address the points you brought up.
Not sure if this is the best way to give feedback, but I figured I'd start an issue with a couple of things I noticed reading the introduction. In many cases I don't have any concrete suggestions on how to improve them, but I still wanted to point out a few things.
Line 17: "Virus scanners don't make sense on modern mobile OSes, and attackers rarely exploit buffer overflows and XSS vulnerabilities in mobile apps (rare exceptions exist)." I think many people will argue that even on classic desktop OSes virus scanners don't make much sense and in fact just increase the attack surface. I guess the main reasons they're maybe (even) less needed for mobile OSes is the default software distribution model: a centralized app store that takes care of malware scanning. As soon as users weaken the default distribution model by sideloading applications, you have the same malware problem as with regular computers. I guess that counts as a difference between mobile OS and desktop OS, but it doesn't immediately become clear from the way it's phrased. Also, I'd argue that buffer overflows and XSS are still a significant problem. For frameworks that use primarily javascript (Cordova) XSS essentially equals RCE, and Stagefright was an integer overflow.
Line 18: "Compromise a person's smartphone and you get unfiltered access to that person's life. When we consider that mobile devices are more readily lost or stolen and mobile malware is on the rise, the need for data protection becomes even more apparent." re mobile malware: the line above argues that virus scanners are not necessary. Calling out mobile malware here kind of invalidates the above point. re unfiltered access: the same is true for desktop computers. I think the lost/stolen risk should be highlighted primarily.
Line 27: Personally I'm not a big fan of this paragraph for several reasons. One, I would argue whether obfuscation and root detection are widely assumed to be necessary (to me these are client-side security controls that are at best speed bumps and at worst make security testing of an application harder and thus help hide real security flaws). Re "However, this binary way of looking at things doesn't make sense because software protection is not a binary proposition": Previously the standard says "A security standard for mobile apps must therefore focus on how mobile apps handle, store and protect sensitive information.". In other words, the standard is about data protection, not software protection. I can absolutely get behind the former, but I have a hard time supporting the later. Re "The question is not whether an app can be reverse engineered or not, but rather how much has been done to make the process more difficult.". I don't think that's the question. IMO an application is (only) secure if despite being easily reversed, it's still not possible for an attacker to gain unauthorized access to sensitive user data. Re "Finding the right requirements [is] unique to mobile security". I don't think that's true. Standard client software is very similar in that regard.
Line 29: "Our goal is therefore to provide software protection requirements in the higher verification levels". I think it would be better to make this optional, rather than requirements. To me, these are not even defense-in-depth, but rather speed bumps that can be used to hold off an attacker for a little while, but when the operating system is broken, it's basically game over (and this is regardless of whether we're on a classic OS or a mobile OS).
Line 34: maybe "offer an industry standard that can be tested against in mobile app security reviews" or similar?
Anyway, I know this is a lot, but I don't mean to invalidate any of the great work you guys have done so far. Feel free to ignore all of the above, but maybe some of the feedback is useful :). I'll try to go through the other chapters as well.