Perform a gap analysis with ENISA's "SMASHING - Smartphone Secure development Guidelines"

[meetinthemiddle-be]

Just to see if they cover something that we missed:

https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/smartphone-guidelines-tool

Analysis result:
Actionlist:

• 1. Enhance consent (processing) for PII in the MSTG (Sync MASVS with OWASP Mobile Security project  #189)
• 2. MASVS: have a requirement on not leaking PII trhough metadata: whether statistics, images, etc. Sync MASVS with OWASP Mobile Security project  #189
• 3. MASVS: Add requirements regarding having a privacy policy and a clearly recorded consent (including recording of its withdrawal). Sync MASVS with OWASP Mobile Security project  #189
• 4. MASVS: Discuss: should we say something about tracking info stored on a device? Sync MASVS with OWASP Mobile Security project  #189
• 5. MASVS: Have a requirement on that the app provides clear explanation on why access to device data or sensors is needed. Have a requirement on that the app provides clear explanation on why access to device data or sensors is needed. #302
• 6. MASVS: Have a requirement regarding providing and withdrawing consent when sharing data with third parties (e.g. no sharing or anonimized sharing without consent, sharing with consent).Have a requirement on abiding the privacy laws of the country where the app is published #297
• 7. MSTG: make sure we explain risks regarding enroling new fingers with biometrics well enough (Android covered, ios: Fix for https://github.com/OWASP/owasp-masvs/issues/203 owasp-mastg#1451).
• .8 ASVS: check whether there are requirements regarding "the use of privacy enhancing technologies, that support data minimization, anonymization and security of personal data" Privacy requierments ASVS#673
• 9. MASVS: Design the user interface in a way that warns the user if the peer certificate does not match the expected certificate and provide the ability to abort any further interaction. Sync MASVS with OWASP Mobile Security project  #189
• 10. ASVS: Ensure adequate logs on the server are retained about established connections. In the case of multiple intermediate proxies, make sure that HTTP headers are parsed correctly (e.g., X-Forwarded-For). --> Logging covered in 1.7.2 of https://github.com/OWASP/ASVS/blob/c80914a97fa5cdc91cb0dc7db338416611d4096e/4.0/en/0x10-V1-Architecture.md and https://github.com/OWASP/ASVS/blob/1aed25ce0f90248b21865208160727f868267254/4.0/en/0x22-V14-Config.md
• 11. MSTG: make sure sensitive information does not end up at the lockscreen. iOS and Android: improve platform interaction on notifications owasp-mastg#1163
• 12. MASVS: reopen the discussion on having custom keyboards for small amounts of input (e.g. pincodes as passwords) Rethink custom keyboards for small amounts of input (e.g. pincodes as passwords) #303
• 13. MASVS: make sure a webview and its storage (Session, local storage,db's) are cleared out after use in case of sensitive information and/or enablement of JS. Make sure a webview and its storage (Session, local storage,db's) are cleared out after use in case of sensitive information and/or enablement of JS. #304
• 14. MASVS-first/MSTG: Consider the posiblity to extend the blocking of an app with deleting the data from the app remotely via a web interface. (MASVS first: Consider the posiblity to extend the blocking of an app with deleting the data from the app remotely via a web interface. #305).
• 15. MASVS: Would be nice to have something like: The App uses only as much data attributes as sufficient for business and no longer than neccessary. Discuss: should we say something about tracking info stored on a device? or about the duration sensitive information is stored on a device? #281
• 16. ASVS: Authentication should not be used as a replacement of authorization security controls. Authorization verifies the permissions of a user and presupposes strong authentication. Covered in https://github.com/OWASP/ASVS/blob/8796248ec63c96f3f0cae1f0a274dc1e5d4e4410/4.0/en/0x12-V4-Access-Control.md.
• 17.ASVS/MASVS: Consider using asymmetric cryptography for authentication and authorization purposes. Generate and use the private key directly within a platform supported secure hardware (e.g., Trusted Execution Environment (TEE), Secure Element (SE)). Consider using asymmetric cryptography for device authentication purposes. Generate and use the private key directly within a platform supported secure hardware (e.g., Trusted Execution Environment (TEE), Secure Element (SE)). #306 and Integration with ASVS on possible mobile client device binding ASVS#674
• 18.ASVS: Use unpredictable session identifiers with high entropy. Requirement on session identifiers ASVS#675
• 19. MSTG: For platforms that support application component history stack (e.g., Android), always clear the stack on session or app termination and user’s request to logout. / if you have multiple activities and other components active: make sure that all of these are cleared out (so terminate all). that's bout clearing memory mostly i'dd say. but it can get some love in the MSTG. fix for last open items at https://github.com/OWASP/owasp-masvs/issues/203 owasp-mastg#1479
• 20. MSTG: Clear any maintained sensitive data on session termination. Reset the application state and request for user re-authentication. fix for last open items at https://github.com/OWASP/owasp-masvs/issues/203 owasp-mastg#1479
• 21. MSTG: Applications have to take into account that different operating system versions provide different levels of access control (e.g., Android permissions) for various system resources. Specifically paid resources have different levels of access control depending on the version of the OS. Applications have to implement access control for those resources to prevent abuse of the application’s access to those resources due to missing access control in older/newer versions of the OS and and/or application framework.Sync MASVS with OWASP Mobile Security project  #189
• 22. MASVS/ASVS ? Discuss: There should be a requirement about validation of payment receipts on the backend server and not on the device . Discuss: There should be a requirement about validation of payment receipts on the backend server and not on the device #307
• 23. Warn user and obtain consent about cost implications for app behaviour - extended via Discussions: Have requirements on in-app purchases #282
• 24. Maintain logs of access to paid-for resources in non-repudiable format - extended via Sync MASVS with OWASP Mobile Security project  #189
• 25. MSTG: check for: Avoid populating webviews loaded from the file URI scheme with user supplied DOM input. fix for last open items at https://github.com/OWASP/owasp-masvs/issues/203 owasp-mastg#1479
• 26. MSTG: Always follow the domain name registration infrastructure to declare a custom permission, in order to avoid any collisions with other apps. fix for last open items at https://github.com/OWASP/owasp-masvs/issues/203 owasp-mastg#1479
• 27. MSTG: mention that Software components that are unmaintained must not be used. fix for last open items at https://github.com/OWASP/owasp-masvs/issues/203 owasp-mastg#1479
• 28. MSTG: Do not deploy public apps with ad-hoc signing certificates used for development and testing.fix for last open items at https://github.com/OWASP/owasp-masvs/issues/203 owasp-mastg#1479

[commjoen]

Please ensure we check only the latest report :-)

[codethatrocks]

I'd like to work on this issue. I checked the first two ENISA categories and documented my thoughts in this google sheet. I'd like to discuss them first to see if it leads in the right direction. Mapping MASVS and ENISA Smartphone guidelines

[commjoen]

Hi @codethatrocks , thank you for your mapping! I would like to take a similar approach here as we did with #189, which means:

• Let's have review sessions with @sushi2k and me
• Let's jot down action points in this ticket based on both reviews :)

It would be good to check #189 as it might well be that all 4 sources give overlapping results :-)

[commjoen]

Great first part of the analysis! I have added my comments to the first set. Thank you for your hard work! I will analyze the rest later this/next week. When @sushi2k has done his analysis as well, we can start creating actionable items in this issue & link them to #189 if they are covered there as well.

[commjoen]

Well done @codethatrocks ! I have added them all to the top so we can start linking issues :).

[commjoen]

@sushi2k , should we really create an issue in the MSTG for 19? because i am not sure how important that is..

[commjoen]

Removed pre-listing comments for better overview...

[commjoen]

With the final PR this is no longer relevant for the MASVS. Closing donw. Thank you all!