search

OWASP / owasp-masvs

The OWASP MASVS (Mobile Application Security Verification Standard) is the industry standard for mobile app security.
https://mas.owasp.org/
Creative Commons Attribution Share Alike 4.0 International
2.01k stars 431 forks source link

V1 feedback #74

Closed cybercybercyber closed 7 years ago

cybercybercyber commented 7 years ago

Continuing from last week:

Re 1.2: Nit: maybe "checked" instead of "tested"? I.e. I suppose it's enough to check CVE db for known vulnerabilities?

Re 1.7: Not sure if I understand this. Is this referring to dynamically loaded 3rd party libraries from resources not under the control of the app owner? (e.g. loading js libraries from the internet, rather than distributing them with the mobile application). If so, why is it limited to security controls?

Re 1.9: Does this include the SDK? I.e. would an application need to duplicate the SDK documentation wrt the security expectations for calling each feature it uses from the SDK?

Re 1.10: Maybe point to other standards like ISO 27k that have more details on such a policy?

Re 1.11: it doesn't sound to me like that's the mobile application owner's responsibility. This is like saying web sites need to have a process in place to monitor the web for phishing pages.

Re 1.12: Is this referring to the backend? I.e. the backend must support not serving certain versions of the application? If so, that wasn't immediately clear to me from how it's phrased.

Re 1.13: Again, I think this needs a more thorough explanation. The way I read it as worded right now, it sounds like e.g. the Facebook mobile app would need to require the user to have a different password for the mobile app than for the web. I think it doesn't refer to the password, but even then, some modern architectures are a bit incompatible with this requirement (e.g. one common architecture is to have a backend API, and both the mobile application and the web application are just front-ends that use the API; I don't see a reason why the API would need to support two different authentication methods to distinguish between mobile and web users).

Re 1.14: It might be worth expanding on what exactly you mean by static and dynamic security testing.

muellerberndt commented 7 years ago

Hey @cybercybercyber, thanks again for all the feedback. I'm creating a new branch to start working your suggestions in, do you want to help with editing? Also, are you on the MSTG Slack channel?

muellerberndt commented 7 years ago

FYI, branch is here: https://github.com/OWASP/owasp-masvs/tree/cyberx3

muellerberndt commented 7 years ago

Re 1.7: Not sure if I understand this. Is this referring to dynamically loaded 3rd party libraries from resources not under the control of the app owner? (e.g. loading js libraries from the internet, rather than distributing them with the mobile application). If so, why is it limited to security controls?

It is best practice for security controls to have a centralized implementation. I don't understand the reference to external libraries either - it is probably meant to refer to bundled third-pard libraries that perform security functions using external services, such as OAuth? Not sure why this needs to be specifically pointed out, so I'm removing that part.

Re 1.9: Does this include the SDK? I.e. would an application need to duplicate the SDK documentation wrt the security expectations for calling each feature it uses from the SDK?

The way I read this is that you should be aware of the security implications of the APIs used: Key storage, IPC facilities, and so on. Perhaps this can be phrased better?

Re 1.10: Maybe point to other standards like ISO 27k that have more details on such a policy?

I added a reference to NIST SP 800-57.

Re 1.11: it doesn't sound to me like that's the mobile application owner's responsibility. This is like saying web sites need to have a process in place to monitor the web for phishing pages.

Agreed. @jeroenwillemsen, @sushi2k, any issues if we remove this?

Re 1.12: Is this referring to the backend? I.e. the backend must support not serving certain versions of the application? If so, that wasn't immediately clear to me from how it's phrased.

Yes, I'm gonna try and rephrase this.

Re 1.13: Again, I think this needs a more thorough explanation. The way I read it as worded right now, it sounds like e.g. the Facebook mobile app would need to require the user to have a different password for the mobile app than for the web. I think it doesn't refer to the password, but even then, some modern architectures are a bit incompatible with this requirement (e.g. one common architecture is to have a backend API, and both the mobile application and the web application are just front-ends that use the API; I don't see a reason why the API would need to support two different authentication methods to distinguish between mobile and web users).

I'm not a fan of this requiriement either, as I can't see myself actually recommending this to anyone. @jeroenwillemsen, any issues if we remove this?

Re 1.14: It might be worth expanding on what exactly you mean by static and dynamic security testing.

Should we make this even more generic and refer simply to "security testing"? Doesn't make sense to me to require specific types of tests.

sushi2k commented 7 years ago

@b-mueller 1.11 can be deleted. Might be better placed in some CERT processes, but not in the MASVS. It's also difficult to describe this in detail in the MSTG, as I think mostly fake-apps might be reported by users/reviews and this will result in describing a non technical process in the MSTG.

1.14: We should make this more generic and the SDLC section in the MSTG could reference to this. The SDLC section should then describe this in detail on what can be done, regarding security in the SDLC.

muellerberndt commented 7 years ago

Hi guys, V1 is updated, please have a look.

commjoen commented 7 years ago

Sorry for not answering timely, I was away for a longer period of time.

sushi2k commented 7 years ago

maybe it is best to indeed have an SDLC section or a reference to other SDLC standards which can be applied here?

@commjoen There will be a chapter for security testing in the SDLC within the MSTG (https://github.com/OWASP/owasp-mstg/blob/master/Document/0x07a-Security-Testing-SDLC.md). I was referring to that. But you are saying to make a whole new section in the MASVS about SDLC with it's own requirements, right? Maybe that would also be a good idea, to ensure best practices are applied to the SDLC, like

What do you guys think?

muellerberndt commented 7 years ago

Pfew I'd rather not add another section at this point. Secure SDLC in general is not mobile app specific. I think referencing a standard would be better here. Do you guys know any? :)

commjoen commented 7 years ago

There are various, one easily accessible is https://www.microsoft.com/en-us/sdl/ for instance. MAybe we can enumerate a few?

sushi2k commented 7 years ago

@b-mueller The SDLC requirements are somehow out of scope for the MASVS, you are right. Let's see what kind of content we have in the SDLC section of the MSTG. Anyway there will be a lot of references in it I guess.

muellerberndt commented 7 years ago

OK I'll re-word 1.13 to more generically refer to require Secure SDLC. In the best case we'll have links to the MSTG for each requirement, so it'll be only a matter of following a link to get to them. The only problem for now is that we cannot provide these links yet because we don't have a release of the MSTG. It will be possible once we have tagged version 1.0 of the MSTG so MASVS 1.0 will be exactly in sync, and link to, MSTG 1.0. I will add some placeholders for now in the "references" section.

muellerberndt commented 7 years ago

All points have been addressed & no more comments incoming so I'm closing this.