OWASP_MASTG.pdf

MASTG Mobile Application Security Testing Guide Version v1.7.0 Sven Schleier Carlos Holguera Bernhard Mueller Jeroen Willemsen OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 released October 30, 2023 Release Notes: https://github.com/OWASP/owasp-mastg/releases/tag/v1.7.0 Online version available at https://github.com/OWASP/owasp-mastg/releases/t ag/v1.7.0 The OWASP MASTG, available online at https://mas.owasp.org/MASTG, is part of the OWASP Mobile Application Security (MAS) Project and is based on the OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 https://mas.owasp.org Copyright © The OWASP Foundation OWASP Mobile Application Security Testing Guide v1.7.0 This work is licensed under Creative Commons Attribution-ShareAlike 4.0 International. For any reuse or distribution, you must make clear to others the license terms of this work. OWASP ® is a registered trademark of the OWASP Foundation, Inc. ISBN: 978-1-257-96636-3 Cover design by Carlos Holguera 3 OWASP Mobile Application Security Testing Guide v1.7.0 Contents Foreword 12 Frontispiece 14 About the OWASP MASTG..................................... 14 Authors............................................ 14 Co-Authors........................................... 15 Changelog........................................... 16 Disclaimer........................................... 16 Copyright and License...................................... 16 OWASP MASVS and MASTG Adoption 17 Mobile Platform Providers..................................... 17 Certification Institutions..................................... 17 Standardization Institutions.................................... 18 Governmental Institutions.................................... 19 Educational Institutions..................................... 19 Application in Scientific Research................................. 19 Books............................................. 19 Industry Case Studies...................................... 20 Acknowledgments 21 Contributors.......................................... 21 MAS Advocates........................................ 21 Our MAS Advocates....................................... 22 Introduction to the OWASP Mobile Application Security Project 25 Key Areas in Mobile Application Security.............................. 25 Navigating the OWASP MASTG.................................. 27 Mobile Application Taxonomy 28 Native App........................................... 28 Web App............................................ 28 Hybrid App........................................... 29 Progressive Web App...................................... 29 What’s Covered in the Mobile Testing Guide............................. 29 Mobile Application Security Testing 30 Principles of Testing....................................... 30 Security Testing and the SDLC................................... 35 References........................................... 41 Mobile App Tampering and Reverse Engineering 42 Why You Need It........................................ 42 Basic Tampering Techniques................................... 43 Static and Dynamic Binary Analysis................................ 43 Advanced Techniques...................................... 47 References........................................... 49 Mobile App Authentication Architectures 50 General Assumptions...................................... 50 General Guidelines on Testing Authentication............................ 51 Stateful vs. Stateless Authentication................................ 51 OAuth 2.0........................................... 53 User Logout.......................................... 55 Supplementary Authentication.................................. 56 Two-factor Authentication.................................... 56 Login Activity and Device Blocking................................. 58 4 OWASP Mobile Application Security Testing Guide v1.7.0 Mobile App Network Communication 59 Secure Connections....................................... 59 Server Trust Evaluation..................................... 59 Verifying the TLS Settings.................................... 61 Intercepting HTTP(S) Traffic.................................... 63 Intercepting Non-HTTP Traffic................................... 64 Intercepting Traffic from the App Process.............................. 64 Intercepting Traffic on the Network Layer.............................. 64 Mobile App Cryptography 71 Key Concepts.......................................... 71 Identifying Insecure and/or Deprecated Cryptographic Algorithms.................... 71 Common Configuration Issues................................... 72 Cryptographic APIs on Android and iOS............................... 76 Cryptographic Policy....................................... 76 Cryptography Regulations.................................... 76 Mobile App Code Quality 77 Injection Flaws......................................... 77 Cross-Site Scripting Flaws.................................... 79 Memory Corruption Bugs..................................... 80 Binary Protection Mechanisms................................... 82 Mobile App User Privacy Protection 84 Overview........................................... 84 Testing for Privacy in Mobile Apps................................. 86 Testing User Education on Data Privacy on the App Marketplace.................... 87 Testing User Education on Security Best Practices.......................... 87 Android Platform Overview 89 Android Architecture....................................... 89 Android Security: Defense-in-Depth Approach............................ 92 Android Application Structure................................... 95 Android Application Publishing.................................. 104 Android Security Testing 108 Android Testing Setup...................................... 108 Installing Apps......................................... 111 Obtaining and Extracting Apps.................................. 111 Exploring the App Package.................................... 113 Symbolic Execution....................................... 115 Patching............................................ 122 Retrieving Strings........................................ 124 Accessing App Data Directories.................................. 125 Dynamic Analysis on Non-Rooted Devices.............................. 127 Static Analysis on Android.................................... 127 Bypassing Certificate Pinning................................... 127 Setting Up an Interception Proxy.................................. 129 Method Hooking........................................ 135 Getting Loaded Classes and Methods Dynamically.......................... 140 Library Injection........................................ 140 Debugging........................................... 142 JNI Tracing........................................... 152 Monitoring System Logs..................................... 152 Runtime Reverse Engineering................................... 153 Host-Device Data Transfer.................................... 155 Decompiling Java Code...................................... 156 Process Exploration....................................... 159 Repackaging & Re-Signing.................................... 163 Reviewing Decompiled Java Code................................. 164 5 OWASP Mobile Application Security Testing Guide v1.7.0 Get Open Connections...................................... 165 Get Loaded Native Libraries.................................... 166 Accessing the Device Shell.................................... 166 Basic Network Monitoring/Sniffing................................. 168 Reviewing Disassembled Native Code............................... 171 Disassembling Native Code.................................... 174 Execution Tracing........................................ 178 Information Gathering - API Usage................................. 179 Retrieving Cross References................................... 180 Method Tracing......................................... 180 Get Open Files......................................... 180 Disassembling Code to Smali................................... 181 Native Code Tracing....................................... 181 Information Gathering - Network Communication........................... 183 Sandbox Inspection....................................... 184 Automated Static Analysis.................................... 184 Listing Installed Apps...................................... 184 Dynamic Analysis on Android................................... 185 Taint Analysis.......................................... 185 Waiting for the Debugger..................................... 186 Emulation-based Analysis.................................... 188 Reverse Engineering Android Apps................................. 189 Repackaging Apps........................................ 189 Android Data Storage 190 Overview........................................... 190 Determining Whether Sensitive Data Is Shared with Third Parties via Embedded Services.......... 203 Determining Whether Sensitive Data Is Shared with Third Parties via Notifications............. 203 Testing Backups for Sensitive Data................................. 204 Testing Local Storage for Sensitive Data.............................. 206 Testing Memory for Sensitive Data................................. 208 Determining Whether the Keyboard Cache Is Disabled for Text Input Fields................ 214 Testing Logs for Sensitive Data.................................. 215 Testing the Device-Access-Security Policy.............................. 217 Android Cryptographic APIs 219 Overview........................................... 219 Testing Symmetric Cryptography................................. 223 Testing the Configuration of Cryptographic Standard Algorithms.................... 224 Testing Random Number Generation................................ 225 Testing the Purposes of Keys................................... 226 Android Local Authentication 227 Overview........................................... 227 Testing Biometric Authentication.................................. 232 Testing Confirm Credentials.................................... 233 Android Network Communication 234 Overview........................................... 234 Testing Custom Certificate Stores and Certificate Pinning....................... 235 Testing Endpoint Identify Verification................................ 239 Testing the Security Provider................................... 242 Testing Data Encryption on the Network............................... 242 Testing the TLS Settings..................................... 243 Android Platform APIs 245 Overview........................................... 245 Testing WebView Protocol Handlers................................. 258 Testing for Overlay Attacks.................................... 259 Testing WebViews Cleanup.................................... 260 6 OWASP Mobile Application Security Testing Guide v1.7.0 Testing for App Permissions.................................... 261 Checking for Sensitive Data Disclosure Through the User Interface................... 265 Finding Sensitive Information in Auto-Generated Screenshots...................... 265 Testing for Vulnerable Implementation of PendingIntent........................ 267 Testing JavaScript Execution in WebViews.............................. 268 Testing for Sensitive Functionality Exposure Through IPC........................ 269 Determining Whether Sensitive Stored Data Has Been Exposed via IPC Mechanisms............ 276 Testing Deep Links....................................... 280 Testing for Java Objects Exposed Through WebViews......................... 285 Android Code Quality and Build Settings 287 Overview........................................... 287 Make Sure That Free Security Features Are Activated......................... 289 Testing for Injection Flaws.................................... 290 Testing Local Storage for Input Validation.............................. 291 Memory Corruption Bugs..................................... 292 Testing Object Persistence.................................... 293 Testing Implicit Intents...................................... 295 Testing Enforced Updating.................................... 297 Checking for Weaknesses in Third Party Libraries........................... 298 Testing for URL Loading in WebViews................................ 299 Android Anti-Reversing Defenses 301 Overview........................................... 301 Testing whether the App is Debuggable............................... 317 Testing Reverse Engineering Tools Detection............................. 318 Testing Root Detection...................................... 319 Testing File Integrity Checks................................... 320 Testing for Debugging Symbols.................................. 321 Testing for Debugging Code and Verbose Error Logging........................ 321 Testing Anti-Debugging Detection................................. 322 Testing Runtime Integrity Checks................................. 323 Testing Obfuscation....................................... 324 Testing Emulator Detection.................................... 325 Making Sure that the App is Properly Signed............................. 325 iOS Platform Overview 327 iOS Security Architecture..................................... 327 Software Development on iOS................................... 331 Apps on iOS.......................................... 331 iOS Security Testing 334 iOS Testing Setup........................................ 334 Dynamic Analysis on Non-Jailbroken Devices............................. 337 Method Hooking........................................ 339 Getting Loaded Classes and Methods dynamically.......................... 340 Sandbox Inspection....................................... 341 Information Gathering - API Usage................................. 341 Emulation-based Analysis.................................... 341 Monitoring System Logs..................................... 345 Repackaging Apps........................................ 346 Library Injection........................................ 347 Process Exploration....................................... 347 Waiting for the debugger..................................... 351 Get Loaded Native Libraries.................................... 351 Automated Static Analysis.................................... 352 Repackaging and Re-Signing................................... 352 Decompiling Native Code..................................... 353 Information Gathering - Network Communication........................... 353 Method Tracing......................................... 354 7 OWASP Mobile Application Security Testing Guide v1.7.0 Runtime Reverse Engineering................................... 354 Basic Network Monitoring/Sniffing................................. 356 Retrieving Strings........................................ 356 Native Code Tracing....................................... 357 Accessing App Data Directories.................................. 357 Symbolic Execution....................................... 361 Exploring the App Package.................................... 362 Accessing the Device Shell.................................... 366 Extracting Information from the Application Binary.......................... 368 Patching React Native Apps.................................... 370 Patching............................................ 371 Retrieving Cross References................................... 371 Installing Apps......................................... 371 Get Open Connections...................................... 373 Dumping KeyChain Data..................................... 373 Disassembling Native Code.................................... 375 Reviewing Decompiled Objective-C and Swift Code.......................... 377 Reviewing Disassembled Objective-C and Swift Code......................... 377 Bypassing Certificate Pinning................................... 382 Listing Installed Apps...................................... 384 Debugging........................................... 384 Get Open Files......................................... 388 Setting up an Interception Proxy.................................. 389 Static Analysis on iOS...................................... 389 Reverse Engineering iOS Apps................................... 390 Host-Device Data Transfer.................................... 390 Dynamic Analysis on iOS..................................... 392 Obtaining and Extracting Apps.................................. 392 Execution Tracing........................................ 394 Reviewing Disassembled Native Code............................... 394 iOS Data Storage 398 Overview........................................... 398 Checking Logs for Sensitive Data................................. 406 Testing Local Data Storage.................................... 407 Testing Backups for Sensitive Data................................. 410 Finding Sensitive Data in the Keyboard Cache............................ 414 Determining Whether Sensitive Data Is Shared with Third Parties.................... 415 iOS Cryptographic APIs 416 Overview........................................... 416 Verifying the Configuration of Cryptographic Standard Algorithms.................... 419 Testing Key Management..................................... 420 Testing Random Number Generation................................ 421 iOS Local Authentication 422 Overview........................................... 422 Testing Local Authentication................................... 424 iOS Network Communication 427 Overview........................................... 427 Testing the TLS Settings..................................... 430 Testing Custom Certificate Stores and Certificate Pinning....................... 431 Testing Endpoint Identity Verification................................ 432 Testing Data Encryption on the Network............................... 433 iOS Platform APIs 436 Overview........................................... 436 Testing WebView Protocol Handlers................................. 450 Testing App Extensions...................................... 454 8 OWASP Mobile Application Security Testing Guide v1.7.0 Testing Custom URL Schemes................................... 455 Checking for Sensitive Data Disclosed Through the User Interface.................... 468 Testing App Permissions..................................... 469 Determining Whether Native Methods Are Exposed Through WebViews.................. 474 Determining Whether Sensitive Data Is Exposed via IPC Mechanisms.................. 477 Testing UIPasteboard...................................... 478 Testing for Sensitive Functionality Exposure Through IPC........................ 480 Testing Auto-Generated Screenshots for Sensitive Information..................... 480 Testing UIActivity Sharing..................................... 481 Testing Universal Links...................................... 487 Testing Object Persistence.................................... 501 Memory Corruption Bugs..................................... 501 Testing Enforced Updating.................................... 502 Checking for Weaknesses in Third Party Libraries........................... 503 Testing for Debugging Code and Verbose Error Logging........................ 516 Testing Anti-Debugging Detection................................. 518 Testing Jailbreak Detection.................................... 518 Testing whether the App is Debuggable............................... 519 Testing Obfuscation....................................... 520 Testing Reverse Engineering Tools Detection............................. 520 Testing for Debugging Symbols.................................. 520 Testing Emulator Detection.................................... 521 Testing File Integrity Checks................................... 521 Making Sure that the App Is Properly Signed............................. 522 Testing Tools 524 gplaycli............................................ 524 Xposed............................................ 524 APKiD............................................. 525 JustTrustMe.......................................... 526 objection for Android...................................... 526 Drozer............................................ 527 Scrcpy............................................ 528 Android Studio......................................... 528 Frida for Android........................................ 529 Apktool............................................ 532 Termux............................................ 533 adb.............................................. 533 SSLUnpinning......................................... 533 apkx............................................. 533 RootCloak Plus......................................... 534 Angr............................................. 534 Magisk............................................ 534 FlowDroid........................................... 535 jdb.............................................. 535 APKLab............................................ 535 Busybox............................................ 535 Proguard........................................... 536 MobSF for Android........................................ 536 Bytecode Viewer........................................ 536 radare2 for Android....................................... 537 Android NDK.......................................... 541 jadx............................................. 542 nm - Android.......................................... 542 Android-SSL-TrustKiller...................................... 542 House............................................. 542 Android SDK.......................................... 543 simctl............................................. 544 lldb.............................................. 544 9 OWASP Mobile Application Security Testing Guide v1.7.0 Xcode Command Line Tools.................................... 544 class-dump-dyld........................................ 544 Frida for iOS.......................................... 544 security............................................ 546 SwiftShield........................................... 546 MachoOView.......................................... 548 Usbmuxd........................................... 548 Xcode............................................. 548 Frida-ios-dump......................................... 548 gdb.............................................. 549 radare2 for iOS......................................... 549 Frida-cycript.......................................... 549 iProxy............................................. 549 nm - iOS............................................ 549 SSL Kill Switch 2........................................ 549 ios-deploy........................................... 550 iOSbackup........................................... 550 MobSF for iOS......................................... 550 class-dump.......................................... 551 Sileo............................................. 551 Cydia............................................. 552 class-dump-z.......................................... 553 Plutil............................................. 553 otool............................................. 553 BinaryCookieReader....................................... 553 objection for iOS........................................ 553 swift-demangle......................................... 554 Keychain-Dumper........................................ 555 Grapefruit........................................... 555 Cycript............................................ 555 xcrun............................................. 558 optool............................................. 558 dsdump............................................ 558 bettercap........................................... 559 Burp Suite........................................... 559 Wireshark........................................... 560 OWASP ZAP.......................................... 560 tcpdump........................................... 560 MITM Relay.......................................... 560 Android tcpdump........................................ 560 r2frida............................................ 560 Frida............................................. 562 Frida CodeShare........................................ 564 LIEF.............................................. 564 Ghidra............................................ 565 RMS Runtime Mobile Security................................... 569 iaito............................................. 569 MobSF............................................ 570 objection........................................... 570 Reference applications 571 OVAA............................................. 571 InsecureShop.......................................... 571 AndroGoat........................................... 571 Android License Validator..................................... 571 InsecureBankv2......................................... 572 DodoVulnerableBank...................................... 572 Android UnCrackable L3..................................... 572 Android UnCrackable L1..................................... 572 10 OWASP Mobile Application Security Testing Guide v1.7.0 MASTG Hacking Playground (Kotlin)................................ 572 MASTG Hacking Playground (Java)................................. 573 Digitalbank.......................................... 573 DIVA Android.......................................... 573 DVHMA............................................ 573 Android UnCrackable L4..................................... 573 Android UnCrackable L2..................................... 574 DVIA............................................. 574 DVIA-v2............................................ 574 Suggested Reading 575 Mobile App Security....................................... 575 Reverse Engineering....................................... 575 11 OWASP Mobile Application Security Testing Guide v1.7.0 Foreword 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: https://www.github.com/OWASP/owasp-mastg/ squirrel (noun plural): Any arboreal sciurine rodent of the genus Sciurus, such as S. vulgaris (red squirrel) or S. carolinensis (grey squirrel), having a bushy tail and feeding on nuts, seeds, etc. On a beautiful summer day, a group of ~7 young men, a woman, and approximately three squirrels met in a Woburn Forest villa during the OWASP Security Summit 2017. So far, nothing unusual. But little did you know, within the next five days, they would redefine not only mobile application security, but the very fundamentals of book writing itself (ironically, the event took place near Bletchley Park, once the residence and work place of the great Alan Turing). Or maybe that’s going too far. But at least, they produced a proof-of-concept for an unusual security book. The Mobile Application Security Testing Guide (MASTG) is an open, agile, crowd-sourced effort, made of the contributions of dozens of authors and reviewers from all over the world. 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 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”. 12 OWASP Mobile Application Security Testing Guide v1.7.0 13 OWASP Mobile Application Security Testing Guide v1.7.0 Frontispiece About the OWASP MASTG The OWASP Mobile Application Security Testing Guide (MASTG), which is part of the OWASP Mobile Application Security (MAS) 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), 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. Authors Bernhard Mueller Bernhard is a cyber security specialist with a talent for hacking systems of all kinds. During more than a decade in the industry, he has published many zero-day exploits for software such as MS SQL Server, Adobe Flash Player, IBM Director, Cisco VOIP, and ModSecurity. If you can name it, he has probably broken it at least once. BlackHat USA commended his pioneering work in mobile security with a Pwnie Award for Best Research. Sven Schleier Sven is an experienced web and mobile penetration tester and assessed everything from historic Flash applications to progressive mobile apps. He is also a security engineer that supported many projects end-to-end during the SDLC to “build security in”. He was speaking at local and international meetups and conferences and is conducting hands-on workshops about web application and mobile app security. 14 OWASP Mobile Application Security Testing Guide v1.7.0 Jeroen Willemsen Jeroen is a principal security architect with a passion for mobile security and risk management. He has supported compa- nies as a security coach, a security engineer and as a full-stack developer, which makes him a jack of all trades. He loves explaining technical subjects: from security issues to programming challenges. Carlos Holguera Carlos is a mobile security research engineer who has gained many years of hands-on experience in the field of security testing for mobile apps and embedded systems such as automotive control units and IoT devices. He is passionate about reverse engineering and dynamic instrumentation of mobile apps and is continuously learning and sharing his knowledge. Co-Authors Co-authors have consistently contributed quality content and have at least 2,000 additions logged in the GitHub reposi- tory. Romuald Szkudlarek Romuald is a passionate cyber security & privacy professional with over 15 years of experience in the web, mobile, IoT and cloud domains. During his career, he has been dedicating his spare time to a variety of projects with the goal of advancing the sectors of software and security. He is teaching regularly at various institutions. He holds CISSP, CCSP, CSSLP, and CEH credentials. Jeroen Beckers Jeroen is a mobile security lead responsible for quality assurance on mobile security projects and for R&D on all things mobile. Although he started his career as a programmer, he found that it was more fun to take things apart than to put things together, and the switch to security was quickly made. Ever since his master’s thesis on Android security, Jeroen has been interested in mobile devices and their (in)security. He loves sharing his knowledge with other people, as is demonstrated by his many talks & trainings at colleges, universities, clients and conferences. Vikas Gupta Vikas is an experienced cyber security researcher, with expertise in mobile security. In his career he has worked to secure applications for various industries including fintech, banks and governments. He enjoys reverse engineering, especially obfuscated native code and cryptography. He holds masters in security and mobile computing, and an OSCP certification. He is always open to share his knowledge and exchange ideas. 15 OWASP Mobile Application Security Testing Guide v1.7.0 Changelog All our Changelogs are available online at the OWASP MASTG GitHub repository, see the Releases page: https://github.com/OWASP/owasp-mastg/releases 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] has further details: https://github.com/OWASP/owasp-mastg/blob/master/CODE_OF_CONDUCT. md 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: https://mas.owasp.org/contact If you find any inconsistencies or typos please open an issue in the OWASP MASTG Github Repo: https://github.com/OWA SP/owasp-mastg Copyright and License Copyright © The OWASP Foundation. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 Interna- tional License. For any reuse or distribution, you must make clear to others the license terms of this work. 16 OWASP Mobile Application Security Testing Guide v1.7.0 OWASP MASVS and MASTG Adoption The OWASP MASVS and MASTG are trusted by the following platform providers and standardization, governmental and educational institutions. Mobile Platform Providers Google Android Since 2021 Google has shown their support for the OWASP Mobile Security project (MASTG/MASVS) and has started providing continuous and high value feedback to the MASVS refactoring process via the App Defense Alliance (ADA) and its MASA (Mobile Application Security Assessment) program. With MASA, Google has acknowledged the importance of leveraging a globally recognized standard for mobile app se- curity to the mobile app ecosystem. Developers can work directly with an Authorized Lab partner to initiate a security assessment. Google will recognize developers who have had their applications independently validated against a set of MASVS Level 1 requirements and will showcase this on their Data safety section. We thank Google, the ADA and all its members for their support and for their excellent work on protecting the mobile app ecosystem. Certification Institutions CREST CREST is an international not-for-profit, membership body who quality assures its members and delivers professional certifications to the cyber security industry. CREST works with governments, regulators, academe, training partners, professional bodies and other stakeholders around the world. In August 2022, CREST launched the OWASP Verification Standard (OVS) Programme. CREST OVS sets new standards for application security. Underpinned by OWASP’s Application Security Verification Standard (ASVS) and Mobile Application Security Verification Standard (MASVS), CREST is leveraging the open-source community to build and maintain global standards to deliver a global web and mobile application security framework. This will provide assurance to the buying community that developers using CREST OVS accredited providers, always know that they are engaged with ethical and capable organisations with skilled and competent security testers by leveraging the OWASP ASVS and MASVS standards. CREST OVS Programme CREST OVS Accreditation Process CREST OVS Introductory Video 17 OWASP Mobile Application Security Testing Guide v1.7.0 We thank CREST for their consulation regarding the OVS programme and its support to the open-source community to build and maintain global cyber security standards. Standardization Institutions NIST (National Institute of Standards and Technology, United States) The National Institute of Standards and Technology (NIST) was founded in 1901 and is now part of the U.S. Department of Commerce. NIST is one of the nation’s oldest physical science laboratories. Congress established the agency to remove a major challenge to U.S. industrial competitiveness at the time — a second-rate measurement infrastructure that lagged behind the capabilities of the United Kingdom, Germany and other economic rivals. NIST.SP.800-163 “Vetting the Security of Mobile Applications” Revision 1, 2019 NIST.SP.800-218 “Secure Software Development Framework (SSDF) v1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities” v1.1, 2022 BSI (Bundesamt für Sicherheit in der Informationstechnik, Germany) BSI stands for “Federal Office for Information Security”, it has the goal to promote IT security in Germany and is the central IT security service provider for the federal government. Technical Guideline BSI TR-03161 Security requirements for eHealth applications v1.0, 2020 Prüfvorschrift für den Produktgutachter des „ePA-Frontend des Versicherten“ und des „E-Rezept-Frontend des Ver- sicherten v2.0, 2021 ioXt 18 OWASP Mobile Application Security Testing Guide v1.7.0 The mission of the ioXt Alliance is to build confidence in Internet of Things products through multi-stakeholder, inter- national, harmonized, and standardized security and privacy requirements, product compliance programs, and public transparency of those requirements and programs. In 2021, ioXt has extended its security principles through the Mobile Application profile, so that app developers can ensure their products are built with, and maintain, high cybersecurity standards such as the OWASP MASVS and the VPN Trust Initiative. The ioXt Mobile Application profile is a security standard that applies to any cloud connected mobile app and provides the much needed market transparency for consumer and commercial mobile app security. ioXt Base Profile v2.0 Governmental Institutions Name Document Year European Payments Council Payment Threats and Fraud Trends Report 2021 European Payments Council Mobile Initiated SEPA Credit Transfer Interoperability 2019 Implementation Guidelines, including SCT Instant (MSCT IIGs) ENISA (European Union Agency for Good Practices for Security of SMART CARS 2019 Cybersecurity) Government of India, Ministry of Electronics Adoption of Mobile AppSec Verification Standard (MASVS) 2019 & Information Technology Version 1.0 of OWASP Finish Transport and Communication Agency Assessment guideline for electronic identification services 2019 (TRAFICOM) (Draft) Gobierno de España INCIBE Ciberseguridad en Smart Toys 2019 Educational Institutions Name Document Year Leibniz Fachhochschule Hannover, Germany Sicherheitsüberprüfung von mobilen iOS Apps nach OWASP 2022 (German) University of Florida, Florida Institute for “SO{U}RCERER : Developer-Driven Security Testing Framework 2021 Cybersecurity Research, United States for Android Apps” University of Adelaide, Australia and Queen An Empirical Assessment of Global COVID-19 Contact Tracing 2021 Mary University of London, United Kingdom Applications School of Information Technology, Mapúa A Vulnerability Assessment on the Parental Control Mobile 2021 University, Philippines Applications Security: Status based on the OWASP Security Requirements Application in Scientific Research STAMBA: Security Testing for Android Mobile Banking Apps Books Hands-On Security in DevOps 19 OWASP Mobile Application Security Testing Guide v1.7.0 Industry Case Studies Case Study: NowSecure Commits to Security Standards Would you like to contribute with your case study? Connect with us! 20 OWASP Mobile Application Security Testing Guide v1.7.0 Acknowledgments Contributors All of our contributors are listed in the Contributing section of the OWASP MAS website: https://mas.owasp.org/contributing/ 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. Being an “MAS Advocate” is the highest status that companies can achieve in the project acknowledging that they’ve gone above and beyond to support the project. We will validate this status according to these categories: 1. Showing Adoption: it should be clear just from looking at the official company page that they have adopted the OWASP MASVS and MASTG. For example: Services / Products Resources (e.g. blog posts, press releases, public pentest reports) Trainings etc. 2. Providing consistent high-impact contributions: by continuously supporting with time/dedicated resources with clear/high impact for the OWASP MAS project. Content Pull Requests (e.g. adding/upgrading existing tests, tooling, maintaining code samples, etc.) Technical PR reviews Improving automation (GitHub Actions) Upgrading, extending or creating new Crackmes Moderating GitHub Discussions Providing high-value feedback to the project and for special events such as the MASVS/MASTG refactoring. etc. 3. Spreading the word and promoting the project with many presentations each year, public trainings, high social media involvement (e.g. liking, re-sharing, doing own posting specifically to promote the project). NOTE: You have to satisfy all three categories in order to qualify as an MAS Advocate. However, you do not need to fulfill each and every bullet point (they are examples). In general, you must be able to clearly show the continuity of your contributions and high impact for the project. For example, to fulfill “2.” you could demonstrate that you’ve been sending high-impact Pull Request in the initial 6 months period and intend to continue to do so. Benefits Company logo displayed in our main READMEs and main OWASP project site. Linked blog posts in the MASTG will include the company name. Special acknowledgement on each MASTG release containing the contributed PRs. Re-shares from the OWASP MAS accounts on new publications (e.g. retweets). Initial public “Thank You” and yearly after successful renewal. 21 OWASP Mobile Application Security Testing Guide v1.7.0 How to Apply If you’d like to apply please contact the project leaders by sending an email to Sven Schleier and Carlos Holguera who will validate your application. Please be sure to include sufficient evidence (usually in the form of a contribution report including URLs linking to the corresponding elements) showing what you’ve done in the 6 months period that goes inline with the three categories described above. 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 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: a 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. 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. Our MAS Advocates NowSecure 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. NowSecure as a MASVS/MASTG Adopter Services / Products: – NowSecure Debuts New OWASP MASVS Mobile Pen Tests – NowSecure Platform for Automated Mobile Security Testing Resources: – The Essential Guide to the OWASP Mobile Security Project Trainings: – Standards and Risk Assessment – OWASP MASVS & MASTG Updates – Intro to Mobile App Security 22 OWASP Mobile Application Security Testing Guide v1.7.0 NowSecure’s Contributions to the MAS Project High-impact Contributions (time/dedicated resources): Content PRs Technical Reviews for PRs Participation in GitHub Discussions A special mention goes for the contribution to the MASVS Refactoring: Significant time investment to drive the discussions and create the proposals along with the community Testability Analysis Feedback on each category proposal Statistics from internal analysis In the past, NowSecure has also contributed to the project, has sponsored it becoming a “God Mode Sponsor” and has donated the UnCrackable App for Android Level 4: Radare2 Pay. Spreading the Word: Social media involvement: continuous Twitter and LinkedIn activity (see examples) Case Study: NowSecure Commits to Security Standards Blog Posts: – Integrate security into the mobile app software development lifecycle – OWASP Mobile Security Testing Checklist Aids Compliance Presentations: – “Mobile Wanderlust”! Our journey to Version 2.0! (OWASP AppSec EU, Jun 10 2022) – Insiders Guide to Mobile AppSec with Latest OWASP MASVS (OWASP Toronto Chapter, Feb 10 2022) – Insiders Guide to Mobile AppSec with Latest OWASP MASVS (OWASP Virtual AppSec 2021, Nov 11 2021) – Insiders Guide to Mobile AppSec with OWASP MASVS (OWASP Northern Virginia Chapter, Oct 8 2021) – and more 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. 23 OWASP Mobile Application Security Testing Guide v1.7.0 24 OWASP Mobile Application Security Testing Guide v1.7.0 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. The OWASP Mobile Application Security Verification Standard (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 OWASP Mobile Application Security Testing Guide (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” 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. 25 OWASP Mobile Application Security Testing Guide v1.7.0 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. When developing mobile apps, we must take extra care when storing user data. For example, we can use appropriate key storage APIs and take advantage of hardware-backed security features when available. 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. Cryptography (MASVS-CRYPTO) 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 (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 authen- tication 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. 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 com- plicated 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. 26 OWASP Mobile Application Security Testing Guide v1.7.0 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. 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 (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. Navigating the OWASP MASTG The MASTG contains descriptions of all requirements specified in the MASVS. The MASTG contains the following main sections: 1. The General Testing Guide contains a mobile app security testing methodology and general vulnerability analy- sis techniques as they apply to mobile app security. It also contains additional technical test cases that are OS- independent, such as authentication and session management, network communications, and cryptography. 2. The Android Testing Guide covers mobile security testing for the Android platform, including security basics, security test cases, reverse engineering techniques and prevention, and tampering techniques and prevention. 3. The iOS Testing Guide covers mobile security testing for the iOS platform, including an overview of the iOS OS, security testing, reverse engineering techniques and prevention, and tampering techniques and prevention. 27 OWASP Mobile Application Security Testing Guide v1.7.0 Mobile Application Taxonomy 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. 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. 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. In a basic sense, apps are designed to run either directly on the platform for which they’re designed, on top of a smart device’s mobile browser, or using a mix of the two. Throughout the following chapter, we will define characteristics that qualify an app for its respective place in mobile app taxonomy as well as discuss differences for each variation. Native App 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), 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.). Some ambiguity exists when discussing native apps for Android as the platform provides two development kits - the Android SDK and the Android NDK. The SDK, which is based on the Java and Kotlin programming language, is the default for developing apps. The NDK (or Native Development Kit) is a C/C++ development kit used for developing binary libraries that can directly access lower level APIs (such as OpenGL). These libraries can be included in regular apps built with the SDK. Therefore, we say that Android native apps (i.e. built with the SDK) may have native code built with the NDK. The most obvious downside of native apps is that they target only one specific platform. To build the same app for both Android and iOS, one needs to maintain two independent code bases, or introduce often complex development tools to port a single code base to two platforms. The following frameworks are an example of the latter and allow you to compile a single codebase for both Android and iOS. Xamarin Google Flutter React Native 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 Mobile web apps (or simply, web apps) are websites designed to look and feel like a native app. These apps run on top of a device’s browser and are usually developed in HTML5, much like a modern web page. Launcher icons may be created to parallel the same feel of accessing a native app; however, these icons are essentially the same as a browser bookmark, simply opening the default web browser to load the referenced web page. Web apps have limited integration with the general components of the device as they run within the confines of a browser (i.e. they are “sandboxed”) and usually lack in performance compared to native apps. Since a web app typically targets multiple platforms, their UIs do not follow some of the design principles of a specific platform. The biggest advantage is reduced development and maintenance costs associated with a single code base as well as enabling developers to 28 OWASP Mobile Application Security Testing Guide v1.7.0 distribute updates without engaging the platform-specific app stores. For example, a change to the HTML file for a web app can serve as viable, cross-platform update whereas an update to a store-based app requires considerably more effort. Hybrid App 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 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: Apache Cordova Framework 7 Ionic jQuery Mobile Native Script Onsen UI Sencha Touch Progressive Web App Progressive Web Apps (PWA) load like regular web pages, but differ from usual web apps in several ways. For example it’s possible to work offline and access to mobile device hardware is possible, that traditionally is only available to native mobile apps. PWAs combine different open standards of the web offered by modern browsers to provide benefits of a rich mobile experience. A Web App Manifest, which is a simple JSON file, can be used to configure the behavior of the app after “installation”. PWAs are supported by Android and iOS, but not all hardware features are yet available. For example Push Notifications, Face ID on iPhone X or ARKit for augmented reality is not available yet on iOS. An overview of PWA and supported features on each platform can be found in a Medium article from Maximiliano Firtman. What’s Covered in the Mobile Testing Guide Throughout this guide, we will focus on apps for Android and iOS running on smartphones. These platforms are currently dominating the market and also run on other device classes including tablets, smartwatches, smart TVs, automotive infotainment units, and other embedded systems. Even if these additional device classes are out of scope, you can still apply most of the knowledge and testing techniques described in this guide with some deviance depending on the target device. Given the vast amount of mobile app frameworks available it would be impossible to cover all of them exhaustively. Therefore, we focus on native apps on each operating system. However, the same techniques are also useful when dealing with web or hybrid apps (ultimately, no matter the framework, every app is based on native components). 29 OWASP Mobile Application Security Testing Guide v1.7.0 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. Throughout the guide, we use “mobile app security testing” as a catchall phrase to refer to the evaluation of mobile app security via static and dynamic analysis. Terms such as “mobile app penetration testing” and “mobile app security review” are used somewhat inconsistently in the security industry, but these terms refer to roughly the same thing. A mobile app security test is usually part of a larger security assessment or penetration test that encompasses the client- server architecture and server-side APIs used by the mobile app. In this guide, we cover mobile app security testing in two contexts. The first is the “classical” security test completed near the end of the development life cycle. In this context, the tester accesses a nearly finished or production-ready version of the app, identifies security issues, and writes a (usually devastating) report. The other context is characterized by the implementation of requirements and the automation of security tests from the beginning of the software development life cycle onwards. The same basic requirements and test cases apply to both contexts, but the high-level method and the level of client interaction differ. Principles of Testing White-box Testing versus Black-box Testing Let’s start by defining the concepts: Black-box testing is conducted without the tester’s having any information about the app being tested. This process is sometimes called “zero-knowledge testing”. The main purpose of this test is allowing the tester to behave like a real attacker in the sense of exploring possible uses for publicly available and discoverable information. White-box testing (sometimes called “full knowledge testing”) is the total opposite of black-box testing in the sense that the tester has full knowledge of the app. The knowledge may encompass source code, documentation, and diagrams. This approach allows much faster testing than black-box testing due to its transparency and with the additional knowledge gained a tester can build much more sophisticated and granular test cases. Gray-box testing is all testing that falls in between the two aforementioned testing types: some information is provided to the tester (usually credentials only), and other information is intended to be discovered. This type of testing is an interesting compromise in the number of test cases, the cost, the speed, and the scope of testing. Gray-box testing is the most common kind of testing in the security industry. We strongly advise that you request the source code so that you can use the testing time as efficiently as possible. The tester’s code access obviously doesn’t simulate an external attack, but it simplifies the identification of vulnerabilities by allowing the tester to verify every identified anomaly or suspicious behavior at the code level. A white-box test is the way to go if the app hasn’t been tested before. Even though decompiling on Android is straightforward, the source code may be obfuscated, and de-obfuscating will be time-consuming. Time constraints are therefore another reason for the tester to have access to the source code. Vulnerability Analysis Vulnerability analysis is usually the process of looking for vulnerabilities in an app. Although this may be done manu- ally, automated scanners are usually used to identify the main vulnerabilities. Static and dynamic analysis are types of vulnerability analysis. Static versus Dynamic Analysis 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 that may help you understand techniques, strengths, weaknesses, and limitations. 30 OWASP Mobile Application Security Testing Guide v1.7.0 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. Now that we have defined static and dynamic analysis, let’s dive deeper. Static Analysis During static analysis, the mobile app’s source code is reviewed to ensure appropriate implementation of security controls. In most cases, a hybrid automatic/manual approach is used. Automatic scans catch the low-hanging fruit, and the human tester can explore the code base with specific usage contexts in mind. Manual Code Review 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 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 Automated analysis tools can be used to speed up the review process of Static Application Security Testing (SAST). They check the source code for compliance with a predefined set of rules or industry best practices, then typically display a list of findings or warnings and flags for all detected violations. Some static analysis tools run against the compiled app only, some must be fed the original source code, and some run as live-analysis plugins in the Integrated Development Environment (IDE). Although some static code analysis tools incorporate a lot of information about the rules and semantics required to analyze mobile apps, they may produce many false positives, particularly if they are not configured for the target environment. A security professional must therefore always review the results. The chapter “Testing Tools” includes a list of static analysis tools, which can be found at the end of this book. Dynamic Analysis The focus of DAST is the testing and evaluation of apps via their real-time execution. The main objective of dynamic analysis is finding security vulnerabilities or weak spots in a program while it is running. Dynamic analysis is conducted both at the mobile platform layer and against the backend services and APIs, where the mobile app’s request and response patterns can be analyzed. Dynamic analysis is usually used to check for security mechanisms that provide sufficient protection against the most prevalent types of attack, such as disclosure of data in transit, authentication and authorization issues, and server con- figuration errors. 31 OWASP Mobile Application Security Testing Guide v1.7.0 Avoiding False Positives Automated Scanning Tools 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 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: The ability to entice the logged-in user to open a malicious link in the web browser used to access the vulnerable site. The client (browser) must automatically add the session cookie or other authentication token to the request. Mobile apps don’t fulfill these requirements: even if WebViews and cookie-based session management are used, any malicious link the user clicks opens in the default browser, which has a separate cookie store. Stored Cross-Site Scripting (XSS) can be an issue if the app includes WebViews, and it may even lead to command execution if the app exports JavaScript interfaces. However, reflected Cross-Site Scripting is rarely an issue for the reason mentioned above (even though whether they should exist at all is arguable, escaping output is simply a best practice). In any case, consider exploit scenarios when you perform the risk assessment; don’t blindly trust your scanning tool’s output. 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) and the associated checklist as baseline for testing. A typical security test is structured as follows: Preparation - defining the scope of security testing, including identifying applicable security controls, the organi- zation’s testing goals, and sensitive data. More generally, preparation includes all synchronization with the client as well as legally protecting the tester (who is often a third party). Remember, attacking a system without written authorization is illegal in many parts of the world! Intelligence Gathering - analyzing the environmental and architectural context of the app to gain a general contextual understanding. Mapping the Application - based on information from the previous phases; may be complemented by automated scanning and manually exploring the app. Mapping provides a thorough understanding of the app, its entry points, the data it holds, and the main potential vulnerabilities. These vulnerabilities can then be ranked according to the damage their exploitation would cause so that the security tester can prioritize them. This phase includes the creation of test cases that may be used during test execution. Exploitation - in this phase, the security tester tries to penetrate the app by exploiting the vulnerabilities identi- fied during the previous phase. This phase is necessary for determining whether vulnerabilities are real and true positives. Reporting - in this phase, which is essential to the client, the security tester reports the vulnerabilities. This includes the exploitation process in detail, classifies the type of vulnerability, documents the risk if an attacker would be able to compromise the target and outlines which data the tester has been able to access illegitimately. Preparation The security level at which the app will be tested must be decided before testing. The security requirements should be decided at the beginning of the project. Different organizations have different security needs and resources available for investing in test activities. Although the controls in MASVS Level 1 (L1) are applicable to all mobile apps, walking through the entire checklist of L1 and Level 2 (L2) MASVS controls with technical and business stakeholders is a good way to decide on a level of test coverage. 32 OWASP Mobile Application Security Testing Guide v1.7.0 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 stake- holders. 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. Coordinating with the Client Setting up a working test environment can be a challenging task. For example, restrictions on the enterprise wireless ac- cess points and networks may impede dynamic analysis performed at client premises. Company policies may prohibit the use of rooted phones or (hardware and software) network testing tools within enterprise networks. Apps that implement root detection and other reverse engineering countermeasures may significantly increase the work required for further analysis. Security testing involves many invasive tasks, including monitoring and manipulating the mobile app’s network traffic, inspecting the app data files, and instrumenting API calls. Security controls, such as certificate pinning and root detection, may impede these tasks and dramatically slow testing down. To overcome these obstacles, you may want to request two of the app’s build variants from the development team. One variant should be a release build so that you can determine whether the implemented controls are working properly and can’t be bypassed easily. The second variant should be a debug build for which certain security controls have been deactivated. Testing two different builds is the most efficient way to cover all test cases. Depending on the scope of the engagement, this approach may not be possible. Requesting both production and debug builds for a white-box test will help you complete all test cases and clearly state the app’s security maturity. The client may prefer that black-box tests be focused on the production app and the evaluation of its security controls’ effectiveness. The scope of both types of testing should be discussed during the preparation phase. For example, whether the security controls should be adjusted should be decided before testing. Additional topics are discussed below. Identifying Sensitive Data Classifications of sensitive information differ by industry and country. In addition, organizations may take a restrictive view of sensitive data, and they may have a data classification policy that clearly defines sensitive information. 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 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 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: user authentication information (credentials, PINs, etc.) Personally Identifiable Information (PII) that can be abused for identity theft: social security numbers, credit card numbers, bank account numbers, health information 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 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. 33 OWASP Mobile Application Security Testing Guide v1.7.0 Intelligence Gathering Intelligence gathering involves the collection of information about the app’s architecture, the business use cases the app serves, and the context in which the app operates. Such information may be classified as “environmental” or “architec- tural”. Environmental Information Environmental information includes: The organization’s goals for the app. Functionality shapes users’ interaction with the app and may make some surfaces more likely than others to be targeted by attackers. The relevant industry. Different industries may have different risk profiles. Stakeholders and investors; understanding who is interested in and responsible for the app. Internal processes, workflows, and organizational structures. Organization-specific internal processes and work- flows may create opportunities for business logic vulnerabilities. Architectural Information Architectural information includes: The mobile app: How the app accesses data and manages it in-process, how it communicates with other resources and manages user sessions, and whether it detects itself running on jailbroken or rooted phones and reacts to these situations. The Operating System: The operating systems and OS versions the app runs on (including Android or iOS version restrictions), whether the app is expected to run on devices that have Mobile Device Management (MDM) controls, and relevant OS vulnerabilities. Network: Usage of secure transport protocols (e.g., TLS), usage of strong keys and cryptographic algorithms (e.g., SHA-2) to secure network traffic encryption, usage of certificate pinning to verify the endpoint, etc. Remote Services: The remote services the app consumes and whether their being compromised could compro- mise the client. Mapping the Application Once the security tester has information about the app and its context, the next step is mapping the app’s structure and content, e.g., identifying its entry points, features, and data. When penetration testing is performed in a white-box or grey-box paradigm, any documents from the interior of the project (architecture diagrams, functional specifications, code, etc.) may greatly facilitate the process. If source code is available, the use of SAST tools can reveal valuable information about vulnerabilities (e.g., SQL Injection). DAST tools may support black-box testing and automatically scan the app: whereas a tester will need hours or days, a scanner may perform the same task in a few minutes. However, it’s important to remember that automatic tools have limitations and will only find what they have been programmed to find. Therefore, human analysis may be necessary to augment results from automatic tools (intuition is often key to security testing). Threat Modeling is an important artifact: documents from the workshop usually greatly support the identification of much of the information a security tester needs (entry points, assets, vulnerabilities, severity, etc.). Testers are strongly advised to discuss the availability of such documents with the client. Threat modeling should be a key part of the software development life cycle. It usually occurs in the early phases of a project. The threat modeling guidelines defined in OWASP are generally applicable to mobile apps. Exploitation Unfortunately, time or financial constraints limit many pentests to application mapping via automated scanners (for vulnerability analysis, for example). Although vulnerabilities identified during the previous phase may be interesting, their relevance must be confirmed with respect to five axes: Damage potential - the damage that can result from exploiting the vulnerability Reproducibility - ease of reproducing the attack Exploitability - ease of executing the attack 34 OWASP Mobile Application Security Testing Guide v1.7.0 Affected users - the number of users affected by the attack Discoverability - ease of discovering the vulnerability Against all odds, some vulnerabilities may not be exploitable and may lead to minor compromises, if any. Other vulnera- bilities may seem harmless at first sight, yet be determined very dangerous under realistic test conditions. Testers who carefully go through the exploitation phase support pentesting by characterizing vulnerabilities and their effects. Reporting The security tester’s findings will be valuable to the client only if they are clearly documented. A good pentest report should include information such as, but not limited to, the following: an executive summary a description of the scope and context (e.g., targeted systems) methods used sources of information (either provided by the client or discovered during the pentest) prioritized findings (e.g., vulnerabilities that have been structured by DREAD classification) detailed findings recommendations for fixing each defect Many pentest report templates are available on the Internet: Google is your friend! Security Testing and the SDLC Although the principles of security testing haven’t fundamentally changed in recent history, software development tech- niques have changed dramatically. While the widespread adoption of Agile practices was speeding up software develop- ment, security testers had to become quicker and more agile while continuing to deliver trustworthy software. The following section is focused on this evolution and describes contemporary security testing. Security Testing during the Software Development Life Cycle Software development is not very old, after all, so the end of developing without a framework is easy to observe. We have all experienced the need for a minimal set of rules to control work as the source code grows. In the past, “Waterfall” methodologies were the most widely adopted: development proceeded by steps that had a predefined sequence. Limited to a single step, backtracking capability was a serious drawback of Waterfall methodologies. Although they have important positive features (providing structure, helping testers clarify where effort is needed, being clear and easy to understand, etc.), they also have negative ones (creating silos, being slow, specialized teams, etc.). As software development matured, competition increased and developers needed to react to market changes more quickly while creating software products with smaller budgets. The idea of less structure became popular, and smaller teams collaborated, breaking silos throughout the organization. The “Agile” concept was born (Scrum, XP, and RAD are well- known examples of Agile implementations); it enabled more autonomous teams to work together more quickly. Security wasn’t originally an integral part of software development. It was an afterthought, performed at the network level by operation teams who had to compensate for poor software security! Although unintegrated security was possible when software programs were located inside a perimeter, the concept became obsolete as new kinds of software con- sumption emerged with web, mobile, and IoT technologies. Nowadays, security must be baked inside software because compensating for vulnerabilities is often very difficult. “SDLC” will be used interchangeably with “Secure SDLC” in the following section to help you internalize the idea that security is a part of software development processes. In the same spirit, we use the name DevSecOps to emphasize the fact that security is part of DevOps. 35 OWASP Mobile Application Security Testing Guide v1.7.0 SDLC Overview General Description of SDLC 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 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 In

Document Details

Tags

Related

Full Transcript

Upgrade to continue