diff --git a/CHANGELOG.md b/CHANGELOG.md index ce80290414..8f6ebc731a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,217 +1,5 @@ # Changelog -## V1.2.1 and newer +All our Changelogs are available online at the OWASP MASTG GitHub repository, see the Releases page: -All our Changelogs are available online at the OWASP MSTG GitHub repository, see the [Releases page](https://github.com/OWASP/owasp-mastg/releases). - -## v1.2 - 25th July 2021 - -167 issues were closed since the last release. A full overview can be seen in Github Issues . - -326 pull requests were merged since the last release. A full overview can be seen in Github Pull Requests - -Major changes include: - -- Migrating the new document build pipeline from MASVS to MSTG. This allows us to build consistently the whole OWASP MSTG documents (PDF, docx etc.) in minutes, without any manual work. -- Besides numerous changes for the test cases we have a new Crackme - Android Level 4 and also new write-ups for the Crackmes. -- We removed all references to Needle and IDB tool, as both tools are outdated. -- References of OWASP Mobile Top 10 and MSTG-IDs are completely moved to MASVS -- Reworking of information gathering (static analysis) for Android Apps -- Update of Biometric Authentication for Android Apps -- New content and updates in the Android and iOS Reverse Engineering and Tampering chapters -- 3 new iOS Reverse Engineering test cases -- Translations of the MSTG are linked to the respective forks but are not part of the MSTG anymore -- Updated English, Japanese, French, Korean and Spanish checklists to be compatible with MSTG 1.2 -- Updated Acknowledgments, with 1 new co-author and contributor -- Added JNI Tracing for Android -- Added dsdump for dumping Objective-C and Swift content -- Added the procedure to sign the debugserver for iOS 12 and higher -- Added dependency-check to verify for vulnerabilities in libraries added by iOS package managers -- Added getppid as debugger detection (iOS) -- Added Domain/URL Enumeration in APKs -- Added introduction into Network.framework (iOS) -- Added UnSAFE Bank iOS Application -- Added information on SECCOMP (Android) -- Added native and java method tracing (Android) -- Added Android library injection -- Added Android 10 TLS and cryptography updates -- Updated code obfuscation for Android and iOS -- Added test case for Reverse Engineering Tools Detection - MSTG-RESILIENCE-4 (iOS) -- Added test case for Emulator Detection - MSTG-RESILIENCE-5 (iOS) -- Added an example with truststore to bypass cert pinning (Android) -- Added content to information gathering using frida (Android) -- Added Sec Consult, RandoriSec and OWASP Bay area as donators -- Added basic information gathering for Android and iOS -- Added Simulating a Man-in-the-Middle Attack with an Access Point -- Added gender neutrality to the MSTG -- Extended section about dealing with Xamarin Apps -- Updated all picture links (img tags) to be in markdown syntax -- Updated iTunes limitations and usage since macOS Catalina -- Added Emulation-based Analysis (iOS and Android) -- Added Debugging iOS release applications using lldb -- Added Korean translation of the checklist -- Updated symbolic execution content (Android) -- Added Ghidra for Android Reverse Engineering -- Added section on Manual (Reversed) Code Review for iOS -- Added explanation of more Frida APIs (iOS and Android) -- Added Apple CryptoKit -- Updated and simplified Frida detection methods -- Added introduction to setup and disassembling for iOS Apps -- Updated section about frida-ios-dump -- Added gplaycli (Android) -- Extended section on how to retrieve UDI (iOS) -- Added new companies in the Users.md list with companies applying the MSTG/MASVS -- Updated partially code samples to Swift 5 -- Adding Process Exploration (Android and iOS) -- Updated best practices for passwords, added "Have I Been Pwned" -- Updated SSL Pinning fallback methods -- Updated app identifier (Android and iOS) -- Updated permission changes for Android O, P and Q -- Updated Broadcast Receiver section (Android) - -Several other minor updates include fixing typos and markdown lint errors and updating outdated links. - -We thank you all contributors for the hard work and continuously improving the document and the OWASP MSTG project! - -## v1.1.3 - 2 August 2019 - -- Updated Acknowledgments, with 2 new co-authors. -- Translated various parts into Japanese. -- A large restructuring of the general testing, platform specific testing and reverse-engineering chapters. -- Updated description of many tools: Adb, Angr, APK axtractor, Apkx, Burp Suite, Drozer, ClassDump(Z/etc), Clutch, Drozer, Frida, Hopper, Ghidra, IDB, Ipa Installer, iFunBox, iOS-deploy, KeychainDumper, Mobile-Security-Framework, Nathan, Needle, Objection, Magisk, PassionFruit, Radare 2, Tableplus, SOcket CAT, Xposed, and others. -- Updated most of the iOS hacking/verification techniques using iOS 12 or 11 as a base instead of iOS 9/10. -- Removed tools which were no longer updated, such as introspy-Android and AndBug. -- Added missing MASVS references from version 1.1.4: v1.X, V3.5, V5.6, V6.2-V6.5, V8.2-V8.6. -- Rewrote device-binding explanation and testcases for Android. -- Added parts on testing unmanaged code in Objective-C, Java, and C/C++. -- Applied many spelling, punctuation and style-related fixes. -- Updated many cryptography related parts. -- Added testaces for upgrade-mechanism verification for apps. -- Updated Readme, Code of Conduct, Contribution guidelines, verification, funding link, and generation scripts. -- Added ISBN as the book is now available at Lulu. -- Added various fixes for the .epub format. -- Added testcases on Android and iOS backup verification. -- Improved key-attestation related explanation for Android. -- Restructured OWASP Mobile Wiki. -- Removed Yahoo Weather app and simplified reference on using SQL injection. -- Improve explanation for iOS app sideloading to include various available methods. -- Added explanation on using ADB and device shell for Android. -- Added explanation on using device shell for iOS. -- Provided comparison for using emulators/simulators and real devices for iOS/Android. -- Fixed Uncrackable Level 3 for Android. -- Improved explanation on how to exfiltrate data and apps on iOS 12 and Android 8. -- Improved/updated explanation on SSL-pinning. -- Added list of adopters of the MASVS/MSTG. -- Updated English, Japanese, French and Spanish checklists to be compatible with MSTG 1.1.2. -- Added a small write-up on Adiantum for Google. -- Added MSTG-ID to the paragraphs to create a link between MSTG paragraphs and MASVS requirements. -- Added review criteria for Android instant apps and guidance for app-bundle evaluation. -- Clarified the differences between various methods of dynamic analysis. - -## v1.1.2 - 12 May 2019 - -- Added missing mappings for MASVS V1.X. -- Updated markdown throughout the English MSTG to be consistent. -- Replaces some dead links. -- Improvements for rendering as a book, including the ISBN number. -- Updated the Excel: it is now available in Japanese as well! -- Many punctuation corrections, spelling and grammar issues resolved. -- Added missing iOS test case regarding memory corruption issues. -- Added contributing, code of conduct, markdown linting and dead link detection. - -## v1.1.1 - 7 May 2019 - -- Improvements on various tool related parts, such as how to use on-device console, adb, nscurl, Frida and Needle. -- Updated 0x4e regarding SMS communication. -- Many grammar/style updates. -- Added Android description regarding MASVS requirement 7.8. -- Updated contributor list. -- Various updates on instructions regarding TLS and encryption. -- Removed some erroneous information. -- Fixed parts of the alignment of the MASVS requirements with the MSTG. -- Updated information on various topics such as jailbreaking and network interception on both iOS and Android. -- Added some steps for Frida detection. -- Added write-ups on Android changes, regarding permissions, application signing, device identifiers, key attestation and more. -- Extended guidance on SafetyNet attestation. -- Added information on Magisk. -- Added Firebase misconfiguration information. -- Added references to more testing tools. -- Updated contributor list. -- Added a lot of information to iOS platform testing. -- Added a lot of fixes for our book-release. - -## v1.1.0 - 30 Nov 2018 - -- Added more samples in Kotlin. -- Simplified leanpub and gitbook publishing. -- A lot of QA improvements. -- Added deserialization test cases for iOS, including input sanitization. -- Added test cases regarding device-access-security policies and data storage on iOS. -- Added test cases regarding session invalidation. -- Improved cryptography and key management test cases on both Android and iOS. -- Started adding various updates in the test cases introduced by Android Oreo and Android Pie. -- Refreshed the Testing Tools section: removed some of the lesser maintained tools, added new tools. -- Fixed some of the markdown issues. -- Updated license to CC 4.0. -- Started Japanese translation. -- Updated references to OWASP Mobile Top 10. -- Updated Android Crackmes. -- Fixed some of the anti-reverse-engineering test cases. -- Added debugging test case for iOS. - -## v1.0.2 - 13 Oct 2018 - -- Updated guiding documentation (README). -- Improved automated build of the pdf, epub and mobi. -- Updated Frontispiece (given new contributor stats). -- Added attack surface sections for Android and various. -- Added vulnerable apps for testing skills. -- Improved sections for testing App permissions for Android (given android Oreo/Pie), added section for testing permissions on iOS. -- Added fix for Fragment Injection on older Android versions. -- Improved sections on iOS WebView related testing. - -## v1.0.1 - 17 Sept 2018 - -- Updated guiding documentation (README, PR templates, improved style guide, issue templates). -- Added automated build of the pdf and DocX. -- Updated Frontispiece (given new contributor stats). -- Updated Crackmes and guiding documentation. -- Updated tooling commands (adb, ABE, iMazing, Needle, IPAinstaller, etc.). -- Added first Russian translations of the 1.0 documents for iOS. -- Improved URLs for GitBook using goo.gl in case of URLs with odd syntax. -- Updated Frontispiece to give credit to all that have helped out for this version. -- Clarified the app taxonomy & security testing sections by a rewrite. -- Added sections for network testing, certificate verification & SSL pinning for Cordova, WebView, Xamarin, React-Native and updated the public key pinning sections. -- Removed no longer working guides (e.g. using iTunes to install apps). -- Updated a lot of URLs (using TLS wherever possible). -- Updated tests regarding WebViews. -- Added new testing tool suites in the tools section, such as the mobile hack tools and various dependency checkers. -- Updated test cases regarding protocol handlers (added missing MASVS 6.6 for iOS). -- Many small updates in terms of wording, spelling/typos, updated code segments and grammar. -- Added missing test cases for MASVS 2.11, 4.7, 7.5 and 4.11. -- Updated the XLS Checklist given MASVS 1.1.0. -- Removed the clipboard test from iOS and Android. -- Removed duplicates on local storage testing and updated data storage test cases. -- Added write-ups from the mobile security sessions at the OWASP summit. -- Added anti-debugging bypass section for iOS. -- Added SQL injection & XML injection samples and improved mitigation documentation. -- Added Needle documentation for iOS. -- Added fragment injection documentation. -- Updated IPA installation process guidance. -- Added XSS sample for Android. -- Added improved documentation for certificate installation on Android devices. -- Updated Frida & Fridump related documentation. -- Added sections about in-memory data analysis in iOS. -- Updated software development and related supporting documentation. -- Updated (anti) reverse-engineering sections for Android and iOS. -- Updated data storage chapters given newer tooling. -- Merged SDLC and security testing chapters. -- Updated cryptography and key-management testing sections for both Android and iOS (up to Android Nougat/iOS 11). -- Updated general overview chapters for Android and iOS. -- Updated Android and iOS IPC testing. -- Added missing overviews, references, etc. to various sections such as 0x6i. -- Updated local authentication chapters and the authentication & session management chapters. -- Updated test cases for sensitive data in memory. -- Added code quality sections. - -## v1.0 - 15 Jun 2018 (First release) + diff --git a/CITATION.cff b/CITATION.cff index d3161e9c5f..000d9e569b 100644 --- a/CITATION.cff +++ b/CITATION.cff @@ -1,6 +1,6 @@ # YAML 1.2 --- -abstract: "The MASTG is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the controls listed in the OWASP Mobile Application Verification Standard (MASVS)." +abstract: "The OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the controls listed in the OWASP Mobile Application Verification Standard (MASVS)." authors: - family-names: Holguera @@ -15,7 +15,7 @@ authors: family-names: Willemsen given-names: Jeroen cff-version: "1.1.0" -date-released: 2021-07-25 +date-released: 2022-09-05 identifiers: - type: isbn @@ -29,5 +29,5 @@ license: "CC-BY-SA-4.0" message: "If you use the MASTG, please cite it using these metadata." repository-code: "https://github.com/OWASP/owasp-mastg/" title: "OWASP Mobile Application Security Testing Guide" -version: "1.2" +version: "1.5.0" ... \ No newline at end of file diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index ff11608280..bbcb8dc339 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -20,7 +20,7 @@ Examples of unacceptable behavior by participants include: - Trolling, insulting/derogatory comments, and personal or political attacks - Public or private harassment - Publishing others' private information, such as a physical or electronic address, without explicit permission -- Misusing the context of the Mobile Security Testing Guide project for commercial goals (e.g. adding sales pitches to the guide or to communication channels used by the project, such as Slack). +- Misusing the context of the Mobile Application Security project for commercial goals (e.g. adding sales pitches to the guide or to communication channels used by the project, such as Slack). - Other conduct which could reasonably be considered inappropriate in a professional setting ## Our Responsibilities diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 86ea53b8cb..d6a8ca1cb0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,3 +1,3 @@ # Contributing -Learn how you can contribute to the OWASP Mobile Security Project [here](docs/contributing/1_How_Can_You_Contribute.md). +Learn how you can contribute to the OWASP Application Mobile Security Project [here](docs/contributing/1_How_Can_You_Contribute.md). diff --git a/Crackmes/README.md b/Crackmes/README.md index 3a7984310f..4f1a502054 100644 --- a/Crackmes/README.md +++ b/Crackmes/README.md @@ -2,7 +2,7 @@ -Welcome to the UnCrackable Apps for Android and iOS, a collection of mobile reverse engineering challenges. These challenges are used as examples throughout the Mobile Security Testing Guide. Of course, you can also solve them for fun. +Welcome to the UnCrackable Apps for Android and iOS, a collection of mobile reverse engineering challenges. These challenges are used as examples throughout the OWASP MASTG. Of course, you can also solve them for fun. ## Android diff --git a/Document/0x01-Foreword.md b/Document/0x01-Foreword.md index aae10d3d43..9e325e4bb8 100644 --- a/Document/0x01-Foreword.md +++ b/Document/0x01-Foreword.md @@ -1,6 +1,6 @@ # Foreword -Welcome to the OWASP Mobile Security Testing Guide. Feel free to explore the existing content, but do note that it may change at any time. New APIs and best practices are introduced in iOS and Android with every major (and minor) release and also vulnerabilities are found every day. +Welcome to the OWASP Mobile Application Security Testing Guide. Feel free to explore the existing content, but do note that it may change at any time. New APIs and best practices are introduced in iOS and Android with every major (and minor) release and also vulnerabilities are found every day. If you have feedback or suggestions, or want to contribute, create an issue on GitHub or ping us on Slack. See the README for instructions: @@ -14,6 +14,6 @@ Or maybe that's going too far. But at least, they produced a proof-of-concept fo Because this isn't a normal security book, the introduction doesn't list impressive facts and data proving importance of mobile devices in this day and age. It also doesn't explain how mobile application security is broken, and why a book like this was sorely needed, and the authors don't thank their beloved ones without whom the book wouldn't have been possible. -We do have a message to our readers however! The first rule of the OWASP Mobile Security Testing Guide is: Don't just follow the OWASP Mobile Security Testing Guide. True excellence at mobile application security requires a deep understanding of mobile operating systems, coding, network security, cryptography, and a whole lot of other things, many of which we can only touch on briefly in this book. Don't stop at security testing. Write your own apps, compile your own kernels, dissect mobile malware, learn how things tick. And as you keep learning new things, consider contributing to the MASTG yourself! Or, as they say: "Do a pull request". +We do have a message to our readers however! The first rule of the OWASP Mobile Application Security Testing Guide is: Don't just follow the OWASP Mobile Application Security Testing Guide. True excellence at mobile application security requires a deep understanding of mobile operating systems, coding, network security, cryptography, and a whole lot of other things, many of which we can only touch on briefly in this book. Don't stop at security testing. Write your own apps, compile your own kernels, dissect mobile malware, learn how things tick. And as you keep learning new things, consider contributing to the MASTG yourself! Or, as they say: "Do a pull request". diff --git a/Document/0x02a-Frontispiece.md b/Document/0x02a-Frontispiece.md index 8dcd452e8d..18b2b2ee7b 100644 --- a/Document/0x02a-Frontispiece.md +++ b/Document/0x02a-Frontispiece.md @@ -1,16 +1,10 @@ # Frontispiece - + -## About the OWASP Mobile Application Security Testing Guide +## About the OWASP MASTG -The OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for testing the security of mobile apps. It describes processes and techniques for verifying the requirements listed in the [Mobile Application Security Verification Standard (MASVS)](https://github.com/OWASP/owasp-masvs), and provides a baseline for complete and consistent security tests. - -OWASP thanks the many authors, reviewers, and editors for their hard work in developing this guide. If you have any comments or suggestions on the Mobile Security Testing Guide, please join the discussion around MASVS and MASTG in the [OWASP Mobile Security Project Slack Channel](https://owasp.slack.com/messages/project-mobile_omtg/details/ "OWASP Mobile Security Project Slack Channel"). You can sign up for the Slack channel yourself using [this URL](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw# "Slack channel sign up"). - -> Please open an issue in our Github Repo if the invite has expired. - -## OWASP MASVS and MASTG Adoption +The [OWASP Mobile Application Security Testing Guide (MASTG)](https://mas.owasp.org/MASTG/0x01-Foreword), which is part of the [OWASP Mobile Application Security (MAS)](https://mas.owasp.org/) flagship project, is a comprehensive manual covering the processes, techniques, and tools used during mobile application security analysis, as well as an exhaustive set of test cases for verifying the requirements listed in the [OWASP Mobile Application Security Verification Standard (MASVS)](https://mas.owasp.org/MASVS/0x01-Foreword), providing a baseline for complete and consistent security tests. The OWASP MASVS and MASTG are trusted by the following platform providers and standardization, governmental and educational institutions. [Learn more](0x02b-MASVS-MASTG-Adoption.md). @@ -18,34 +12,6 @@ The OWASP MASVS and MASTG are trusted by the following platform providers and st -
- -## šŸ„‡ MAS Advocates - -MAS Advocates are industry adopters of the OWASP MASVS and MASTG who have invested a significant and consistent amount of resources to push the project forward by providing consistent high-impact contributions and continuously spreading the word. [Learn more](0x02c-Acknowledgements.md#our-mastg-advocates). - - - - - -
- -## Disclaimer - -Please consult the laws in your country before executing any tests against mobile apps by utilizing the MASTG materials. Refrain from violating the laws with anything described in the MASTG. - -Our [Code of Conduct](https://github.com/OWASP/owasp-mastg/blob/master/CODE_OF_CONDUCT.md) has further details. - -## Copyright and License - -Copyright Ā© The OWASP Foundation. This work is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/ "Creative Commons Attribution-ShareAlike 4.0 International License"). For any reuse or distribution, you must make clear to others the license terms of this work. - - - -## ISBN - -Our ISBN Number is 978-1-257-96636-3 and a hard copy of the MASTG can be ordered at [lulu.com](https://www.lulu.com/shop/jeroen-willemsen-and-sven-schleier-and-bernhard-mĆ¼ller-and-carlos-holguera/owasp-mobile-security-testing-guide/paperback/product-1kw4dp4k.html). - ## Authors ### Bernhard Mueller @@ -95,3 +61,27 @@ The Mobile Security Testing Guide was initiated by Milan Singh Thakur in 2015. T | Authors | Reviewers | Top Contributors | | --- | --- | --- | | Milan Singh Thakur, Abhinav Sejpal, Pragati Singh, Mohammad Hamed Dadpour, David Fern, Mirza Ali, Rahil Parikh | Andrew Muller, Jonathan Carter | Jim Manico, Paco Hope, Yair Amit, Amin Lalji, OWASP Mobile Team | + + + +## Changelog + +All our Changelogs are available online at the OWASP MASTG GitHub repository, see the Releases page: + + + +## Disclaimer + +Please consult the laws in your country before executing any tests against mobile apps by utilizing the MASTG materials. Refrain from violating the laws with anything described in the MASTG. + +Our [Code of Conduct](https://github.com/OWASP/owasp-mastg/blob/master/CODE_OF_CONDUCT.md) has further details. + +OWASP thanks the many authors, reviewers, and editors for their hard work in developing this guide. If you have any comments or suggestions, please connect with us at . + +If you find any inconsistencies or typos please open an issue in [the OWASP MASTG Github Repo]: . + +## Copyright and License + +Copyright Ā© The OWASP Foundation. This work is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/ "Creative Commons Attribution-ShareAlike 4.0 International License"). For any reuse or distribution, you must make clear to others the license terms of this work. + + diff --git a/Document/0x02b-MASVS-MASTG-Adoption.md b/Document/0x02b-MASVS-MASTG-Adoption.md index 2712f62d0c..c2d38c30d7 100644 --- a/Document/0x02b-MASVS-MASTG-Adoption.md +++ b/Document/0x02b-MASVS-MASTG-Adoption.md @@ -67,7 +67,7 @@ In 2021, ioXt has [extended its security principles through the Mobile Applicati | European Payments Council | [Payment Threats and Fraud Trends Report](https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2021-12/EPC193-21%20v1.0%202021%20Payments%20Threats%20and%20Fraud%20Trends%20Report.pdf) | 2021 | | European Payments Council | [Mobile Initiated SEPA Credit Transfer Interoperability Implementation Guidelines, including SCT Instant (MSCT IIGs)](https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/mobile-initiated-sepa-instant-credit-transfer-interoperability) | 2019 | | ENISA (European Union Agency for Cybersecurity) | [Good Practices for Security of SMART CARS](https://www.enisa.europa.eu/publications/smart-cars) | 2019 | -| Government of India, Ministry of Electronics & Information Technology | [Adoption of Mobile AppSec Verification Standard (MASVS) Version 1.0 of OWASP](http://egovstandards.gov.in/sites/default/files/Adoption%20of%20Mobile%20AppSec%20Verification%20Standard%20%28MASVS%29%20Version%201.0%20of%20OWASP_0.pdf) | 2019 | +| Government of India, Ministry of Electronics & Information Technology | [Adoption of Mobile AppSec Verification Standard (MASVS) Version 1.0 of OWASP](http://egovstandards.gov.in/notified-standards-1) | 2019 | | Finish Transport and Communication Agency (TRAFICOM) | [Assessment guideline for electronic identification services (Draft)](https://www.traficom.fi/sites/default/files/media/file/DRAFT%20Traficom%20guideline%20211%202019%20conformity%20assessment%20of%20eID%20service.pdf) | 2019 | | Gobierno de EspaƱa INCIBE | [Ciberseguridad en Smart Toys](https://www.incibe.es/sites/default/files/contenidos/guias/doc/guia_smarttoys_final.pdf) | 2019 | @@ -79,7 +79,7 @@ In 2021, ioXt has [extended its security principles through the Mobile Applicati | University of Adelaide, Australia and Queen Mary University of London, United Kingdom | [An Empirical Assessment of Global COVID-19 Contact Tracing Applications](https://arxiv.org/pdf/2006.10933.pdf) | 2021 | | School of Information Technology, MapĆŗa University, Philippines | [A Vulnerability Assessment on the Parental Control Mobile Applications Security: Status based on the OWASP Security Requirements](http://www.ieomsociety.org/singapore2021/papers/1104.pdf) | 2021 | -## Application in scientific research +## Application in Scientific Research - [STAMBA: Security Testing for Android Mobile Banking Apps](https://link.springer.com/chapter/10.1007/978-3-319-28658-7_57 "Advances in Signal Processing and Intelligent Recognition Systems pp 671-683") diff --git a/Document/0x02c-Acknowledgements.md b/Document/0x02c-Acknowledgements.md index 3a324dad46..85d6fcb00a 100644 --- a/Document/0x02c-Acknowledgements.md +++ b/Document/0x02c-Acknowledgements.md @@ -1,6 +1,6 @@ # Acknowledgments -## MAS Advocates +## šŸ„‡ MAS Advocates MAS Advocates are industry adopters of the OWASP MASVS and MASTG who have invested a significant and consistent amount of resources to push the project forward by providing consistent high-impact contributions and continuously spreading the word. @@ -40,12 +40,12 @@ If you'd like to apply please contact the project leaders by sending an email to ### ā— Important Disclaimers - If the "MAS Advocate" status is granted and you'd like to maintain it, the aforementioned contributions must remain consistent after the initial period as well. You should keep collecting this evidence and send us a _contribution report_ yearly. -- [Financial donations](https://owasp.org/www-project-mobile-security-testing-guide/#div-donate) are not part of the eligibility criteria but will be listed for completion. +- [Financial donations](https://mas.owasp.org/donate/) are not part of the eligibility criteria but will be listed for completion. - Re-shared publications and blog posts linked in MASTG text must be **educational** and focus on mobile security or MASVS/MASTG and **not endorse company products/services**. - Advocate Companies may use the logo and links to MASVS/MASTG resources as part of their communication but cannot use them as an endorsement by OWASP as a preferred provider of software and services. - Example of what's ok: list MAS Advocateā€ status on website home page, in about company slides in sales presentations, on sales collateral. - Example of what's not ok: an MAS Advocateā€ cannot claim they are OWASP certified. -- The quality of the application of the MASVS/MASTG by these companies [has not been vetted by the MAS team](https://github.com/OWASP/owasp-masvs/blob/master/Document/0x04-Assessment_and_Certification.md#owasps-stance-on-masvs-certifications-and-trust-marks). +- The quality of the application of the MASVS/MASTG by these companies [has not been vetted by the MAS team](https://mas.owasp.org/MASVS/0x04-Assessment_and_Certification/#owasps-stance-on-masvs-certifications-and-trust-marks). > The OWASP Foundation is very grateful for the support by the individuals and organizations listed. However please note, the OWASP Foundation is strictly vendor neutral and does not endorse any of its supporters. MAS Advocates do not influence the content of the MASVS or MASTG in any way. @@ -53,17 +53,14 @@ If you'd like to apply please contact the project leaders by sending an email to
- - - - +
[NowSecure](https://www.nowsecure.com) has provided consistent high-impact contributions to the project and has successfully helped spread the word. **We'd like to thank NowSecure for its exemplary contribution which sets a blueprint for other potential contributors wanting to push the project forward.** -### MASVS/MASTG Adopter +### NowSecure as a MASVS/MASTG Adopter - Services / Products: - [NowSecure Debuts New OWASP MASVS Mobile Pen Tests](https://www.nowsecure.com/blog/2022/03/22/nowsecure-debuts-new-owasp-masvs-mobile-pen-tests/) @@ -75,7 +72,7 @@ If you'd like to apply please contact the project leaders by sending an email to - [OWASP MASVS & MASTG Updates](https://academy.nowsecure.com/owasp-masvs-mstg-updates) - [Intro to Mobile App Security](https://academy.nowsecure.com/intro-to-mobile-app-security) -### MASVS/MASTG Contributions +### NowSecure's Contributions to the MAS Project **High-impact Contributions (time/dedicated resources):** @@ -165,6 +162,6 @@ Reviewers have consistently provided useful feedback through GitHub issues and p ### Donators -While both the MASVS and the MASTG are created and maintained by the community on a voluntary basis, sometimes a little bit of outside help is required. We therefore thank our donators for providing the funds to be able to hire technical editors. Note that their donation does not influence the content of the MASVS or MASTG in any way. The Donation Packages are described on our [OWASP Project page](https://owasp.org/www-project-mobile-security-testing-guide/#div-donate "OWASP Mobile Security Testing Guide Donation Packages"). +While both the MASVS and the MASTG are created and maintained by the community on a voluntary basis, sometimes a little bit of outside help is required. We therefore thank our donators for providing the funds to be able to hire technical editors. Note that their donation does not influence the content of the MASVS or MASTG in any way. The Donation Packages are described on our [OWASP Project page](https://mas.owasp.org/donate/ "OWASP MAS Donation Packages"). diff --git a/Document/0x03-Overview.md b/Document/0x03-Overview.md index 2564412a1e..507d02c47c 100644 --- a/Document/0x03-Overview.md +++ b/Document/0x03-Overview.md @@ -1,16 +1,20 @@ -# Overview - -## Introduction to the OWASP Mobile Security Testing Guide +# Introduction to the OWASP Mobile Application Security Project New technology always introduces new security risks, and mobile computing is no exception. Security concerns for mobile apps differ from traditional desktop software in some important ways. Modern mobile operating systems are arguably more secure than traditional desktop operating systems, but problems can still appear when we don't carefully consider security during mobile app development. Data storage, inter-app communication, proper usage of cryptographic APIs, and secure network communication are only some of these considerations. -### Key Areas in Mobile Application Security +The [OWASP Mobile Application Security _Verification Standard_ (MASVS)](https://mas.owasp.org/MASVS/0x01-Foreword) defines a mobile app security model and lists generic security requirements for mobile apps. It can be used by architects, developers, testers, security professionals, and consumers to define and understand the qualities of a secure mobile app. The [OWASP Mobile Application Security _Testing Guide_ (MASTG)](https://mas.owasp.org/MASTG/0x01-Foreword) maps to the same basic set of security requirements offered by the MASVS and depending on the context they can be used individually or combined to achieve different objectives. + + + +For example, the MASVS requirements can be used in an app's planning and architecture design stages while the checklist and testing guide may serve as a baseline for manual security testing or as a template for automated security tests during or after development. In the "[Mobile App Security Testing](0x04b-Mobile-App-Security-Testing.md)" chapter we'll describe how you can apply the checklist and MASTG to a mobile app penetration test. + +## Key Areas in Mobile Application Security Many mobile app penetration testers have a background in network and web app penetration testing, a quality that is valuable for mobile app testing. Almost every mobile app talks to a backend service, and those services are prone to the same types of attacks we are familiar with in web apps on desktop machines. Mobile apps differ in that there is a smaller attack surface and therefore more security against injection and similar attacks. Instead, we must prioritize data protection on the device and the network to increase mobile security. Let's discuss the key areas in mobile app security. -#### Local Data Storage +### Data Storage and Privacy (MASVS-STORAGE) The protection of sensitive data, such as user credentials and private information, is crucial to mobile security. If an app uses operating system APIs such as local storage or inter-process communication (IPC) improperly, the app might expose sensitive data to other apps running on the same device. It may also unintentionally leak data to cloud storage, backups, or the keyboard cache. Additionally, mobile devices can be lost or stolen more easily compared to other types of devices, so it's more likely an individual can gain physical access to the device, making it easier to retrieve the data. @@ -18,39 +22,35 @@ When developing mobile apps, we must take extra care when storing user data. For Fragmentation is a problem we deal with especially on Android devices. Not every Android device offers hardware-backed secure storage, and many devices are running outdated versions of Android. For an app to be supported on these out-of-date devices, it would have to be created using an older version of Android's API which may lack important security features. For maximum security, the best choice is to create apps with the current API version even though that excludes some users. -#### Communication with Trusted Endpoints +### Cryptography (MASVS-CRYPTO) -Mobile devices regularly connect to a variety of networks, including public Wi-Fi networks shared with other (potentially malicious) clients. This creates opportunities for a wide variety of network-based attacks ranging from simple to complicated and old to new. It's crucial to maintain the confidentiality and integrity of information exchanged between the mobile app and remote service endpoints. As a basic requirement, mobile apps must set up a secure, encrypted channel for network communication using the TLS protocol with appropriate settings. +Cryptography is an essential ingredient when it comes to protecting data stored on a mobile device. It is also an area where things can go horribly wrong, especially when standard conventions are not followed. It is essential to ensure that the application uses cryptography according to industry best practices, including the use of proven cryptographic libraries, a proper choice and configuration of cryptographic primitives as well as a suitable random number generator wherever randomness is required. -#### Authentication and Authorization +### Authentication and Authorization (MASVS-AUTH) In most cases, sending users to log in to a remote service is an integral part of the overall mobile app architecture. Even though most of the authentication and authorization logic happens at the endpoint, there are also some implementation challenges on the mobile app side. Unlike web apps, mobile apps often store long-time session tokens that are unlocked with user-to-device authentication features such as fingerprint scanning. While this allows for a quicker login and better user experience (nobody likes to enter complex passwords), it also introduces additional complexity and room for error. Mobile app architectures also increasingly incorporate authorization frameworks (such as OAuth2) that delegate authentication to a separate service or outsource the authentication process to an authentication provider. Using OAuth2 allows the client-side authentication logic to be outsourced to other apps on the same device (e.g. the system browser). Security testers must know the advantages and disadvantages of different possible authorization frameworks and architectures. -#### Interaction with the Mobile Platform +### Network Communication (MASVS-NETWORK) + +Mobile devices regularly connect to a variety of networks, including public Wi-Fi networks shared with other (potentially malicious) clients. This creates opportunities for a wide variety of network-based attacks ranging from simple to complicated and old to new. It's crucial to maintain the confidentiality and integrity of information exchanged between the mobile app and remote service endpoints. As a basic requirement, mobile apps must set up a secure, encrypted channel for network communication using the TLS protocol with appropriate settings. + +### Interaction with the Mobile Platform (MASVS-PLATFORM) Mobile operating system architectures differ from classical desktop architectures in important ways. For example, all mobile operating systems implement app permission systems that regulate access to specific APIs. They also offer more (Android) or less rich (iOS) inter-process communication (IPC) facilities that enable apps to exchange signals and data. These platform-specific features come with their own set of pitfalls. For example, if IPC APIs are misused, sensitive data or functionality might be unintentionally exposed to other apps running on the device. -#### Code Quality and Exploit Mitigation +### Code Quality and Exploit Mitigation (MASVS-CODE) -Traditional injection and memory management issues aren't often seen in mobile apps due to the smaller attack surface. Mobile apps mostly interact with the trusted backend service and the UI, so even if many buffer overflow vulnerabilities exist in the app, those vulnerabilities usually don't open up any useful attack vectors. The same applies to browser exploits such as cross-site scripting (XSS allows attackers to inject scripts into web pages) that are very prevalent in web apps. However, there are always exceptions. XSS is theoretically possible on mobile in some cases, but it's very rare to see XSS issues that an individual can exploit. For more information about XSS, see the "[Cross-Site Scripting Flaws](0x04h-Testing-Code-Quality.md#cross-site-scripting-flaws-mstg-arch-2-and-mstg-platform-2)" section in the chapter "Testing Code Quality". +Traditional injection and memory management issues aren't often seen in mobile apps due to the smaller attack surface. Mobile apps mostly interact with the trusted backend service and the UI, so even if many buffer overflow vulnerabilities exist in the app, those vulnerabilities usually don't open up any useful attack vectors. The same applies to browser exploits such as cross-site scripting (XSS allows attackers to inject scripts into web pages) that are very prevalent in web apps. However, there are always exceptions. XSS is theoretically possible on mobile in some cases, but it's very rare to see XSS issues that an individual can exploit. This protection from injection and memory management issues doesn't mean that app developers can get away with writing sloppy code. Following security best practices results in hardened (secure) release builds that are resilient against tampering. Free security features offered by compilers and mobile SDKs help increase security and mitigate attacks. -#### Anti-Tampering and Anti-Reversing +### Anti-Tampering and Anti-Reversing (MASVS-RESILIENCE) There are three things you should never bring up in polite conversations: religion, politics, and code obfuscation. Many security experts dismiss client-side protections outright. However, software protection controls are widely used in the mobile app world, so security testers need ways to deal with these protections. We believe there's a benefit to client-side protections if they are employed with a clear purpose and realistic expectations in mind and aren't used to replace security controls. -## The OWASP Mobile AppSec Verification Standard - -This guide is closely related to the OWASP Mobile Application Security Verification Standard (MASVS). The MASVS defines a mobile app security model and lists generic security requirements for mobile apps. It can be used by architects, developers, testers, security professionals, and consumers to define and understand the qualities of a secure mobile app. The MASTG maps to the same basic set of security requirements offered by the MASVS and depending on the context they can be used individually or combined to achieve different objectives. - - - -For example, the MASVS requirements can be used in an app's planning and architecture design stages while the checklist and testing guide may serve as a baseline for manual security testing or as a template for automated security tests during or after development. In the "[Mobile App Security Testing](0x04b-Mobile-App-Security-Testing.md)" chapter we'll describe how you can apply the checklist and MASTG to a mobile app penetration test. - -## Navigating the Mobile Security Testing Guide +## Navigating the OWASP MASTG The MASTG contains descriptions of all requirements specified in the MASVS. The MASTG contains the following main sections: diff --git a/Document/0x04a-Mobile-App-Taxonomy.md b/Document/0x04a-Mobile-App-Taxonomy.md index 8e9ebb163d..83324bf464 100644 --- a/Document/0x04a-Mobile-App-Taxonomy.md +++ b/Document/0x04a-Mobile-App-Taxonomy.md @@ -1,6 +1,6 @@ -# Mobile App Taxonomy +# Mobile Application Taxonomy -The term "mobile app" refers to a self-contained computer program designed to execute on a mobile device. Today, the Android and iOS operating systems cumulatively comprise [more than 99% of the mobile OS market share](https://www.idc.com/promo/smartphone-market-share/os). Additionally, mobile Internet usage has surpassed desktop usage for the first time in history, making mobile browsing and apps the [most widespread kind of Internet-capable applications](https://www.idc.com/promo/smartphone-market-share/os). +The term "mobile application" or "mobile app" refers to a self-contained computer program designed to execute on a mobile device. Today, the Android and iOS operating systems cumulatively comprise [more than 99% of the mobile OS market share](https://www.idc.com/promo/smartphone-market-share/os). Additionally, mobile Internet usage has surpassed desktop usage for the first time in history, making mobile browsing and apps the [most widespread kind of Internet-capable apps](https://www.idc.com/promo/smartphone-market-share/os). > In this guide, we'll use the term "app" as a general term for referring to any kind of application running on popular mobile OSes. @@ -8,7 +8,7 @@ In a basic sense, apps are designed to run either directly on the platform for w ## Native App -Mobile operating systems, including Android and iOS, come with a Software Development Kit (SDK) for developing applications specific to the OS. Such applications are referred to as _native_ to the system for which they have been developed. When discussing an app, the general assumption is that it is a native app implemented in a standard programming language for the respective operating system - Objective-C or Swift for iOS, and Java or Kotlin for Android. +Mobile operating systems, including Android and iOS, come with a Software Development Kit (SDK) for developing apps specific to the OS. Such apps are referred to as _native_ to the system for which they have been developed. When discussing an app, the general assumption is that it is a native app implemented in a standard programming language for the respective operating system - Objective-C or Swift for iOS, and Java or Kotlin for Android. Native apps inherently have the capability to provide the fastest performance with the highest degree of reliability. They usually adhere to platform-specific design principles (e.g. the [Android Design Principles](https://developer.android.com/design "Android Design Principles")), which tends to result in a more consistent user interface (UI) compared to _hybrid_ or _web_ apps. Due to their close integration with the operating system, native apps can directly access almost every component of the device (camera, sensors, hardware-backed key stores, etc.). @@ -20,7 +20,7 @@ The most obvious downside of _native apps_ is that they target only one specific - [Google Flutter](https://flutter.dev/ "Google Flutter") - [React Native](https://reactnative.dev/ "React Native") -Applications developed using these frameworks internally use the APIs native to the system and offer performance equivalent to native applications. Also, these apps can make use of all device capabilities, including the GPS, accelerometer, camera, the notification system, etc. Since the final output is very similar to previously discussed _native apps_, apps developed using these frameworks can also be considered as _native apps_. +Apps developed using these frameworks internally use the APIs native to the system and offer performance equivalent to native apps. Also, these apps can make use of all device capabilities, including the GPS, accelerometer, camera, the notification system, etc. Since the final output is very similar to previously discussed _native apps_, apps developed using these frameworks can also be considered as _native apps_. ## Web App @@ -32,7 +32,7 @@ Web apps have limited integration with the general components of the device as t Hybrid apps attempt to fill the gap between _native_ and _web apps_. A _hybrid app_ executes like a _native app_, but a majority of the processes rely on web technologies, meaning a portion of the app runs in an embedded web browser (commonly called "WebView"). As such, hybrid apps inherit both pros and cons of _native_ and _web apps_. -A web-to-native abstraction layer enables access to device capabilities for _hybrid apps_ not accessible to a pure _web app_. Depending on the framework used for development, one code base can result in multiple applications that target different platforms, with a UI closely resembling that of the original platform for which the app was developed. +A web-to-native abstraction layer enables access to device capabilities for _hybrid apps_ not accessible to a pure _web app_. Depending on the framework used for development, one code base can result in multiple apps that target different platforms, with a UI closely resembling that of the original platform for which the app was developed. Following is a non-exhaustive list of more popular frameworks for developing _hybrid apps_: diff --git a/Document/0x04b-Mobile-App-Security-Testing.md b/Document/0x04b-Mobile-App-Security-Testing.md index 41b91b2662..f83e85e1eb 100644 --- a/Document/0x04b-Mobile-App-Security-Testing.md +++ b/Document/0x04b-Mobile-App-Security-Testing.md @@ -1,4 +1,4 @@ -# Mobile App Security Testing +# Mobile Application Security Testing In the following sections we'll provide a brief overview of general security testing principles and key terminology. The concepts introduced are largely identical to those found in other types of penetration testing, so if you are an experienced tester you may be familiar with some of the content. @@ -26,7 +26,7 @@ Vulnerability analysis is usually the process of looking for vulnerabilities in ### Static versus Dynamic Analysis -Static Application Security Testing (SAST) involves examining an application's components without executing them, by analyzing the source code either manually or automatically. +Static Application Security Testing (SAST) involves examining an app's components without executing them, by analyzing the source code either manually or automatically. OWASP provides information about [Static Code Analysis](https://owasp.org/www-community/controls/Static_Code_Analysis "OWASP Static Code Analysis") that may help you understand techniques, strengths, weaknesses, and limitations. Dynamic Application Security Testing (DAST) involves examining the app during runtime. This type of analysis can be manual or automatic. It usually doesn't provide the information that static analysis provides, but it is a good way to detect interesting elements (assets, features, entry points, etc.) from a user's point of view. @@ -39,13 +39,13 @@ During static analysis, the mobile app's source code is reviewed to ensure appro #### Manual Code Review -A tester performs manual code review by manually analyzing the mobile application's source code for security vulnerabilities. Methods range from a basic keyword search via the 'grep' command to a line-by-line examination of the source code. IDEs (Integrated Development Environments) often provide basic code review functions and can be extended with various tools. +A tester performs manual code review by manually analyzing the mobile app's source code for security vulnerabilities. Methods range from a basic keyword search via the 'grep' command to a line-by-line examination of the source code. IDEs (Integrated Development Environments) often provide basic code review functions and can be extended with various tools. A common approach to manual code analysis entails identifying key security vulnerability indicators by searching for certain APIs and keywords, such as database-related method calls like "executeStatement" or "executeQuery". Code containing these strings is a good starting point for manual analysis. In contrast to automatic code analysis, manual code review is very good for identifying vulnerabilities in the business logic, standards violations, and design flaws, especially when the code is technically secure but logically flawed. Such scenarios are unlikely to be detected by any automatic code analysis tool. -A manual code review requires an expert code reviewer who is proficient in both the language and the frameworks used for the mobile application. Full code review can be a slow, tedious, time-consuming process for the reviewer, especially given large code bases with many dependencies. +A manual code review requires an expert code reviewer who is proficient in both the language and the frameworks used for the mobile app. Full code review can be a slow, tedious, time-consuming process for the reviewer, especially given large code bases with many dependencies. #### Automated Source Code Analysis @@ -70,7 +70,7 @@ Dynamic analysis is usually used to check for security mechanisms that provide s Automated testing tools' lack of sensitivity to app context is a challenge. These tools may identify a potential issue that's irrelevant. Such results are called "false positives". -For example, security testers commonly report vulnerabilities that are exploitable in a web browser but aren't relevant to the mobile app. This false positive occurs because automated tools used to scan the backend service are based on regular browser-based web applications. Issues such as CSRF (Cross-site Request Forgery) and Cross-Site Scripting (XSS) are reported accordingly. +For example, security testers commonly report vulnerabilities that are exploitable in a web browser but aren't relevant to the mobile app. This false positive occurs because automated tools used to scan the backend service are based on regular browser-based web apps. Issues such as CSRF (Cross-site Request Forgery) and Cross-Site Scripting (XSS) are reported accordingly. Let's take CSRF as an example. A successful CSRF attack requires the following: @@ -83,19 +83,6 @@ Stored Cross-Site Scripting (XSS) can be an issue if the app includes WebViews, > In any case, consider exploit scenarios when you perform the risk assessment; don't blindly trust your scanning tool's output. -#### Clipboard - -When typing data into input fields, the clipboard can be used to copy in data. The clipboard is accessible system-wide and is therefore shared by apps. This sharing can be misused by malicious apps to get sensitive data that has been stored in the clipboard. - -Before iOS 9, a malicious app might monitor the pasteboard in the background while periodically retrieving `[UIPasteboard generalPasteboard].string`. As of iOS 9, pasteboard content is accessible to apps in the foreground only, which reduces the attack surface of password sniffing from the clipboard dramatically. - -For [Android there was a PoC exploit released](https://arstechnica.com/information-technology/2014/11/using-a-password-manager-on-android-it-may-be-wide-open-to-sniffing-attacks/ "Password Sniffing") in order to demonstrate the attack vector if passwords are stored within the clipboard. [Disabling pasting in passwords input fields](https://github.com/OWASP/owasp-masvs/issues/106 "Disabling Pasting for Password Input Fields") was a requirement in the MASVS 1.0, but was removed due to several reasons: - -- Preventing pasting into input fields of an app, does not prevent that a user will copy sensitive information anyway. Since the information has already been copied before the user notices that it's not possible to paste it in, a malicious app has already sniffed the clipboard. -- If pasting is disabled on password fields users might even choose weaker passwords that they can remember and they cannot use password managers anymore, which would contradict the original intention of making the app more secure. - -When using an app you should still be aware that other apps are reading the clipboard continuously, as the [Facebook app](https://www.thedailybeast.com/facebook-is-spying-on-your-clipboard "Facebook Is Spying On Your Clipboard") did. Still, copy-pasting passwords is a security risk you should be aware of, but also cannot be solved by an app. - ### Penetration Testing (a.k.a. Pentesting) The classic approach involves all-around security testing of the app's final or near-final build, e.g., the build that's available at the end of the development process. For testing at the end of the development process, we recommend the [Mobile App Security Verification Standard (MASVS)](https://github.com/OWASP/owasp-masvs "OWASP MASVS") and the associated checklist as baseline for testing. A typical security test is structured as follows: @@ -112,9 +99,7 @@ The security level at which the app will be tested must be decided before testin Organizations may have different regulatory and legal obligations in certain territories. Even if an app doesn't handle sensitive data, some L2 requirements may be relevant (because of industry regulations or local laws). For example, two-factor authentication (2FA) may be obligatory for a financial app and enforced by a country's central bank and/or financial regulatory authorities. -Security goals/controls defined earlier in the development process may also be reviewed during the discussion with stakeholders. Some controls may conform to MASVS controls, but others may be specific to the organization or application. - - +Security goals/controls defined earlier in the development process may also be reviewed during the discussion with stakeholders. Some controls may conform to MASVS controls, but others may be specific to the organization or app. All involved parties must agree on the decisions and the scope in the checklist because these will define the baseline for all security testing. @@ -137,10 +122,10 @@ Classifications of sensitive information differ by industry and country. In addi There are three general states from which data may be accessible: - **At rest** - the data is sitting in a file or data store -- **In use** - an application has loaded the data into its address space +- **In use** - an app has loaded the data into its address space - **In transit** - data has been exchanged between mobile app and endpoint or consuming processes on the device, e.g., during IPC (Inter-Process Communication) -The degree of scrutiny that's appropriate for each state may depend on the data's importance and likelihood of being accessed. For example, data held in application memory may be more vulnerable than data on web servers to access via core dumps because attackers are more likely to gain physical access to mobile devices than to web servers. +The degree of scrutiny that's appropriate for each state may depend on the data's importance and likelihood of being accessed. For example, data held in app memory may be more vulnerable than data on web servers to access via core dumps because attackers are more likely to gain physical access to mobile devices than to web servers. When no data classification policy is available, use the following list of information that's generally considered sensitive: @@ -149,7 +134,7 @@ When no data classification policy is available, use the following list of infor - device identifiers that may identify a person - highly sensitive data whose compromise would lead to reputational harm and/or financial costs - any data whose protection is a legal obligation -- any technical data generated by the application (or its related systems) and used to protect other data or the system itself (e.g., encryption keys). +- any technical data generated by the app (or its related systems) and used to protect other data or the system itself (e.g., encryption keys). A definition of "sensitive data" must be decided before testing begins because detecting sensitive data leakage without a definition may be impossible. @@ -236,9 +221,9 @@ Security wasn't originally an integral part of software development. It was an a SDLCs always consist of the same steps (the overall process is sequential in the Waterfall paradigm and iterative in the Agile paradigm): -- Perform a **risk assessment** for the application and its components to identify their risk profiles. These risk profiles typically depend on the organization's risk appetite and applicable regulatory requirements. The risk assessment is also based on factors, including whether the application is accessible via the Internet and the kind of data the application processes and stores. All kinds of risks must be taken into account: financial, marketing, industrial, etc. Data classification policies specify which data is sensitive and how it must be secured. +- Perform a **risk assessment** for the app and its components to identify their risk profiles. These risk profiles typically depend on the organization's risk appetite and applicable regulatory requirements. The risk assessment is also based on factors, including whether the app is accessible via the Internet and the kind of data the app processes and stores. All kinds of risks must be taken into account: financial, marketing, industrial, etc. Data classification policies specify which data is sensitive and how it must be secured. - **Security Requirements** are determined at the beginning of a project or development cycle, when functional requirements are being gathered. **Abuse Cases** are added as use cases are created. Teams (including development teams) may be given security training (such as Secure Coding) if they need it. -You can use the [OWASP MASVS](https://mobile-security.gitbook.io/masvs/ "OWASP MASVS") to determine the security requirements of mobile applications on the basis of the risk assessment phase. Iteratively reviewing requirements when features and data classes are added is common, especially with Agile projects. +You can use the [OWASP MASVS](https://mas.owasp.org/MASVS/0x01-Foreword "OWASP MASVS") to determine the security requirements of mobile apps on the basis of the risk assessment phase. Iteratively reviewing requirements when features and data classes are added is common, especially with Agile projects. - **Threat Modeling**, which is basically the identification, enumeration, prioritization, and initial handling of threats, is a foundational artifact that must be performed as architecture development and design progress. **Security Architecture**, a Threat Model factor, can be refined (for both software and hardware aspects) after the Threat Modeling phase. **Secure Coding rules** are established and the list of **Security tools** that will be used is created. The strategy for **Security testing** is clarified. - All security requirements and design considerations should be stored in the Application Life Cycle Management (ALM) system (also known as the issue tracker) that the development/ops team uses to ensure tight integration of security requirements into the development workflow. The security requirements should contain relevant source code snippets so that developers can quickly reference the snippets. Creating a dedicated repository that's under version control and contains only these code snippets is a secure coding strategy that's more beneficial than the traditional approach (storing the guidelines in word documents or PDFs). - **Securely develop the software**. To increase code security, you must complete activities such as **Security Code Reviews**, **Static Application Security Testing**, and **Security Unit Testing**. Although quality analogues of these security activities exist, the same logic must be applied to security, e.g., reviewing, analyzing, and testing code for security defects (for example, missing input validation, failing to free all resources, etc.). @@ -295,7 +280,7 @@ People may assume that the term "DevOps" represents collaboration between develo In other words, DevOps collaboration includes quality teams, security teams, and many other teams related to the project. When you hear "DevOps" today, you should probably be thinking of something like [DevOpsQATestInfoSec](https://techbeacon.com/evolution-devops-new-thinking-gene-kim "The evolution of DevOps: Gene Kim on getting to continuous delivery"). Indeed, DevOps values pertain to increasing not only speed but also quality, security, reliability, stability, and resilience. -Security is just as critical to business success as the overall quality, performance, and usability of an application. As development cycles are shortened and delivery frequencies increased, making sure that quality and security are built in from the very beginning becomes essential. **DevSecOps** is all about adding security to DevOps processes. Most defects are identified during production. DevOps specifies best practices for identifying as many defects as possible early in the life cycle and for minimizing the number of defects in the released application. +Security is just as critical to business success as the overall quality, performance, and usability of an app. As development cycles are shortened and delivery frequencies increased, making sure that quality and security are built in from the very beginning becomes essential. **DevSecOps** is all about adding security to DevOps processes. Most defects are identified during production. DevOps specifies best practices for identifying as many defects as possible early in the life cycle and for minimizing the number of defects in the released app. However, DevSecOps is not just a linear process oriented towards delivering the best possible software to operations; it is also a mandate that operations closely monitor software that's in production to identify issues and fix them by forming a quick and efficient feedback loop with development. DevSecOps is a process through which Continuous Improvement is heavily emphasized. @@ -321,8 +306,8 @@ Instead of manually provisioning computing resources (physical servers, virtual Infrastructure as Code practices facilitate collaboration between development and operations teams, with the following results: -- Devs better understand infrastructure from a familiar point of view and can prepare resources that the running application will require. -- Ops operate an environment that better suits the application, and they share a language with Devs. +- Devs better understand infrastructure from a familiar point of view and can prepare resources that the running app will require. +- Ops operate an environment that better suits the app, and they share a language with Devs. Infrastructure as Code also facilitates the construction of the environments required by classical software creation projects, for **development** ("DEV"), **integration** ("INT"), **testing** ("PPR" for Pre-Production. Some tests are usually performed in earlier environments, and PPR tests mostly pertain to non-regression and performance with data that's similar to data used in production), and **production** ("PRD"). The value of infrastructure as code lies in the possible similarity between environments (they should be the same). @@ -332,7 +317,7 @@ The main tools in this domain are [Puppet](https://puppet.com/ "Puppet"), [Terra ##### Deployment -The deployment pipeline's sophistication depends on the maturity of the project organization or development team. In its simplest form, the deployment pipeline consists of a commit phase. The commit phase usually involves running simple compiler checks and the unit test suite as well as creating a deployable artifact of the application. A release candidate is the latest version that has been checked into the trunk of the version control system. Release candidates are evaluated by the deployment pipeline for conformity to standards they must fulfill for deployment to production. +The deployment pipeline's sophistication depends on the maturity of the project organization or development team. In its simplest form, the deployment pipeline consists of a commit phase. The commit phase usually involves running simple compiler checks and the unit test suite as well as creating a deployable artifact of the app. A release candidate is the latest version that has been checked into the trunk of the version control system. Release candidates are evaluated by the deployment pipeline for conformity to standards they must fulfill for deployment to production. The commit phase is designed to provide instant feedback to developers and is therefore run on every commit to the trunk. Time constraints exist because of this frequency. The commit phase should usually be complete within five minutes, and it shouldn't take longer than ten. Adhering to this time constraint is quite challenging when it comes to security because many security tools can't be run quickly enough (#paul, #mcgraw). @@ -342,7 +327,7 @@ CI/CD means "Continuous Integration/Continuous Delivery" in some contexts and "C - Continuous Delivery candidate releases can proceed to the pre-production environment. If the release can then be validated (either manually or automatically), deployment can continue. If not, the project team will be notified and proper action(s) must be taken. - Continuous Deployment releases are directly transitioned from integration to production, e.g., they become accessible to the user. However, no release should go to production if significant defects have been identified during previous activities. -The delivery and deployment of applications with low or medium sensitivity may be merged into a single step, and validation may be performed after delivery. However, keeping these two actions separate and using strong validation are strongly advised for sensitive applications. +The delivery and deployment of apps with low or medium sensitivity may be merged into a single step, and validation may be performed after delivery. However, keeping these two actions separate and using strong validation are strongly advised for sensitive apps. ##### Security @@ -351,13 +336,13 @@ At this point, the big question is: now that other activities required for deliv Once again, the answer is automation and tooling: by implementing these two concepts throughout the project life cycle, you can maintain and improve security. The higher the expected level of security, the more controls, checkpoints, and emphasis will take place. The following are examples: - Static Application Security Testing can take place during the development phase, and it can be integrated into the Continuous Integration process with more or less emphasis on scan results. You can establish more or less demanding Secure Coding Rules and use SAST tools to check the effectiveness of their implementation. -- Dynamic Application Security Testing may be automatically performed after the application has been built (e.g., after Continuous Integration has taken place) and before delivery, again, with more or less emphasis on results. +- Dynamic Application Security Testing may be automatically performed after the app has been built (e.g., after Continuous Integration has taken place) and before delivery, again, with more or less emphasis on results. - You can add manual validation checkpoints between consecutive phases, for example, between delivery and deployment. -The security of an application developed with DevOps must be considered during operations. The following are examples: +The security of an app developed with DevOps must be considered during operations. The following are examples: - Scanning should take place regularly (at both the infrastructure and application level). -- Pentesting may take place regularly. (The version of the application used in production is the version that should be pentested, and the testing should take place in a dedicated environment and include data that's similar to the production version data. See the section on Penetration Testing for more details.) +- Pentesting may take place regularly. (The version of the app used in production is the version that should be pentested, and the testing should take place in a dedicated environment and include data that's similar to the production version data. See the section on Penetration Testing for more details.) - Active monitoring should be performed to identify issues and remediate them as soon as possible via the feedback loop. diff --git a/Document/0x06h-Testing-Platform-Interaction.md b/Document/0x06h-Testing-Platform-Interaction.md index d7e4707a2d..34d065b0d5 100644 --- a/Document/0x06h-Testing-Platform-Interaction.md +++ b/Document/0x06h-Testing-Platform-Interaction.md @@ -1417,6 +1417,13 @@ If you want to learn more about what's happening under-the-hood in terms of XPC, #### Overview +When typing data into input fields, the clipboard can be used to copy in data. The clipboard is accessible system-wide and is therefore shared by apps. This sharing can be misused by malicious apps to get sensitive data that has been stored in the clipboard. + +When using an app you should be aware that other apps might be reading the clipboard continuously, as the [Facebook app](https://www.thedailybeast.com/facebook-is-spying-on-your-clipboard "Facebook Is Spying On Your Clipboard") did. Before iOS 9, a malicious app might monitor the pasteboard in the background while periodically retrieving `[UIPasteboard generalPasteboard].string`. As of iOS 9, pasteboard content is accessible to apps in the foreground only, which reduces the attack surface of password sniffing from the clipboard dramatically. Still, copy-pasting passwords is a security risk you should be aware of, but also cannot be solved by an app. + +- Preventing pasting into input fields of an app, does not prevent that a user will copy sensitive information anyway. Since the information has already been copied before the user notices that it's not possible to paste it in, a malicious app has already sniffed the clipboard. +- If pasting is disabled on password fields users might even choose weaker passwords that they can remember and they cannot use password managers anymore, which would contradict the original intention of making the app more secure. + The [`UIPasteboard`](https://developer.apple.com/documentation/uikit/uipasteboard "UIPasteboard") enables sharing data within an app, and from an app to other apps. There are two kinds of pasteboards: - **systemwide general pasteboard**: for sharing data with any app. Persistent by default across device restarts and app uninstalls (since iOS 10). diff --git a/Document/0x08a-Testing-Tools.md b/Document/0x08a-Testing-Tools.md index c60d6231ad..50f0c51241 100644 --- a/Document/0x08a-Testing-Tools.md +++ b/Document/0x08a-Testing-Tools.md @@ -1421,7 +1421,7 @@ cy# [alertView show] cy# [alertView release] ``` - + Find the app's document directory with Cycript: diff --git a/Document/CHANGELOG.md b/Document/CHANGELOG.md index ce80290414..8f6ebc731a 100644 --- a/Document/CHANGELOG.md +++ b/Document/CHANGELOG.md @@ -1,217 +1,5 @@ # Changelog -## V1.2.1 and newer +All our Changelogs are available online at the OWASP MASTG GitHub repository, see the Releases page: -All our Changelogs are available online at the OWASP MSTG GitHub repository, see the [Releases page](https://github.com/OWASP/owasp-mastg/releases). - -## v1.2 - 25th July 2021 - -167 issues were closed since the last release. A full overview can be seen in Github Issues . - -326 pull requests were merged since the last release. A full overview can be seen in Github Pull Requests - -Major changes include: - -- Migrating the new document build pipeline from MASVS to MSTG. This allows us to build consistently the whole OWASP MSTG documents (PDF, docx etc.) in minutes, without any manual work. -- Besides numerous changes for the test cases we have a new Crackme - Android Level 4 and also new write-ups for the Crackmes. -- We removed all references to Needle and IDB tool, as both tools are outdated. -- References of OWASP Mobile Top 10 and MSTG-IDs are completely moved to MASVS -- Reworking of information gathering (static analysis) for Android Apps -- Update of Biometric Authentication for Android Apps -- New content and updates in the Android and iOS Reverse Engineering and Tampering chapters -- 3 new iOS Reverse Engineering test cases -- Translations of the MSTG are linked to the respective forks but are not part of the MSTG anymore -- Updated English, Japanese, French, Korean and Spanish checklists to be compatible with MSTG 1.2 -- Updated Acknowledgments, with 1 new co-author and contributor -- Added JNI Tracing for Android -- Added dsdump for dumping Objective-C and Swift content -- Added the procedure to sign the debugserver for iOS 12 and higher -- Added dependency-check to verify for vulnerabilities in libraries added by iOS package managers -- Added getppid as debugger detection (iOS) -- Added Domain/URL Enumeration in APKs -- Added introduction into Network.framework (iOS) -- Added UnSAFE Bank iOS Application -- Added information on SECCOMP (Android) -- Added native and java method tracing (Android) -- Added Android library injection -- Added Android 10 TLS and cryptography updates -- Updated code obfuscation for Android and iOS -- Added test case for Reverse Engineering Tools Detection - MSTG-RESILIENCE-4 (iOS) -- Added test case for Emulator Detection - MSTG-RESILIENCE-5 (iOS) -- Added an example with truststore to bypass cert pinning (Android) -- Added content to information gathering using frida (Android) -- Added Sec Consult, RandoriSec and OWASP Bay area as donators -- Added basic information gathering for Android and iOS -- Added Simulating a Man-in-the-Middle Attack with an Access Point -- Added gender neutrality to the MSTG -- Extended section about dealing with Xamarin Apps -- Updated all picture links (img tags) to be in markdown syntax -- Updated iTunes limitations and usage since macOS Catalina -- Added Emulation-based Analysis (iOS and Android) -- Added Debugging iOS release applications using lldb -- Added Korean translation of the checklist -- Updated symbolic execution content (Android) -- Added Ghidra for Android Reverse Engineering -- Added section on Manual (Reversed) Code Review for iOS -- Added explanation of more Frida APIs (iOS and Android) -- Added Apple CryptoKit -- Updated and simplified Frida detection methods -- Added introduction to setup and disassembling for iOS Apps -- Updated section about frida-ios-dump -- Added gplaycli (Android) -- Extended section on how to retrieve UDI (iOS) -- Added new companies in the Users.md list with companies applying the MSTG/MASVS -- Updated partially code samples to Swift 5 -- Adding Process Exploration (Android and iOS) -- Updated best practices for passwords, added "Have I Been Pwned" -- Updated SSL Pinning fallback methods -- Updated app identifier (Android and iOS) -- Updated permission changes for Android O, P and Q -- Updated Broadcast Receiver section (Android) - -Several other minor updates include fixing typos and markdown lint errors and updating outdated links. - -We thank you all contributors for the hard work and continuously improving the document and the OWASP MSTG project! - -## v1.1.3 - 2 August 2019 - -- Updated Acknowledgments, with 2 new co-authors. -- Translated various parts into Japanese. -- A large restructuring of the general testing, platform specific testing and reverse-engineering chapters. -- Updated description of many tools: Adb, Angr, APK axtractor, Apkx, Burp Suite, Drozer, ClassDump(Z/etc), Clutch, Drozer, Frida, Hopper, Ghidra, IDB, Ipa Installer, iFunBox, iOS-deploy, KeychainDumper, Mobile-Security-Framework, Nathan, Needle, Objection, Magisk, PassionFruit, Radare 2, Tableplus, SOcket CAT, Xposed, and others. -- Updated most of the iOS hacking/verification techniques using iOS 12 or 11 as a base instead of iOS 9/10. -- Removed tools which were no longer updated, such as introspy-Android and AndBug. -- Added missing MASVS references from version 1.1.4: v1.X, V3.5, V5.6, V6.2-V6.5, V8.2-V8.6. -- Rewrote device-binding explanation and testcases for Android. -- Added parts on testing unmanaged code in Objective-C, Java, and C/C++. -- Applied many spelling, punctuation and style-related fixes. -- Updated many cryptography related parts. -- Added testaces for upgrade-mechanism verification for apps. -- Updated Readme, Code of Conduct, Contribution guidelines, verification, funding link, and generation scripts. -- Added ISBN as the book is now available at Lulu. -- Added various fixes for the .epub format. -- Added testcases on Android and iOS backup verification. -- Improved key-attestation related explanation for Android. -- Restructured OWASP Mobile Wiki. -- Removed Yahoo Weather app and simplified reference on using SQL injection. -- Improve explanation for iOS app sideloading to include various available methods. -- Added explanation on using ADB and device shell for Android. -- Added explanation on using device shell for iOS. -- Provided comparison for using emulators/simulators and real devices for iOS/Android. -- Fixed Uncrackable Level 3 for Android. -- Improved explanation on how to exfiltrate data and apps on iOS 12 and Android 8. -- Improved/updated explanation on SSL-pinning. -- Added list of adopters of the MASVS/MSTG. -- Updated English, Japanese, French and Spanish checklists to be compatible with MSTG 1.1.2. -- Added a small write-up on Adiantum for Google. -- Added MSTG-ID to the paragraphs to create a link between MSTG paragraphs and MASVS requirements. -- Added review criteria for Android instant apps and guidance for app-bundle evaluation. -- Clarified the differences between various methods of dynamic analysis. - -## v1.1.2 - 12 May 2019 - -- Added missing mappings for MASVS V1.X. -- Updated markdown throughout the English MSTG to be consistent. -- Replaces some dead links. -- Improvements for rendering as a book, including the ISBN number. -- Updated the Excel: it is now available in Japanese as well! -- Many punctuation corrections, spelling and grammar issues resolved. -- Added missing iOS test case regarding memory corruption issues. -- Added contributing, code of conduct, markdown linting and dead link detection. - -## v1.1.1 - 7 May 2019 - -- Improvements on various tool related parts, such as how to use on-device console, adb, nscurl, Frida and Needle. -- Updated 0x4e regarding SMS communication. -- Many grammar/style updates. -- Added Android description regarding MASVS requirement 7.8. -- Updated contributor list. -- Various updates on instructions regarding TLS and encryption. -- Removed some erroneous information. -- Fixed parts of the alignment of the MASVS requirements with the MSTG. -- Updated information on various topics such as jailbreaking and network interception on both iOS and Android. -- Added some steps for Frida detection. -- Added write-ups on Android changes, regarding permissions, application signing, device identifiers, key attestation and more. -- Extended guidance on SafetyNet attestation. -- Added information on Magisk. -- Added Firebase misconfiguration information. -- Added references to more testing tools. -- Updated contributor list. -- Added a lot of information to iOS platform testing. -- Added a lot of fixes for our book-release. - -## v1.1.0 - 30 Nov 2018 - -- Added more samples in Kotlin. -- Simplified leanpub and gitbook publishing. -- A lot of QA improvements. -- Added deserialization test cases for iOS, including input sanitization. -- Added test cases regarding device-access-security policies and data storage on iOS. -- Added test cases regarding session invalidation. -- Improved cryptography and key management test cases on both Android and iOS. -- Started adding various updates in the test cases introduced by Android Oreo and Android Pie. -- Refreshed the Testing Tools section: removed some of the lesser maintained tools, added new tools. -- Fixed some of the markdown issues. -- Updated license to CC 4.0. -- Started Japanese translation. -- Updated references to OWASP Mobile Top 10. -- Updated Android Crackmes. -- Fixed some of the anti-reverse-engineering test cases. -- Added debugging test case for iOS. - -## v1.0.2 - 13 Oct 2018 - -- Updated guiding documentation (README). -- Improved automated build of the pdf, epub and mobi. -- Updated Frontispiece (given new contributor stats). -- Added attack surface sections for Android and various. -- Added vulnerable apps for testing skills. -- Improved sections for testing App permissions for Android (given android Oreo/Pie), added section for testing permissions on iOS. -- Added fix for Fragment Injection on older Android versions. -- Improved sections on iOS WebView related testing. - -## v1.0.1 - 17 Sept 2018 - -- Updated guiding documentation (README, PR templates, improved style guide, issue templates). -- Added automated build of the pdf and DocX. -- Updated Frontispiece (given new contributor stats). -- Updated Crackmes and guiding documentation. -- Updated tooling commands (adb, ABE, iMazing, Needle, IPAinstaller, etc.). -- Added first Russian translations of the 1.0 documents for iOS. -- Improved URLs for GitBook using goo.gl in case of URLs with odd syntax. -- Updated Frontispiece to give credit to all that have helped out for this version. -- Clarified the app taxonomy & security testing sections by a rewrite. -- Added sections for network testing, certificate verification & SSL pinning for Cordova, WebView, Xamarin, React-Native and updated the public key pinning sections. -- Removed no longer working guides (e.g. using iTunes to install apps). -- Updated a lot of URLs (using TLS wherever possible). -- Updated tests regarding WebViews. -- Added new testing tool suites in the tools section, such as the mobile hack tools and various dependency checkers. -- Updated test cases regarding protocol handlers (added missing MASVS 6.6 for iOS). -- Many small updates in terms of wording, spelling/typos, updated code segments and grammar. -- Added missing test cases for MASVS 2.11, 4.7, 7.5 and 4.11. -- Updated the XLS Checklist given MASVS 1.1.0. -- Removed the clipboard test from iOS and Android. -- Removed duplicates on local storage testing and updated data storage test cases. -- Added write-ups from the mobile security sessions at the OWASP summit. -- Added anti-debugging bypass section for iOS. -- Added SQL injection & XML injection samples and improved mitigation documentation. -- Added Needle documentation for iOS. -- Added fragment injection documentation. -- Updated IPA installation process guidance. -- Added XSS sample for Android. -- Added improved documentation for certificate installation on Android devices. -- Updated Frida & Fridump related documentation. -- Added sections about in-memory data analysis in iOS. -- Updated software development and related supporting documentation. -- Updated (anti) reverse-engineering sections for Android and iOS. -- Updated data storage chapters given newer tooling. -- Merged SDLC and security testing chapters. -- Updated cryptography and key-management testing sections for both Android and iOS (up to Android Nougat/iOS 11). -- Updated general overview chapters for Android and iOS. -- Updated Android and iOS IPC testing. -- Added missing overviews, references, etc. to various sections such as 0x6i. -- Updated local authentication chapters and the authentication & session management chapters. -- Updated test cases for sensitive data in memory. -- Added code quality sections. - -## v1.0 - 15 Jun 2018 (First release) + diff --git a/Document/Images/Chapters/0x03/mstg-detailed-summary.png b/Document/Images/Chapters/0x03/mstg-detailed-summary.png deleted file mode 100644 index ae14ce3721..0000000000 Binary files a/Document/Images/Chapters/0x03/mstg-detailed-summary.png and /dev/null differ diff --git a/Document/Images/Chapters/0x03/mstg-preparation.png b/Document/Images/Chapters/0x03/mstg-preparation.png deleted file mode 100644 index 60319a5dc8..0000000000 Binary files a/Document/Images/Chapters/0x03/mstg-preparation.png and /dev/null differ diff --git a/Document/Images/Chapters/0x03/mstg-spiderchart.png b/Document/Images/Chapters/0x03/mstg-spiderchart.png deleted file mode 100644 index 64ccbd9dca..0000000000 Binary files a/Document/Images/Chapters/0x03/mstg-spiderchart.png and /dev/null differ diff --git a/Document/Images/Chapters/0x03/mstg-test-cases.png b/Document/Images/Chapters/0x03/mstg-test-cases.png deleted file mode 100644 index 6818fb8e53..0000000000 Binary files a/Document/Images/Chapters/0x03/mstg-test-cases.png and /dev/null differ diff --git a/Document/Images/Chapters/0x03/owasp-mobile-overview.jpg b/Document/Images/Chapters/0x03/owasp-mobile-overview.jpg deleted file mode 100644 index 614075caee..0000000000 Binary files a/Document/Images/Chapters/0x03/owasp-mobile-overview.jpg and /dev/null differ diff --git a/Document/Images/Chapters/0x03/owasp-mobile-overview.png b/Document/Images/Chapters/0x03/owasp-mobile-overview.png new file mode 100644 index 0000000000..012659626c Binary files /dev/null and b/Document/Images/Chapters/0x03/owasp-mobile-overview.png differ diff --git a/Document/Images/OWASP_logo.png b/Document/Images/OWASP_logo.png deleted file mode 100644 index 8a02b6263f..0000000000 Binary files a/Document/Images/OWASP_logo.png and /dev/null differ diff --git a/Document/Images/OWASP_logo_white.png b/Document/Images/OWASP_logo_white.png index f70ee08323..585e21804c 100644 Binary files a/Document/Images/OWASP_logo_white.png and b/Document/Images/OWASP_logo_white.png differ diff --git a/Document/Images/owasp_mas_header.png b/Document/Images/owasp_mas_header.png new file mode 100644 index 0000000000..7f644b6409 Binary files /dev/null and b/Document/Images/owasp_mas_header.png differ diff --git a/Document/SUMMARY.md b/Document/SUMMARY.md index 5b347765de..a82c9fd09b 100644 --- a/Document/SUMMARY.md +++ b/Document/SUMMARY.md @@ -1,15 +1,14 @@ # Summary -- [Changelog](CHANGELOG.md) - [Frontispiece](0x02a-Frontispiece.md) - [OWASP MASVS and MASTG Adoption](0x02b-MASVS-MASTG-Adoption.md) - [Acknowledgments](0x02c-Acknowledgements.md) ## Overview -- [Introduction to the Mobile Security Testing Guide](0x03-Overview.md) -- [Mobile App Taxonomy](0x04a-Mobile-App-Taxonomy.md) -- [Mobile App Security Testing](0x04b-Mobile-App-Security-Testing.md) +- [Introduction to the OWASP Mobile Application Security Project](0x03-Overview.md) +- [Mobile Application Taxonomy](0x04a-Mobile-App-Taxonomy.md) +- [Mobile Application Security Testing](0x04b-Mobile-App-Security-Testing.md) ## General Mobile App Testing Guide diff --git a/OWASP_logo.png b/OWASP_logo.png new file mode 100644 index 0000000000..b0af38b273 Binary files /dev/null and b/OWASP_logo.png differ diff --git a/PULL_REQUEST_TEMPLATE.md b/PULL_REQUEST_TEMPLATE.md index 1e7e554023..e58361bcdd 100644 --- a/PULL_REQUEST_TEMPLATE.md +++ b/PULL_REQUEST_TEMPLATE.md @@ -1,4 +1,4 @@ -Thank you for submitting a Pull Request to the Mobile Security Testing Guide. Please make sure that: +Thank you for submitting a Pull Request to the OWASP MASTG. Please make sure that: - [ ] Your contribution is written in the 2nd person (e.g. you) - [ ] Your contribution is written in an active present form for as much as possible. diff --git a/README.md b/README.md index 38c9b3aba5..af70268f93 100644 --- a/README.md +++ b/README.md @@ -96,9 +96,9 @@ Before you start contributing, please check our pages ["How Can You Contribute?" - [Frontispiece](https://mas.owasp.org/MASTG/0x02a-Frontispiece) - [OWASP MASVS and MASTG Adoption](https://mas.owasp.org/MASTG/0x02b-MASVS-MASTG-Adoption) - [Acknowledgements](https://mas.owasp.org/MASTG/0x02c-Acknowledgements) -- [Introduction to the Mobile Security Testing Guide](https://mas.owasp.org/MASTG/0x03-Overview) -- [Mobile App Taxonomy](https://mas.owasp.org/MASTG/General/0x04a-Mobile-App-Taxonomy) -- [Mobile App Security Testing](https://mas.owasp.org/MASTG/General/0x04b-Mobile-App-Security-Testing) +- [Introduction to the OWASP Mobile Application Security Project](https://mas.owasp.org/MASTG/0x03-Overview) +- [Mobile Application Taxonomy](https://mas.owasp.org/MASTG/General/0x04a-Mobile-App-Taxonomy) +- [Mobile Application Security Testing](https://mas.owasp.org/MASTG/General/0x04b-Mobile-App-Security-Testing) ### General Testing Guide diff --git a/docs/contributing/5_Style_Guide.md b/docs/contributing/5_Style_Guide.md index b1b5bf6a9f..394dc4b4c8 100644 --- a/docs/contributing/5_Style_Guide.md +++ b/docs/contributing/5_Style_Guide.md @@ -39,7 +39,7 @@ There is one exception: We are still using "man in the middle", as it is simply ### Timeliness of Content -Keeping accurate and timely content establishes the 'Mobile Security Testing Guide' as a credible and trustworthy source of information. +Keeping accurate and timely content establishes the OWASP MAS deliverables as a credible and trustworthy source of information. When using statistical data on your page, ensure that the information is current and up-to-date and is accompanied by the source from which it was derived, along with the date the data was compiled. diff --git a/docs/news.md b/docs/news.md index 91af6b8305..a70f150355 100644 --- a/docs/news.md +++ b/docs/news.md @@ -106,7 +106,7 @@ Sven, Jeroen and Carlos ## March 17th, 2020: International release of MASVS 1.2 -A new version of the OWASP Mobile Application Security Standard (MASVS) was released! The MASVS establishes baseline security requirements for mobile apps and summarizes them in one standard. With this new release we achieved a significant alignment and coverage with existing mobile security documents from ENISA, older NIST documents, OWASP Mobile top 10, and others. The new version 1.2 is available in Github Releases: . For more details please look into our Changelog for Version 1.2 and Version 1.2-RC . +A new version of the OWASP Mobile Application Security Standard (MASVS) was released! The MASVS establishes baseline security requirements for mobile apps and summarizes them in one standard. With this new release we achieved a significant alignment and coverage with existing mobile security documents from ENISA, older NIST documents, OWASP Mobile top 10, and others. The new version 1.2 is available in Github Releases: . For more details please look into our Release Notes for Version 1.2 and Version 1.2-RC . Thanks to the great support of our community we have now 9 different languages available in total for the MASVS and would like to thank all of our translators for their great work and support throughout: @@ -212,7 +212,7 @@ Now that the document generation process for the MSTG has been optimized enough ## September 16th, 2018: MSTG 1.0.1 released -The Mobile Security Testing Guide version 1.0.1 has been released using our automated release system (based on tagging). See the CHANGELOG.md for all the changes. We now have added pdf support and improved our .docx quiet a lot. We will further improve the release process for the pdf and epubs after milestone 1.1.0. +The Mobile Security Testing Guide version 1.0.1 has been released using our automated release system (based on tagging). See the [Release Notes](https://github.com/OWASP/owasp-mastg/releases/tag/1.0.1) for all the changes. We now have added pdf support and improved our .docx quiet a lot. We will further improve the release process for the pdf and epubs after milestone 1.1.0. ## September 1st, 2018: Mobile Security Testing Guide mentioned in NIST SP-163r1 diff --git a/tools/docker/first_page.tex b/tools/docker/first_page.tex index 8df8a5b613..d3cfceca5c 100644 --- a/tools/docker/first_page.tex +++ b/tools/docker/first_page.tex @@ -1,6 +1,24 @@ \thispagestyle{empty} % remove page numbers -OWASP Mobile Security Testing Guide +\textbf{OWASP Mobile Application Security Testing Guide (MASTG)} +Version $version$ released \today \\ -Version $version$ \today +Release Notes: \url{https://github.com/OWASP/owasp-mastg/releases/tag/$version$} + +Online version available at \url{https://mas.owasp.org/MASTG/0x01-Foreword} + +The OWASP MASTG is part of the OWASP Mobile Application Security (MAS) Project. \\ +\url{https://mas.owasp.org} \\ \\ + +Copyright Ā© The OWASP Foundation. \\ + +License: Creative Commons Attribution-ShareAlike 4.0 International \\ +\url{https://creativecommons.org/licenses/by-sa/4.0/} + +For any reuse or distribution, you must make clear to others the license terms of this work.\\ + +ISBN: 978-1-257-96636-3 \\ \\ + + +\emph{Cover design by Carlos Holguera} \ No newline at end of file diff --git a/tools/docker/pandoc_makedocs.sh b/tools/docker/pandoc_makedocs.sh index 4494e9d57e..c07a8b9f11 100755 --- a/tools/docker/pandoc_makedocs.sh +++ b/tools/docker/pandoc_makedocs.sh @@ -34,7 +34,7 @@ docker run --rm --entrypoint '/bin/sh' --volume `pwd`:/pandoc ${IMG}:${TAG} -c ' PANDOC=${PANDOC:-${PANDOCKER}} METADATA="build/metadata.md" -CHAPTERS="build/0x*.md build/CHANGELOG.md" +CHAPTERS="build/0x*.md" OUTPUT_BASE_NAME="OWASP_MASTG-${VERSION}" [ ! -z "${VERBOSE}" ] && echo "Create PDF" diff --git a/tools/scripts/excel_styles_and_validation.py b/tools/scripts/excel_styles_and_validation.py index 0f01302907..ce21815bfb 100644 --- a/tools/scripts/excel_styles_and_validation.py +++ b/tools/scripts/excel_styles_and_validation.py @@ -90,16 +90,16 @@ def load_styles(wb): red_fill = PatternFill(bgColor="FFC7CE") dxf = DifferentialStyle(font=red_text, fill=red_fill, alignment=align_center) rule_fail = Rule(type="containsText", operator="containsText", text="Fail", dxf=dxf) -rule_fail.formula = ['NOT(ISERROR(SEARCH("Fail",J11)))'] +rule_fail.formula = ['NOT(ISERROR(SEARCH("Fail",K11)))'] green_text = Font(color="38761D") green_fill = PatternFill(bgColor="B6D7A8") dxf = DifferentialStyle(font=green_text, fill=green_fill, alignment=align_center) rule_pass = Rule(type="containsText", operator="containsText", text="Pass", dxf=dxf) -rule_pass.formula = ['NOT(ISERROR(SEARCH("Pass",J11)))'] +rule_pass.formula = ['NOT(ISERROR(SEARCH("Pass",K11)))'] gray_text = Font(color="666666") gray_fill = PatternFill(bgColor="CCCCCC") dxf = DifferentialStyle(font=gray_text, fill=gray_fill, alignment=align_center) rule_na = Rule(type="containsText", operator="containsText", text="N/A", dxf=dxf) -rule_na.formula = ['NOT(ISERROR(SEARCH("N/A",J11)))'] +rule_na.formula = ['NOT(ISERROR(SEARCH("N/A",K11)))'] diff --git a/tools/scripts/gen_all_excel.sh b/tools/scripts/gen_all_excel.sh index 3666ebdaff..cbbc6a8405 100755 --- a/tools/scripts/gen_all_excel.sh +++ b/tools/scripts/gen_all_excel.sh @@ -4,5 +4,5 @@ LanguageArray=( $(cd owasp-masvs && ls -1 | grep Document | sed -r 's/Document-? for lang in ${LanguageArray[*]}; do cd owasp-masvs/tools && python3 ./export.py -f yaml -l $lang > masvs_$lang.yaml && cd - python3 parse_html.py -m owasp-masvs/tools/masvs_$lang.yaml -i generated/html -o masvs_full_$lang.yaml - python3 yaml_to_excel.py -m masvs_full_$lang.yaml -l $lang -o Mobile_App_Security_Checklist_$lang.xlsx --mstgversion $1 --mstgcommit $2 --masvsversion $3 --masvscommit $4 + python3 yaml_to_excel.py -m masvs_full_$lang.yaml -l $lang -o Mobile_App_Security_Checklist_$lang.xlsx --mastgversion $1 --mastgcommit $2 --masvsversion $3 --masvscommit $4 done diff --git a/tools/scripts/testcase_diff.py b/tools/scripts/testcase_diff.py new file mode 100644 index 0000000000..09b2b12f56 --- /dev/null +++ b/tools/scripts/testcase_diff.py @@ -0,0 +1,46 @@ +import yaml + +def main(): + import argparse + + parser = argparse.ArgumentParser(description="Diff the MASTG test cases covered.") + parser.add_argument("-o", "--old", required=True) + parser.add_argument("-n", "--new", required=True) + + args = parser.parse_args() + + MASVS_OLD = yaml.safe_load(open(args.old)) + MASVS_NEW = yaml.safe_load(open(args.new)) + + updated = 0 + added = 0 + removed = 0 + + print("OWASP MAS Checklists Changes") + + for mstg_id, req in MASVS_NEW.items(): + old_links = MASVS_OLD[mstg_id].get("links") + new_links = req.get("links") + + if old_links and new_links: + diff = list(set(new_links) - set(old_links)) + updated += 1 + if diff: + print(f"- [UPDATED] {mstg_id}:") + for link in diff: + print(f" - {link}") + print("\n") + elif old_links is None and new_links: + added += 1 + print(f"- [ADDED] {mstg_id}:") + for link in new_links: + print(f" - {link}") + print("\n") + elif old_links and new_links is None: + removed += 1 + print(f"- [REMOVED] {mstg_id}\n") + + print(f"\nSUMMARY: removed ({removed}) added ({added}) updated ({updated})") + +if __name__ == "__main__": + main() \ No newline at end of file diff --git a/tools/scripts/yaml_to_excel.py b/tools/scripts/yaml_to_excel.py index 0bd4aeae60..cbe2e78af9 100644 --- a/tools/scripts/yaml_to_excel.py +++ b/tools/scripts/yaml_to_excel.py @@ -47,8 +47,8 @@ MASVS = None LANG = "" -MSTGVERSION = "" -MSTGCOMMIT = "" +MASTGVERSION = "" +MASTGCOMMIT = "" MASVSVERSION = "" MASVSCOMMIT = "" TEST_CASE_ALIAS = "Test Case" @@ -63,9 +63,10 @@ {"col": "E", "position": 5, "name": "L1", "width": 5, "style": "gray_header"}, {"col": "F", "position": 6, "name": "L2", "width": 5, "style": "gray_header"}, {"col": "G", "position": 7, "name": "R", "width": 5, "style": "gray_header"}, - {"col": "H", "position": 8, "name": "Android", "width": 10, "style": "gray_header"}, - {"col": "I", "position": 9, "name": "iOS", "width": 10, "style": "gray_header"}, - {"col": "J", "position": 10, "name": "Status", "width": 10, "style": "gray_header"}, + {"col": "H", "position": 8, "name": "Common", "width": 10, "style": "gray_header"}, + {"col": "I", "position": 9, "name": "Android", "width": 10, "style": "gray_header"}, + {"col": "J", "position": 10, "name": "iOS", "width": 10, "style": "gray_header"}, + {"col": "K", "position": 11, "name": "Status", "width": 10, "style": "gray_header"}, ] } @@ -89,7 +90,7 @@ def write_header(ws): ws["D2"].value = "Mobile Application Security Verification Standard" ws["D2"].style = "big_title" - ws["D3"].value = f'=HYPERLINK("https://github.com/OWASP/owasp-mastg/releases/tag/{MSTGVERSION}", "OWASP MASTG {MSTGVERSION} (commit: {MSTGCOMMIT})")' + ws["D3"].value = f'=HYPERLINK("https://github.com/OWASP/owasp-mastg/releases/tag/{MASTGVERSION}", "OWASP MASTG {MASTGVERSION} (commit: {MASTGCOMMIT})")' ws["D3"].font = Font(name=excel_styles_and_validation.FONT, color="00C0C0C0") ws["D4"].value = f'=HYPERLINK("https://github.com/OWASP/owasp-masvs/releases/tag/{MASVSVERSION}", "OWASP MASVS {MASVSVERSION} (commit: {MASVSCOMMIT})")' ws["D4"].font = Font(name=excel_styles_and_validation.FONT, color="00C0C0C0") @@ -133,7 +134,7 @@ def create_security_requirements_sheet(wb): write_header(ws) set_columns_width(ws) - status_cells = 'J11:J400' + status_cells = 'K11:K400' ws.conditional_formatting.add(status_cells, excel_styles_and_validation.rule_fail) ws.conditional_formatting.add(status_cells, excel_styles_and_validation.rule_pass) ws.conditional_formatting.add(status_cells, excel_styles_and_validation.rule_na) @@ -145,9 +146,10 @@ def create_security_requirements_sheet(wb): col_l1 = 5 col_l2 = 6 col_r = 7 - col_link_android = 8 - col_link_ios = 9 - col_status = 10 + col_link_common = 8 + col_link_android = 9 + col_link_ios = 10 + col_status = 11 for mstg_id, req in MASVS.items(): req_id = req["id"].split(".") @@ -187,35 +189,28 @@ def create_security_requirements_sheet(wb): ws.cell(row=row, column=col_l2).style = "green" if req["R"]: ws.cell(row=row, column=col_r).style = "orange" + + ws.cell(row=row, column=col_link_common).value = "N/A" + ws.cell(row=row, column=col_link_common).style = "gray_header" + ws.cell(row=row, column=col_link_android).value = "N/A" + ws.cell(row=row, column=col_link_android).style = "gray_header" + + ws.cell(row=row, column=col_link_ios).value = "N/A" + ws.cell(row=row, column=col_link_ios).style = "gray_header" + if req.get("links"): - # We only get the first link because there should be actually only one per platform. link_common = get_link_for(req["links"], "0x04") link_android = get_link_for(req["links"], "0x05") link_ios = get_link_for(req["links"], "0x06") + if link_common: + write_testcase(ws, row, col_link_common, link_common) if link_android: write_testcase(ws, row, col_link_android, link_android) - else: - ws.cell(row=row, column=col_link_android).value = "N/A" - ws.cell(row=row, column=col_link_android).style = "gray_header" - if link_ios: write_testcase(ws, row, col_link_ios, link_ios) - else: - ws.cell(row=row, column=col_link_ios).value = "N/A" - ws.cell(row=row, column=col_link_ios).style = "gray_header" - - # If 0x04 link exists, and a cell is None or "N/A", then write the link as common test case. - if link_common: - if ws.cell(row=row, column=col_link_android).value is None \ - or ws.cell(row=row, column=col_link_android).value == "N/A": - write_testcase(ws, row, col_link_android, link_common) - if ws.cell(row=row, column=col_link_ios).value is None \ - or ws.cell(row=row, column=col_link_ios).value == "N/A": - write_testcase(ws, row, col_link_ios, link_common) - ws.row_dimensions[row].height = 55 # points status_cell = ws.cell(row=row, column=col_status).coordinate @@ -244,7 +239,7 @@ def create_about_sheet(wb): ws.cell(row=row, column=first_col).style = "text" row = row + 2 - url = "https://owasp.org/www-project-mobile-security-testing-guide/" + url = "https://owasp.org/mas/" ws.cell(row=row, column=first_col).value = f'=HYPERLINK("{url}", "{url}")' row = row + 2 @@ -254,7 +249,7 @@ def create_about_sheet(wb): ws.cell(row=row, column=first_col).style = "text" row = row + 2 - url = "https://github.com/OWASP/owasp-mastg/" + url = "https://mas.owasp.org/MASTG/0x01-Foreword/" ws.cell(row=row, column=first_col).value = f'=HYPERLINK("{url}", "{url}")' row = row + 2 @@ -264,7 +259,7 @@ def create_about_sheet(wb): ws.cell(row=row, column=first_col).style = "text" row = row + 2 - url = "https://github.com/OWASP/owasp-masvs/" + url = "https://mas.owasp.org/MASVS/0x01-Foreword/" ws.cell(row=row, column=first_col).value = f'=HYPERLINK("{url}", "{url}")' row = row + 2 @@ -308,15 +303,15 @@ def generate_spreadsheet(output_file): def main(): - global MASVS, LANG, MSTGVERSION, MSTGCOMMIT, MASVSVERSION, MASVSCOMMIT + global MASVS, LANG, MASTGVERSION, MASTGCOMMIT, MASVSVERSION, MASVSCOMMIT import argparse parser = argparse.ArgumentParser(description="Export the MASVS requirements as Excel. Default language is en.") parser.add_argument("-m", "--masvs", required=True) parser.add_argument("-l", "--lang", required=True) parser.add_argument("-o", "--outputfile", required=True) - parser.add_argument("-v1", "--mstgversion", required=True) - parser.add_argument("-c1", "--mstgcommit", required=True) + parser.add_argument("-v1", "--mastgversion", required=True) + parser.add_argument("-c1", "--mastgcommit", required=True) parser.add_argument("-v2", "--masvsversion", required=True) parser.add_argument("-c2", "--masvscommit", required=True) @@ -325,12 +320,12 @@ def main(): # set global vars MASVS = yaml.safe_load(open(args.masvs)) LANG = args.lang - MSTGVERSION = args.mstgversion - MSTGCOMMIT = args.mstgcommit + MASTGVERSION = args.mastgversion + MASTGCOMMIT = args.mastgcommit MASVSVERSION = args.masvsversion MASVSCOMMIT = args.masvscommit - print(f"Generating {LANG.upper()} Checklist for MASTG {MSTGVERSION} ({MSTGCOMMIT}) and MASVS {MASVSVERSION} ({MASVSCOMMIT})") + print(f"Generating {LANG.upper()} Checklist for MASTG {MASTGVERSION} ({MASTGCOMMIT}) and MASVS {MASVSVERSION} ({MASVSCOMMIT})") generate_spreadsheet(args.outputfile)