Sync MASVS with OWASP Mobile Security project

[sushi2k]

Check the requirements listed here and verify if covered or should be added to MASVS:

• - https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#Top_10_Mobile_Controls
• - https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#Secure_M-Development
• - https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10
  Actionlist:
• 1. MASVS: Add requirement to V4 for offline auth: Local offline authentication of a user towards the mobile app should leverage the APIs offered by the mobile operating system.. Covered in Adding 5 new requirements based on #189 disscussion. the changes are … #274
• 2. MSTG: We need to detail the explanation of 4.11 in the MSTG: explain what meta-information can help (location, etc.) and which events should be covered (eg.. Change password, etc.). E.g.: extend ### Testing Login Activity and Device Blocking (MSTG‑AUTH‑11) --> issue at extend ### Testing Login Activity and Device Blocking (MSTG‑AUTH‑11) owasp-mastg#1382
• 3. MSTG: Suggest to file an issue with eh MSTG where we extend explanation of enforcement on the remote endpoint(4.9). Not sure if a captcha is a good idea. See Explain in the guide that 4.9 + 2nd factor should mean: enforce at remote endpoint owasp-mastg#1383
• 4. MSTG: we have to show in the MSTG (i guess we do already!) that you CAN EASILY FIND A KEY IN A NATIVE BINRAY! HIDING IN A PLAIN NATIVE BINARY IS A DUMB IDEA! Covered in Ensure that hardcoded keys in native ios/android code are explained as a bad idea. owasp-mastg#1384
• 5. MSTG: An app should give a notiifcation when something is wrong with a certifcate (pin), or at least log at the remote endpoint something is wrong. This is already in the mstg - just need to confirm what we say over there. Covered in Make sure we cover pinning failbacks properly owasp-mastg#1385
• 6. MASVS: Consider a requirement that we do not store sensitve data offline, but only online (as L2 variant of MSTG‑STORAGE‑2). Covered in Adding 5 new requirements based on #189 disscussion. the changes are … #274.
• 7. MASVS: Discuss: should we say something about tracking info stored on a device? Discuss: should we say something about tracking info stored on a device? or about the duration sensitive information is stored on a device? #281
• 8. MASVS: Have an L2 requirement in V4 regarding contextual information for session management. Covered in Adding 5 new requirements based on #189 disscussion. the changes are … #274
• 9. MSTG: Update how we cover app-device identification: Covered in the mstg wrongly: MSTG‑STORAGE‑10: https://github.com/OWASP/owasp-mstg/blob/4d9938a3d767f56387fb2586886664aab89419e6/Document/0x04e-Testing-Authentication-and-Session-Management.md#testing-login-activity-and-device-blocking-mstgauth11, but we do cover instanceID and identifierforVendor in different pages. Let;s make sure we open up an issue where verification is set straight with modern standards & create a requirement for V6 as jotted down by Sven. MSTG update will be covered in iOS 12: make sure you only use identifierForVendor and instanceID owasp-mastg#1161
• 9b MASVS: let's extend V6 of the MASVS to cover device binding/authentication Adding 5 new requirements based on #189 disscussion. the changes are … #274.
• 10. MASVS: have a requirement that local storage should be wiped after 5 auth failures (l2). Covered in Adding 5 new requirements based on #189 disscussion. the changes are … #274.
• 11. MSTG: accessing paid content might be interesting in tners of session logging :) no extension at the MASVS required: just extend the MSTG with a hint on payed content. Note: google play chekcouts and appstore imbursements are logged partially, but i was able to circumvent them on some apps, allowing me to unlock stuff. Maybe we should do something about the logging of the content access at least and say something about ensuring that purchases require verification before unlocking them? See extend ### Testing Login Activity and Device Blocking (MSTG‑AUTH‑11) owasp-mastg#1382
• 12. MASVS: maybe we should think about in-app purchases and SMS services via apps a little longer: e.g. have 4.11 on payed materials? Maybe file an issue with teh masvs to make the discussion public? Discussions: Have requirements on in-app purchases #282
• 13. ASVS (not MASVS): check if the aSVS has something on bugbounty/responsible disclosure? If not, raise in an issue. Responsible disclosure / Security.txt ASVS#664
• 13b. MASVS: make sure that the mobile app can use the bugbounty/responsible disclosure process. Responsible disclosure requirement #283
• 14. MASVS: L2 requirement: have an application-versioning acceptlist/blocklist? However, in the MSTG we have to show how you can enrich a user-agent with a signature/token to make it hard to intercept / alter the user agent data. Basically: if an API does not block it, the user does not upgrade, we can get into trouble. Covered in Adding 5 new requirements based on #189 disscussion. the changes are … #274

Actionlist based on top 10 mobile controls:

• 15. MSTG: Extend extend ### Testing Login Activity and Device Blocking (MSTG‑AUTH‑11) owasp-mastg#1382 with making sure that certain operations are signed, such as payed content access, given consent to T&Cs,
• 16. MASVS: Add requirements regarding having a privacy policy and a clearly recorded consent (and its withdrawal). Have a requirement on abiding the privacy laws of the country where the app is published #297
• 17. MASVS: have a requirement on not leaking PII through metadata: whether statistics, images, etc. have a requirement on not leaking PII through metadata: whether statistics, images, etc. #298
• 18. MASVS/MSTG: make sure we require to educate the user on best practices, including on how to get the app. (start with an issue on the MSTG) Android Oreo change: Install from unknown sources owasp-mastg#954
• 19. MASVS: we might want to add a hint that paid content could use L2 and possible R protection Explain that paid content in apps could require L2 and possible R protection #299

Actionlist based on Mobile top 10 2016:

• 20. MASVS: Reiterate over authorization requirements Improve MASVS: Reiterate over authorization requirements #300
• 21. MASVS: Make sure we cover hidden switches/backdoors/easter-eggs, dev-management code well Make sure we cover hidden switches/backdoors/easter-eggs, dev-management code well #301
• 22. MSTG: Make sure we cover hidden switches/backdoors/easter-eggs, dev-management code well

[A-AFTAHI]

I'm working on this

[commjoen]

Great! What is your current status /planning on this subject @A-AFTAHI ? We want to reshape the current owasp wiki and this issue will have to be fixed in order to make everything a bit more consequent ^^.

[commjoen]

Mobile-Sec-Project_Syn_MASVS.xlsx
First analysis as done by @A-AFTAHI . Will be discussed upcoming tuesday in a call.

[sushi2k]

Great work @A-AFTAHI. Let me have a look at it. I might be able to join the call also.

[sushi2k]

Mobile-Sec-Project_Syn_MASVS-Sven.xlsx

Please find my feedback here. @commjoen let me know when you have the call. Cheers

[commjoen]

Tuesday 19:00 dutch time :-)

[commjoen]

Mobile-Sec-Project_Syn_MASVS-Sven_remarks_aftahi_jeroen.xlsx
Updated feedback with @A-AFTAHI , will compile actionlist.

[A-AFTAHI]

Thanks @commjoen for the Update!

[commjoen]

Moved all actions to the top of the issue to track progress

[commjoen]

@A-AFTAHI : does the current Excel cover both https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#Top_10_Mobile_Controls and
https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#Secure_M-Development ?

[A-AFTAHI]

The First version of the excel was only based on https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#Secure_M-Development , and since the current version is based on the first one so we have to make sure that everything in https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#Top_10_Mobile_Controls is already covered.
let me check that

[commjoen]

Okidoki. Let me know when you have somethign to review which includes that, so we can extend and start executing the actions listed at #189 (comment)

[commjoen]

All MSTG actions based on #189 (comment) have been created. the MASVS issues can be fixed in 1 PR.

[A-AFTAHI]

Mobile-Sec-Project_&Mobile_Top10_Syn_MASVS-Sven_remarks_aftahi_jeroen.xlsx
He is the excel file updated with my Mobile Top 10 Analysis. please take a look at it and review my interpretations.

[commjoen]

Mobile-Sec-Project_.Mobile_Top10_Syn_MASVS-Sven_remarks_aftahi_jeroen_version 1.xlsx
Please find my comments. which top 10 is this? 2013? because 2016 has different items i believe (https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10)

[A-AFTAHI]

You're right! in 2016 there are different items. well my analysis was based on the TOP 10 in the link initially suggested by @sushi2k https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#Top_10_Mobile_Controls

[commjoen]

Can you do both please? Just add a few rows and we are fine :-)

[A-AFTAHI]

Mobile-Sec-Project_.Mobile_Top10_Syn_MASVS-Sven_remarks_aftahi_jeroen_version.2.xlsx
Here is an updated version of the excel with mobile Top 10 2016 analysis covered!

[commjoen]

Thank you very much! Will review tomorrow :)

[commjoen]

All reviewed
Mobile-Sec-Project_.Mobile_Top10_Syn_MASVS-Sven_remarks_aftahi_jeroen_version.3.xlsx

[commjoen]

Executed all actions till step 16. Let's make sure we make issues out of each of the steps to take and then close this issue.

[commjoen]

So OWASP/ASVS#664 came back "won't fix". @sushi2k , @TheDauntless , @cpholguera , @A-AFTAHI : what do we do with this? Because having an RD makes sense to me. For now I have set up https://owasp.slack.com/archives/C04T40NND/p1565798928215600 as a discussion within OWASP.

[sushi2k]

Why not put a L1 requirement into V1:

A responsible disclosure policy exists that defines a communication channel to communicate identified vulnerabilities.

In the MSTG we could make a short test case, similar to https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05d-Testing-Data-Storage.md#testing-the-device-access-security-policy-mstg-storage-11.

We could then reference and describe, e.g. https://securitytxt.org/. The security.txt is not a standard yet, but something that is very easy to implement and get's quite some acceptance (at least in the bug bounty community).

I know you don't wan't to have it in the MASVS, but it's part of a application security strategy/program (like threat modeling, which we also have as a requirement).

[sushi2k]

Otherwise we could describe responsible disclosure in the MSTG and just leverage on this requirement in the MASVS:

| 1.10 | MSTG‑ARCH‑10 | Security is addressed within all parts of the software development lifecycle. | | ✓ |

Responsible Disclosure is then one way for a feedback loop for the SDLC? I know it's a bit far fetched, but then we at least don't need to touch the MASVS.

[commjoen]

You're right... If no one moves, we should be frontrunner. We could include http://disclose.io/ in the MSTG

[commjoen]

As @TheDauntless would say: let's put it in a separate issue 👍

[commjoen]

It is in #283

[commjoen]

All issues have been created or set. We are ready to close this. Thanks @A-AFTAHI for the long haul analysis!