{"id":15002,"date":"2021-04-07T09:01:00","date_gmt":"2021-04-07T07:01:00","guid":{"rendered":"https:\/\/stage-fp.webenv.pl\/blog\/?p=15002"},"modified":"2022-11-16T12:02:48","modified_gmt":"2022-11-16T11:02:48","slug":"introduction-to-mobile-security","status":"publish","type":"post","link":"https:\/\/www.future-processing.com\/blog\/introduction-to-mobile-security\/","title":{"rendered":"Introduction to Mobile Security"},"content":{"rendered":"\n

Many applications and solutions migrate from desktop and web environments into mobile to compete for casual users who prefer to use services without even powering up their laptops. These services vary from controlling a home vacuum cleaner robot, using calory-counting applications, chatting to connect with friends, buying tickets for a bus to work, managing bank account, posting on social media\u2026 As we can see, the possibilities are limitless, but one thing is common. These applications handle user data.<\/p>\n\n\n\n

User data in any application can differ, but stolen and leaked it can cause irreversible damage. To mention a few cases, it can destroy property, someone\u2019s personal or public life, it can lead to attacks on bank accounts or blackmail.<\/p>\n\n\n\n

The responsibility for users\u2019 data falls on business owner who handles this data. Breaches and leaks can be fined under GDPR up to 20mln euro or up to 4% of the annual worldwide turnover of the preceding financial year \u2013 whichever is greater. This can be a huge blow to any company\u2019s stability. But with some effort and invested funds, companies can protect themselves and try to mitigate threats for users of their applications.<\/p>\n\n\n\n

This article was created to show where to look for guidelines about mobile security. All materials we present here are open-source documents. The first one presents threats to mobile applications. The second one is a set of requirements applications should meet to be considered secure. The final one is  a manual for people who will verify if these requirements are being met.<\/p>\n\n\n\n


Source of materials<\/h2>\n\n\n\n

To know if a mobile application is secure, we should know what can be wrong with it. There are many resources on this topic. One of the most known resources is from the Open Web Application Security Project, OWASP for short – the biggest non-profit foundation working to improve software security. This foundation, with chapters around the globe, runs various community-led projects. A part of them is dedicated to security of mobile applications. Of course, OWASP published many useful materials concerning software security for web applications, API or IoT, but our focus here is on materials regarding mobile platforms.<\/p>\n\n\n\n


OWASP Mobile Top 10<\/h2>\n\n\n\n

This OWASP list is focused on flaws in security of a mobile application itself, without going into problems which can occur on the server\u2019s side of the whole system and typical web application issues.<\/p>\n\n\n\n

OWASP built it based on real-world data that was collected, analysed, and categorised. In the list, the flaws are described by threat agents, and the list includes information on how the flaws can occur and what impact they have – both from the business and technical perspectives. There are also short summaries on how to check if an application is vulnerable to a given risk, together with mitigation and exemplary attack scenarios. All this is completed with further references and links to online resources.<\/p>\n\n\n\n


The 10 problems, or risks, mentioned, in the order of likelihood and severity, are:<\/strong><\/p>\n\n\n\n


1. Improper Platform Usage<\/h4>\n\n\n\n

This category consists of risks introduced by violating published guidelines or other conventions and common practices. Misuse of Android intents, permissions, keychain and similar introduce unexpected security vulnerabilities like Cross-Site Scripting, exposing data in iOS Keychain, etc.<\/p>\n\n\n\n


2. Insecure Data Storage<\/h4>\n\n\n\n

Protection of data stored inside the device\u2019s filesystem or sensitive information in data stores is one of the challenges which mobile developers face. Without proper protection, user data will be exposed when an attacker uses specialised tools or malware to inspect the device\u2019s memory or storage.<\/p>\n\n\n\n


3. Insecure Communication<\/h4>\n\n\n\n

Data transit in an application can be threated by malware, malicious networks, or network devices. Application development should ensure proper protection against eavesdropping by introducing appropriate encryption of transport channels which should use strong ciphers and certificates. Also, the application should avoid sending any sensitive data by alternate, less-protected channels.<\/p>\n\n\n\n


4. Insecure Authentication<\/h4>\n\n\n\n

Authentication is a mechanism of identifying users. This category brings attention to the limitations of the authentication on mobile platforms due to input form factor, device capabilities and unreliable connection. These  include  weak password policies, storing credentials or shared secrets on the device.<\/p>\n\n\n\n


5. Insufficient Cryptography<\/h4>\n\n\n\n

This includes poor key management, as even the best cryptography fails when keys are accessible or hardcoded in binaries. Another issue can be the reliance on built-in code encryption processes, usage of self-created custom encryption protocols or weak cryptography.<\/p>\n\n\n\n


6. Insecure Authorisation<\/h4>\n\n\n\n

If authentication is identifying users, then authorisation is a mechanism that determines to which functionalities\/resources they should have access to. Problems with recognising permissions of a user in a system can vary in results, from privilege escalation to insecure direct object references. Absence of checking what a user should be able to do can result in user executing functions not suitable for their designed role.<\/p>\n\n\n\n


7. Poor Client Code Quality<\/h4>\n\n\n\n

This category contains various problems with client\u2019s code, including buffer overflows and memory leaks. It is difficult for exploitation, but it can result in foreign code execution or denial of service.<\/p>\n\n\n\n


8. Code Tampering<\/h4>\n\n\n\n

Code modifications and exploitation via malicious versions of applications hosted on third-party is a common problem on mobile market. The victim is often tricked into installing malicious version of a well-known application from an unknown source.<\/p>\n\n\n\n


9. Reverse Engineering<\/h4>\n\n\n\n

The code of most mobile applications is written in languages (frameworks) with dynamic introspection at runtime, making the applications susceptible to reverse engineering. One of the possibilities to prevent this is making it hard for the attacker to understand its innerworkings by obfuscating the code of the application.<\/p>\n\n\n\n


10. Extraneous Functionality<\/h4>\n\n\n\n

These vulnerabilities are directed at backend systems but involve analysing a mobile application. Using  their knowledge about configuration, switches, left-over test code, unused variables and logs, an attacker tries to bypass security controls and hidden backend endpoints. At the same time, they gain knowledge about functionalities not visible in the user interface, passwords, and hardcoded accounts.<\/p>\n\n\n\n


Other useful OWASP projects<\/h3>\n\n\n\n

Beyond OWASP Mobile Top 10 which is directly focused on the security on mobile apps, there are other useful OWASP projects which can be helpful when developing secure mobile applications. <\/p>\n\n\n\n

These are the following:<\/p>\n\n\n\n


OWASP Top Ten <\/strong>– a project focused on web application\u2019s security issues. The issues it describes can occur not only because of various vulnerabilities, but also when some of the standards or best practices are omitted.<\/p>\n\n\n\n

The latest OWASP Top Ten list officially released in 2019 includes:<\/p>\n\n\n\n

  1. Injections<\/li>
  2. Broken Authentication<\/li>
  3. Sensitive Data Exposure<\/li>
  4. XML External Entities (XXE)<\/li>
  5. Broken Access Control<\/li>
  6. Security Misconfiguration<\/li>
  7. Cross-Site Scripting<\/li>
  8. Insecure Deserialisation<\/li>
  9. Using Components with Known Vulnerabilities<\/li>
  10. Insufficient Logging and Monitoring<\/li><\/ol>\n\n\n\n


    OWASP API Security <\/strong>\u2013 a list that covers OWASP API Top Ten 2019 vulnerabilities. This project focuses on securing one of the most invisible parts of a mobile application\u2019s ecosystem – at least from the user\u2019s perspective.<\/p>\n\n\n\n

    The list consists of:<\/p>\n\n\n\n

    1. Broken Object Level Authorisation<\/li>
    2. Broken User Authentication<\/li>
    3. Excessive Data Exposure<\/li>
    4. Lack of Resources & Rate Limiting<\/li>
    5. Broken Function Level Authorisation<\/li>
    6. Mass Assignment<\/li>
    7. Security Misconfiguration<\/li>
    8. Injection<\/li>
    9. Improper Assets Management<\/li>
    10. Insufficient Logging & Monitoring<\/li><\/ol>\n\n\n\n


      Mobile Application Security Verification Standard<\/h2>\n\n\n\n

      After getting to know what the most popular mistakes are during development, the next step should be knowing what requirements for a modern mobile app are to consider it secure.<\/p>\n\n\n\n

      The OWASP Mobile Application Security Verification Standard (MASVS) can be a great source of this information. It offers two levels of security requirements (MASVS-L1 as baseline and additional MASVS-L2 as protection for applications handling high sensitivity data) with third level (MASVS-R) which hardens applications against client-side threats with a set of reverse engineering resiliency requirements.<\/p>\n\n\n

      \n
      \n \n \"masvs <\/a>\n <\/figure>\n \n
      \n
      \n \n Close picture \n <\/use>\n <\/svg> <\/button>\n
      \n
      \"masvs <\/figure>\n <\/div>\n <\/div>\n<\/div>\n <\/div>\n\n\n\n

      The last level can be an addition to the first or second level, so there are four possible combinations. Considering which level to apply should be preceded by risk assessment which should be compared with the cost of introducing it. Sometimes, introducing some security measures could be simply not worth of time and effort in perspective of a given risk.<\/p>\n\n\n\n

       <\/strong>
      Below, there are examples for each level the applications should consider:<\/strong><\/p>\n\n\n\n

      • MASVS-L1 \u2013 the level which all applications should achieve, a set of best practices with moderate impact on development cost and user experience.<\/li>
      • MASVS-L2 \u2013 applications with personally identifiable information (PII), credit card numbers or risk of fraudulent usage of data stored. Also utilised, when user\u2019s funds are moved.<\/li>
      • MASVS-L1+R \u2013 all applications which want to protect their Intellectual Property, hardening it against tampering and reverse engineering, including games which want to protect their product against modifying and cheating.<\/li>
      • MASVS-L2+R \u2013 for applications which store PII and whose wide range of supported devices and operating systems increases the need for enhanced resiliency.  Also, applications relying on client-side protection when using in-app purchases can benefit from anti-tampering and anti-reverse engineering mechanisms. Lastly \u2013 for online banking which handles users\u2019 funds on device exposed to potential risk.<\/li><\/ul>\n\n\n\n

        The MASVS specifies which requirements are necessary for each level. These requirements are categorised into 8 groups. First seven categories consider L1 and L2, while the eighth specifies requirements for \u201c+R\u201d resilience level. <\/p>\n\n\n\n


        These categories are:<\/strong><\/p>\n\n\n\n

        • V1: Architecture, Design and Threat Modelling Requirements<\/li>
        • V2: Data Storage and Privacy Requirements<\/li>
        • V3: Cryptography Requirements<\/li>
        • V4: Authentication and Session Management Requirements<\/li>
        • V5: Network Communication Requirements<\/li>
        • V6: Platform Interaction Requirements<\/li>
        • V7: Code Quality and Build Setting Requirements<\/li>
        • V8: Resilience Requirements<\/li><\/ul>\n\n\n\n

          As mentioned before, mobile applications are often part of a more complicated system. <\/p>\n\n\n\n


          Application Security Verification Standard (ASVS)<\/strong> is more general, not focusing on mobile applications. It can be very useful when the product is more complex and consists of API and a web-application beside the mobile application. This document has similar structure to MASVS, but there is no Resiliency level and levels vary from 1 (bare minimum) to 3 (for military, critical infrastructure and \u201chealth & safety\u201d areas).<\/p>\n\n\n

          \n
          \n \n \"asvs <\/a>\n <\/figure>\n \n
          \n
          \n \n Close picture \n <\/use>\n <\/svg> <\/button>\n
          \n
          \"asvs <\/figure>\n <\/div>\n <\/div>\n<\/div>\n <\/div>\n\n\n\n


          Categories of requirements in ASVS are as follows:<\/strong><\/p>\n\n\n\n

          • V1: Architecture, Design and Threat Modelling Requirements<\/li>
          • V2: Authentication Verification Requirements<\/li>
          • V3: Session Management Requirements<\/li>
          • V4: Access Control Verification Requirements<\/li>
          • V5: Validation, Sanitisation and Encoding Verification Requirements<\/li>
          • V6: Stored Cryptography Verification Requirements<\/li>
          • V7: Error Handling and Logging Verification Requirements<\/li>
          • V8: Data Protection Verification Requirements<\/li>
          • V9: Communications Verification Requirements<\/li>
          • V10: Malicious Code Verification Requirements<\/li>
          • V11: Business Logic Verification Requirements<\/li>
          • V12: File and Resources Verification Requirements<\/li>
          • V13: API and Web Service Verification Requirements<\/li>
          • V14: Configuration Verification Requirements<\/li><\/ul>\n\n\n\n

            As you can see, some categories are similar to those in the MASVS, but remember that the perspective of ASVS is different, less focused and it describes requirements for the whole possible system.<\/p>\n\n\n\n

            Gathering requirements for applications is not where the usefulness of MASVS and ASVS ends. They can not only be used as requirements source, but also for secure development training, as baseline for security testing methodologies and security checklists.<\/p>\n\n\n\n


            Mobile Security Testing Guide<\/h2>\n\n\n\n

            Mobile Security Testing Guide maps requirements from MASVS into testing methodology. Every requirement has a corresponding section on how to approach testing and ensure that the requirements are being met. These sections are divided into three main categories, one general for mobile applications and one each for specific platforms – Android and iOS, with security overview, test cases and techniques. <\/p>\n\n\n\n

            For example, the V4.1 from MASVS is:
            <\/strong><\/p>\n\n\n

            \n
            \n \n \"MASVS\" <\/a>\n <\/figure>\n \n
            \n
            \n \n Close picture \n <\/use>\n <\/svg> <\/button>\n
            \n
            \"MASVS\" <\/figure>\n <\/div>\n <\/div>\n<\/div>\n <\/div>\n\n\n\n

            In MSTG, you can look for references of proper ID, in this case \u201cMSTG-AUTH-1\u201d. The ID appears two times in the \u201cMobile App Authentication Architectures\u201d chapter (universal part for both platforms). First time in \u201cVerifying that Appropriate Authentication is in Place\u201d which contains steps to verify if proper authentication and authorisation are in place, and a second time in \u201cTesting OAuth 2.0 Flows\u201d describing best practices to follow and how to verify them. One more occurrence can be found in the \u201cLocal Authentication on Android\u201d chapter under \u201cTesting Confirm Credentials\u201d. There, you can find the \u201cOverview\u201d section which explains how Local Authentication on Android works, the \u201cStatic Analysis\u201d section with code snippets which help to indicate if functionality was introduced and in \u201cDynamic Analysis\u201d on how to verify application in runtime.<\/p>\n\n\n\n

            In the document, one can also find information on how to set testing environments for both platforms, descriptions of tools used in verifications with proper repositories as well as further reading on the topic of mobile architecture and security. With more than 500 pages full of information, it can be very helpful for a security tester in a project.<\/p>\n\n\n\n

            In addition to this, the Projects Page on OWASP has MSTG Hacking Playground \u2013 iOS and Android applications made in an insecure way to present to the readers examples of vulnerabilities described in the Testing Guide.<\/p>\n\n\n\n


            Summary<\/h2>\n\n\n\n

            Documents presented in this article can be very helpful and allow us to introduce security in mobile application with relatively small effort.<\/p>\n\n\n\n

            The first one, OWASP Mobile Top 10 will help you understand what threats can endanger your application\u2019s security.<\/p>\n\n\n\n

            The second one, Mobile Application Security Verification Standard is a great source of requirements for various levels of security in application and it can also be used as checklist when assessing security state of the application. Requirements are clear, with every section linked to further reading where you can find implementation tips and cheat sheets on given elements of application and how to secure it.<\/p>\n\n\n\n

            The third one, Mobile Security Testing Guide is more a complex and heavy document, but is one of the best sources of knowledge on how to approach verification of security requirements mapped from MASVS.<\/p>\n\n\n\n

            All of these, after introducing them in development or testing process can significantly increase the security of your product. After all, a safe product means safe business and safe business means less risk of financial loss.<\/p>\n\n\n

            \n \n Get a security expert to inspect your app\n \n <\/use>\n <\/svg>\n \n <\/use>\n <\/svg> <\/a>\n <\/div>\n","protected":false},"excerpt":{"rendered":"

            Nowadays, having a smartphone in a pocket enables users to use various services almost everywhere at any given time. In the age of ever-improving mobile technology, the market grows more and more, benefiting from stable operating systems, good processing power and longer battery life.<\/p>\n","protected":false},"author":251,"featured_media":15053,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2110,980],"tags":[],"coauthors":[2147],"class_list":["post-15002","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security","category-software-development"],"acf":{"reading-time":"7 mins","show-toc-sublists":false,"image":null,"logo":null,"button1":{"button1_type":"","button":null},"button2":{"button2_type":"","button":null},"person":{"person_photo":null,"person_name":"","person_position":""}},"_links":{"self":[{"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/posts\/15002","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/users\/251"}],"replies":[{"embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/comments?post=15002"}],"version-history":[{"count":0,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/posts\/15002\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/media\/15053"}],"wp:attachment":[{"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/media?parent=15002"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/categories?post=15002"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/tags?post=15002"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.future-processing.com\/blog\/wp-json\/wp\/v2\/coauthors?post=15002"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}