From 2aded867095b47680f5e7f397d1bc2461063d0e8 Mon Sep 17 00:00:00 2001 From: Joanna May Date: Tue, 17 Dec 2024 10:50:30 -0600 Subject: [PATCH 1/8] fix: add security section --- astro.config.mjs | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/astro.config.mjs b/astro.config.mjs index 35a6519..d4318fb 100644 --- a/astro.config.mjs +++ b/astro.config.mjs @@ -101,6 +101,12 @@ export default defineConfig({ directory: "navigation", }, }, + { + label: "🔐 Security", + autogenerate: { + directory: "security", + }, + }, { label: "🪄 State Management", autogenerate: { From ecd4ccd6c4ca0ea48e9e1f521f2a97457ffbbb50 Mon Sep 17 00:00:00 2001 From: Joanna May Date: Wed, 22 Jan 2025 08:29:31 -0600 Subject: [PATCH 2/8] wip: edit document --- cspell.json | 24 +- .../docs/security/security_in_mobile_apps.mdx | 205 +++++++++--------- 2 files changed, 117 insertions(+), 112 deletions(-) diff --git a/cspell.json b/cspell.json index 90410eb..5df332b 100644 --- a/cspell.json +++ b/cspell.json @@ -1,17 +1,28 @@ { "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json", "version": "0.2", - "ignorePaths": ["node_modules/**", ".**/"], - "files": ["**/*.md", "**/*.mdx", "**/*.tsx", "**/*.ts", "**/*.json"], + "ignorePaths": [ + "node_modules/**", + ".**/" + ], + "files": [ + "**/*.md", + "**/*.mdx", + "**/*.tsx", + "**/*.ts", + "**/*.json" + ], "words": [ "ABAP", "Abuild", "Agda", "AMPL", "ANTLR", + "Approov", "astro", "astrojs", "Augeas", + "Backdoors", "Batchfile", "Befunge", "Bidirectionality", @@ -20,6 +31,7 @@ "Carto", "Cirru", "Codemagic", + "codesigning", "Crunscript", "Csound", "Cuda", @@ -34,10 +46,10 @@ "Eclass", "Filebench", "Filterscript", - "fontsource", "Firestore", - "Formz", + "fontsource", "formz", + "Formz", "Frege", "gaugecomponent", "Genshi", @@ -54,19 +66,21 @@ "Ioke", "Ishida", "Jailbreaking", + "Jailbroken", "Jasmin", "Jison", "Jolie", + "Keyloggers", "laboratoria", "Linx", "listview", "listviews", "Logtalk", "LOLCODE", - "Mathematica", "MASTG", "MASVS", "MASWE", + "Mathematica", "mdlint", "merch", "Mirah", diff --git a/src/content/docs/security/security_in_mobile_apps.mdx b/src/content/docs/security/security_in_mobile_apps.mdx index 84eba64..bb55917 100644 --- a/src/content/docs/security/security_in_mobile_apps.mdx +++ b/src/content/docs/security/security_in_mobile_apps.mdx @@ -3,186 +3,177 @@ title: Security in Mobile Apps description: Mobile app security threats and how to protect your app using OWASP Mobile's 10 best practices. --- -Mobile app security is a critical concern for developers and users alike. The [Open Web Application Security Project (OWASP)](https://owasp.org/) Mobile Security Project provides a comprehensive guide to the top 10 security risks for mobile apps. This article will cover the top 10 security threats and how to protect your app using OWASP Mobile's best practices. -But first let's take a look at the common mobile app security threats. +Mobile app security is a critical concern for developers and users alike. The [Open Web Application Security Project (OWASP)](https://owasp.org/) maintains industry-accepted mobile application security guidelines that should be followed when building multiplatform mobile applications. + +:::danger +By far, the most common security threat is **social engineering**. Be sure to educate your team and create well-defined trust structures which require face-to-face confirmation for any proposed changes that affect security. +::: ## Common Mobile App Security Threats +- **Social Engineering**: is a manipulation tactic that exploits human error to gain unauthorized access to private information, systems, or valuables. In cybercrime, it involves deceiving users into revealing data, spreading malware, or granting access to restricted systems. + - **Malware**: Malicious software intentionally designed to harm, exploit, or compromise a mobile device, its data, or the user. Mobile app malware can take various forms, often disguised as legitimate apps or embedded within apps to deceive users into installing it on their devices. - - Trojan + - Trojans - Spyware - Adware - Ransomware - Banking Malware - - Keylogger + - Keyloggers - Rooting/Jailbreaking Tools - Worms - - Backdoor - - and more. + - Backdoors -- **Phishing**: In a mobile app, it is a deceptive attempt by malicious actors to trick users into revealing sensitive information, such as login credentials, financial details, or personal data, through fraudulent means. Phishing typically relies on social engineering techniques to exploit user trust and manipulate users into taking actions that compromise their security. -- **Man in the middle attacks (MitM)**: Interception of communication between mobile apps and APIs, allowing attackers to eavesdrop or modify data +- **Phishing**: a deceptive attempt by malicious actors to trick users into revealing sensitive information such as login credentials, financial details, or personal data through fraudulent means. Phishing typically relies on **social engineering techniques** to exploit user trust and **manipulate users into taking actions that compromise their security.** +- **Man in the middle attacks (MitM)**: intercepting communication between mobile apps and servers, allowing attackers to eavesdrop or modify data. - **Data breaches:** Unauthorized access leads to the exposure of sensitive user data. Risks include personal information (PII), credentials, and financial data. -- **Authentication attacks**: in a mobile app are attempts by malicious actors to exploit vulnerabilities in the app's authentication mechanisms to gain unauthorized access to user accounts, sensitive data, or application functionality. These attacks target flaws in how the app verifies the identity of its users or systems. +- **Authentication attacks**: attempts by malicious actors to exploit vulnerabilities in the app's authentication mechanisms to gain unauthorized access to user accounts, sensitive data, or application functionality. These attacks target flaws in how the app verifies the identity of its users or systems. - Credential Stuffing - Brute Force Attacks - Phishing Attacks - Session Hijacking - Man-in-the-Middle (MitM) Attacks - Password Reset Exploits - - _OAuth and Token-Based Attacks_: Attackers exploit vulnerabilities in OAuth flows or misconfigure token handling to gain unauthorized access. -- **Code tampering**: Unauthorized modification of the mobile app's code, potentially leading to functionality alterations or the injection of malicious code. -- **Reverse engineering**: Extraction of source code or sensitive information from the mobile app, often to create fake versions. -- **API Security risks**: Inadequate protection of APIs, leading to vulnerabilities such as unauthorized access, injection attacks, and data exposure. -- **Insecure data storage**: Weak encryption or improper storage of sensitive data on the device, making it vulnerable to unauthorized access. + - OAuth and Token-Based Attacks: Attackers exploit vulnerabilities in OAuth flows or misconfigure token handling to gain unauthorized access. +- **Code tampering**: Unauthorized modification of the mobile app's code, potentially leading to alterations in functionality or the injection of malicious code. +- **Reverse engineering**: Extraction of source code or sensitive information from the mobile app, often to create fake versions of the app. +- **Insufficient API Security**: Inadequate protection of APIs, leading to vulnerabilities such as unauthorized access, injection attacks, and data exposure. +- **Insecure Data Storage**: Weak encryption or improper storage of sensitive data on the device, making it vulnerable to unauthorized access. - **Insufficient Transport Layer Protection:** Lack of proper TLS encryption during data transmission, exposing information to interception and manipulation. - **Denial of Service (DoS) Attacks:** Overwhelming a mobile app or API with traffic disrupts its availability, causing service downtime. -- **Unsecured Third-Party Libraries:** Integration of insecure or outdated third-party libraries, introducing potential vulnerabilities into the mobile app. +- **Unsecured Third-Party Libraries:** Integration of insecure or outdated third-party libraries which introduce vulnerabilities into the mobile app. - **Poorly Implemented Multi-Factor Authentication (MFA):** Inadequate implementation of MFA, allowing attackers to bypass additional authentication measures. - **Supply Chain Attacks:** Compromising the security of a mobile app or API through vulnerabilities in its supply chain, including third-party services or components. -- **Social Engineering**: is a manipulation tactic that exploits human error to gain unauthorized access to private information, systems, or valuables. In cybercrime, it involves deceiving users into revealing data, spreading malware, or granting access to restricted systems. -And more. -## OWASP (Open Worldwide Application Security Project) +## OWASP Guidelines The **Open Worldwide Application Security Project (OWASP)** is a globally recognized nonprofit organization dedicated to improving the security of software and web applications. Established in 2001, OWASP provides resources, tools, and best practices to help developers, organizations, and security professionals build secure applications and address vulnerabilities effectively. -### Importance of OWASP - -- **Promotes Secure Development**: Encourages developers to integrate security practices from the ground up. -- **Universal Accessibility**: Resources are open-source and widely adopted across industries. -- **Standardization**: Sets benchmarks for assessing and improving application security. -- **Collaboration**: Facilitates knowledge sharing among global security professionals. - ### OWASP Mobile Top 10 Security Risks in 2024 -The OWASP Mobile Top 10 is a list of the most critical security risks for mobile apps, updated periodically to reflect emerging threats and trends. The latest version, OWASP Mobile Top 10 2024, highlights the following risks: +The OWASP Mobile Top 10 is a list of the most critical security risks for mobile apps and is updated periodically to reflect emerging threats and trends. + +The latest version, OWASP Mobile Top 10 2024, highlights the following risks: ![OWASP comparison 2016 vs 2024](./images/owasp_comparison.png) _Source_: [OWASP Mobile Top 10 2024](https://owasp.org/www-project-mobile-top-10/) -- **M1: Improper Credential Usage**: Threat agents can exploit hardcoded credentials or improper credential usage in mobile applications by using automated tools, either publicly available or custom-built. These vulnerabilities make it easier for attackers to locate and exploit the credentials or weaknesses in their implementation. - - - **How to prevent it?**: - - Avoid hardcoding credentials in the app's code or configuration files. - - Implement secure credential storage mechanisms, such as the Android Keystore or iOS Keychain or use revocable tokens. - - Use strong encryption and hashing algorithms during credential storage and transmission. - - Avoid weak authentication mechanisms, such as weak passwords or insecure authentication flows. +#### Improper Credential Usage -Dart-crypt is an interesting package to hashing passwords in Dart. You can find more information about Dart-crypt. +Threat agents can exploit hardcoded credentials or improper credential usage in mobile applications by using automated tools, either publicly available or custom-built. -- [Dart-crypt](https://github.com/hoylen/dart-crypt) +:::danger +If your app requires access to sensitive API's, **you must not include those API keys in the front-end of your app.** -Use Firebase Authentication for a more secure authentication system. You can find more information in the official documentation. +It is impossible to secure any credentials that are shipped with an application, since **the compiled code for front-end applications is subject to reverse engineering** (no matter how clever you think you are). -- [Firebase Authentication](https://firebase.google.com/docs/auth) +Instead of shipping sensitive API keys in your app, create a microservice or cloud function which stores the API key securely in your backend (or leverage services like [Approov](https://approov.io/)). Yes, it's extra work — but it's mandatory for sensitive endpoints. +::: -Here you have another interesting article that talks about authentication in Flutter. +:::tip +- , Use the Android Keystore or iOS Keychain to store sensitive user information. +- Use strong encryption and hashing algorithms during credential storage and transmission. +- Avoid weak authentication mechanisms, including common/weak passwords or insecure authentication flows. +::: -- [Flutter authentication with Auth0](https://developer.auth0.com/resources/guides/mobile/flutter/basic-authentication/) +[Dart-crypt](https://github.com/hoylen/dart-crypt) allows you to salt and hash passwords easily. -More information on _M1: Improper Credential Usage_ [here.](https://owasp.org/www-project-mobile-top-10/2023-risks/m1-improper-credential-usage.html) +[Firebase Authentication](https://firebase.google.com/docs/auth) handles a wide variety of common security considerations and eliminates the need for highly sophisticated authentication for small to mid-size projects. -- **M2: Inadequate Supply Chain Security**: Attackers can exploit vulnerabilities in the mobile app supply chain, such as inserting malicious code during development or exploiting flaws in third-party libraries, SDKs, or hardcoded credentials. These actions can lead to data theft, user surveillance, unauthorized access to backend servers, denial of service, or full control over the app or device. +There's also a [Flutter-specific guide to Auth0](https://developer.auth0.com/resources/guides/mobile/flutter/basic-authentication/) if you're leveraging that in your application. - - **How to prevent it?**: - - Apply secure coding, code review, and testing throughout development. - - Ensure secure app signing and distribution to block malicious actors. - - Use trusted, validated third-party libraries to minimize risks. - - Implement security controls for updates and patches to address - vulnerabilities. - - Monitor and detect supply chain incidents with testing and scanning for timely responses. +For more information on _Improper Credential Usage_, [refer to the OWASP guide](https://owasp.org/www-project-mobile-top-10/2023-risks/m1-improper-credential-usage.html). -You can check the **Software supply chain security for Flutter and its ecosystem** video from the Flutter Forward 2023 conference. +#### Inadequate Supply Chain Security -- [Software supply chain security for Flutter and its ecosystem](https://www.youtube.com/watch?v=7LFftXcw1jA) +Attackers can exploit vulnerabilities in the mobile app supply chain, such as inserting malicious code during development or exploiting flaws in third-party libraries, SDKs, or hardcoded credentials. -Also, check it out the **SLSA** (Supply Chain Levels for Software Artifacts)security framework, which is a check-list of standards and controls to prevent supply chain attacks. +:::tip +- Leverage human-led code review (with automated tests, checks and analyzers). +- Ensure secure app signing and distribution to block malicious actors. Services like [Codemagic](https://codemagic.io/) can drastically simplify the code-signing process. +- Use trusted, validated third-party libraries to minimize risks. +- Implement a process that requires both a human and an automated vulnerability checker (such as dependabot) to review package updates and patches in your codebase. +- Stay up-to-date on supply chain incidents and open source package vulnerabilities. +- Carefully scan pull requests on your open source projects — many open source projects have accidentally merged malicious code by accident. +::: -- [SLSA](https://slsa.dev/) +You can check the [Software supply chain security for Flutter and its ecosystem video](https://www.youtube.com/watch?v=7LFftXcw1jA) from the Flutter Forward 2023 conference. -More information on _M2: Inadequate Supply Chain Security_ [here.](https://owasp.org/www-project-mobile-top-10/2023-risks/m2-inadequate-supply-chain-security.html) +The [**SLSA** (Supply Chain Levels for Software Artifacts) security framework](https://slsa.dev/) maintains a check-list of standards and controls to prevent supply chain attacks. -- **M3: Insecure Authentication/Authorization**: Threat agents that exploit authentication and authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools. +For more information on _Inadequate Supply Chain Security_, [refer to the OWASP guide.](https://owasp.org/www-project-mobile-top-10/2023-risks/m2-inadequate-supply-chain-security.html) - - **How to prevent it?**: - These are only a few of the many ways to prevent this threat: - - Use server-side authentication; avoid client-side methods to prevent bypasses. - - Encrypt local data if needed, but mitigate risks of binary attacks. - - Implement device-specific tokens instead of storing passwords or using weak identifiers. - - Make persistent authentication opt-in, and avoid weak PINs for passwords. - - Enforce all controls server-side; assume client-side can be bypassed. - - Use biometrics (FaceID, TouchID) for secure access to sensitive data. - - Perform local integrity checks if offline functionality is necessary. +#### Insecure Authentication/Authorization -This is an interesting article that talks about encryption and decryption in Flutter. +Threat agents that exploit authentication and authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools. -- [Encryption and Decryption in Flutter](https://medium.com/@laithalsahore19/explore-encrypt-decrypt-data-in-flutter-e1e64c86b0ee) -Use **local auth** package to add biometrics to the app. +:::tip +- Use server-side authentication. +- Encrypt local data. +- Use device-specific tokens instead of storing passwords or using weak identifiers. +- Make persistent authentication opt-in. +- Avoid weak PINs for passwords. +- Enforce all controls server-side; assume client-side can be bypassed. +- Use biometrics (FaceID, TouchID) for secure access to sensitive data. +- Perform local integrity checks if offline functionality is necessary. +::: -- [Local Auth](https://pub.dev/packages/local_auth) +For more on data safety, check out the [Encryption and Decryption in Flutter](https://medium.com/@laithalsahore19/explore-encrypt-decrypt-data-in-flutter-e1e64c86b0ee) overview. -More information on _M3: Insecure Authentication/Authorization_ [here.](https://owasp.org/www-project-mobile-top-10/2023-risks/m3-insecure-authentication-authorization.html) +You can also use [Local Auth](https://pub.dev/packages/local_auth) to integrate biometric authentication. -- **M4: Insufficient Input/Output Validation**: insufficient validation and sanitization of user inputs or network data in mobile apps can lead to critical vulnerabilities, including SQL injection, command injection, and XSS attacks. These flaws may enable unauthorized data access, app manipulation, system compromise, data corruption, or malicious code injection, posing significant security risks. +For more information on _Insecure Authentication/Authorization_, [refer to the OWASP guide](https://owasp.org/www-project-mobile-top-10/2023-risks/m3-insecure-authentication-authorization.html). - - **How to prevent it?**: - - **Input Validation**: Use strict validation, set length limits, and reject unexpected or malicious input. - - **Output Sanitization**: Sanitize output to prevent XSS (cross-site scripting) and use encoding for displayed or transmitted data. - - **Context-Specific Validation**: Adapt validation to the context of the data, such as database loads or queries, to block targeted attacks. - - **Data Integrity Checks**: Detect and prevent data corruption or unauthorized changes. - - **Secure Coding**: Use practices like parameterized queries to block SQL injection. - - **Regular Testing**: Conduct penetration testing and code reviews to find and fix vulnerabilities. +#### Insufficient Input/Output Validation -Use the **formz** package to validate forms in Flutter and prevent incorrect data to be sent to the backend. +Insufficient validation and sanitization of user inputs or network data in mobile apps can lead to critical vulnerabilities, including SQL injection, command injection, and XSS attacks. -- [Formz](https://pub.dev/packages/formz) +:::tip +- Use strict input validation, set length limits, and reject unexpected or malicious input. +- Sanitize output to prevent XSS (cross-site scripting). +- Use parameterized queries to block SQL injection. +- Work with external security vendors which can evaluate and test your application and its servers. +::: -Use persist data with SQLite to prevent SQL Injection. +Use the [Formz](https://pub.dev/packages/formz) package to validate forms in Flutter and prevent incorrect data to be sent to the backend. -- [Persist data with SQLite](https://docs.flutter.dev/cookbook/persistence/sqlite) +For more information on _Insufficient Input/Output Validation_, [refer to the OWASP guide](https://owasp.org/www-project-mobile-top-10/2023-risks/m4-insufficient-input-output-validation.html). -More information on _M4: Insufficient Input/Output Validation_ [here.](https://owasp.org/www-project-mobile-top-10/2023-risks/m4-insufficient-input-output-validation.html) +#### Insecure Communication -- **M5: Insecure Communication**: mobile apps often exchange data with remote servers, creating vulnerabilities if data is sent in plaintext or with outdated encryption. Threat agents can intercept or modify data, aiming for theft, espionage, or identity fraud. Key threats include: +Threat agents can intercept or modify insecure communications transferred between an app and the server. - - Adversaries on the same local network (e.g., compromised Wi-Fi). - - Unauthorized network devices (e.g. malicious routers or proxy servers). - - Malware on the mobile device itself. +When creating an app, assume threats can originate from any of the following: - - **How to prevent it?**: - - **Assume an Unsecure Network Layer**: Always secure transport channels against eavesdropping. - - **Use SSL/TLS**: Apply SSL/TLS for all data transmissions to backend services and third-party entities, avoiding mixed SSL sessions. - - **Use Trusted Certificates**: Implement certificates signed by trusted CAs and never allow untrusted, expired, or mismatched certificates. - - **Strong Encryption**: Use industry-standard cipher suites with appropriate key lengths. - - **Certificate Pinning**: Consider pinning certificates and always require SSL chain verification. - - **Server Authentication**: Verify endpoint server identities using trusted certificates before establishing connections. - - **User Alerts**: Notify users of invalid certificates through the app’s UI. - - **Secondary Encryption**: Encrypt sensitive data before sending it over SSL for additional protection. - - **Avoid Alternate Channels**: Never transmit sensitive data via SMS, MMS, or notifications. - - **Development Practices**: Use local development CAs and avoid disabling SSL verification. - - **Traffic Analysis**: During security testing, check for plaintext data transmission vulnerabilities. +- Adversaries on the same local network (compromised Wi-Fi). +- Unauthorized network devices (malicious routers or proxy servers). +- Malware on the mobile device itself. -If you're using Firebase, you can implement App Check to protect your backend from unauthorized clients accessing it. Learn more in the official documentation. +:::tip +- Use SSL/TLS for all data transmissions to backend services and third-party entities and avoid mixed SSL sessions. +- Only accept certificates signed by trusted certificate authorities (CA's) and never allow expired or mismatched certificates. +- Use current, industry accepted encryption algorithms with appropriate key lengths (AES-128 is a good start). Encryption algorithms are subject to mathematical analysis: some older algorithms have been identified by mathematicians and experts as being easier to exploit. +- Pin certificates and require SSL chain verification. +- Never transmit sensitive data via unencrypted channels (like SMS or via push notifications). +- During security testing, conduct traffic analysis to verify no plaintext data transmissions. +::: -- [Firebase App Check](https://firebase.google.com/docs/app-check) +If you're using Firebase, you can implement [Firebase App Check](https://firebase.google.com/docs/app-check) to protect your backend from unauthorized clients accessing it. -This article explains how to add SSL certificate pinning to a Flutter app. +For more on certificates, see [SSL Certificate Pinning in Flutter](https://dwirandyh.medium.com/securing-your-flutter-app-by-adding-ssl-pinning-474722e38518). -- [SSL Certificate Pinning in Flutter](https://dwirandyh.medium.com/securing-your-flutter-app-by-adding-ssl-pinning-474722e38518) +You may also use a package called [Http Certificate Pinning package](https://pub.dev/packages/http_certificate_pinning) to add certificate pinning to your app. -Also you can use a popular package called **http certificate pinning** to add certificate pinning to your app. +For more information on _Insecure Communication_, [refer to the OWASP guide](https://owasp.org/www-project-mobile-top-10/2023-risks/m5-insecure-communication.html). -- [Http Certificate Pinning package](https://pub.dev/packages/http_certificate_pinning) +#### Inadequate Privacy Controls -More information on _M5: Insecure Communication_ [here.](https://owasp.org/www-project-mobile-top-10/2023-risks/m5-insecure-communication.html) +Privacy controls are concerned with protecting personally identifiable information (PII), such as names and addresses, credit card information, email and IP addresses, health information, religion, sexuality, and political opinions. -- **M6: Inadequate Privacy Controls**: Privacy controls are concerned with protecting personally identifiable information (PII), such as names and addresses, credit card information, email and IP addresses, health information, religion, sexuality, and political opinions. - This information is valuable to attackers for a number of reasons. For example, an attacker could impersonate the victim to commit fraud, misuse the victim's payment details, blackmail the victim with sensitive information, or harm the victim by destroying or tampering with their critical data. +This information is valuable to attackers for a number of reasons. For example, an attacker could impersonate the victim to commit fraud, misuse the victim's payment details, blackmail the victim with sensitive information, or harm the victim by destroying or tampering with their critical data. - **How to prevent it?**: The best way to prevent privacy violations is to minimize the collection and processing of Personally Identifiable Information (PII). This requires a full understanding of the app's PII usage. From 4f8573b61e362171208e449677b3f04f66315eaf Mon Sep 17 00:00:00 2001 From: Joanna May Date: Wed, 22 Jan 2025 08:30:43 -0600 Subject: [PATCH 3/8] fix: undo duplicate change --- astro.config.mjs | 6 ------ 1 file changed, 6 deletions(-) diff --git a/astro.config.mjs b/astro.config.mjs index d4318fb..7042caa 100644 --- a/astro.config.mjs +++ b/astro.config.mjs @@ -131,12 +131,6 @@ export default defineConfig({ directory: "widgets", }, }, - { - label: "🔐 Security", - autogenerate: { - directory: "security", - }, - }, ], components: { TwoColumnContent: From 478eef96308cef1712882f618fdf81502aefde70 Mon Sep 17 00:00:00 2001 From: Joanna May Date: Thu, 23 Jan 2025 11:16:59 -0600 Subject: [PATCH 4/8] docs: finish editing --- .../docs/security/security_in_mobile_apps.mdx | 148 +++++++++--------- 1 file changed, 74 insertions(+), 74 deletions(-) diff --git a/src/content/docs/security/security_in_mobile_apps.mdx b/src/content/docs/security/security_in_mobile_apps.mdx index bb55917..e8befb9 100644 --- a/src/content/docs/security/security_in_mobile_apps.mdx +++ b/src/content/docs/security/security_in_mobile_apps.mdx @@ -46,7 +46,6 @@ By far, the most common security threat is **social engineering**. Be sure to ed - **Poorly Implemented Multi-Factor Authentication (MFA):** Inadequate implementation of MFA, allowing attackers to bypass additional authentication measures. - **Supply Chain Attacks:** Compromising the security of a mobile app or API through vulnerabilities in its supply chain, including third-party services or components. - ## OWASP Guidelines The **Open Worldwide Application Security Project (OWASP)** is a globally recognized nonprofit organization dedicated to improving the security of software and web applications. Established in 2001, OWASP provides resources, tools, and best practices to help developers, organizations, and security professionals build secure applications and address vulnerabilities effectively. @@ -60,7 +59,7 @@ The latest version, OWASP Mobile Top 10 2024, highlights the following risks: ![OWASP comparison 2016 vs 2024](./images/owasp_comparison.png) _Source_: [OWASP Mobile Top 10 2024](https://owasp.org/www-project-mobile-top-10/) -#### Improper Credential Usage +### Improper Credential Usage Threat agents can exploit hardcoded credentials or improper credential usage in mobile applications by using automated tools, either publicly available or custom-built. @@ -86,7 +85,7 @@ There's also a [Flutter-specific guide to Auth0](https://developer.auth0.com/res For more information on _Improper Credential Usage_, [refer to the OWASP guide](https://owasp.org/www-project-mobile-top-10/2023-risks/m1-improper-credential-usage.html). -#### Inadequate Supply Chain Security +### Inadequate Supply Chain Security Attackers can exploit vulnerabilities in the mobile app supply chain, such as inserting malicious code during development or exploiting flaws in third-party libraries, SDKs, or hardcoded credentials. @@ -105,7 +104,7 @@ The [**SLSA** (Supply Chain Levels for Software Artifacts) security framework](h For more information on _Inadequate Supply Chain Security_, [refer to the OWASP guide.](https://owasp.org/www-project-mobile-top-10/2023-risks/m2-inadequate-supply-chain-security.html) -#### Insecure Authentication/Authorization +### Insecure Authentication/Authorization Threat agents that exploit authentication and authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools. @@ -127,7 +126,7 @@ You can also use [Local Auth](https://pub.dev/packages/local_auth) to integrate For more information on _Insecure Authentication/Authorization_, [refer to the OWASP guide](https://owasp.org/www-project-mobile-top-10/2023-risks/m3-insecure-authentication-authorization.html). -#### Insufficient Input/Output Validation +### Insufficient Input/Output Validation Insufficient validation and sanitization of user inputs or network data in mobile apps can lead to critical vulnerabilities, including SQL injection, command injection, and XSS attacks. @@ -142,7 +141,7 @@ Use the [Formz](https://pub.dev/packages/formz) package to validate forms in Flu For more information on _Insufficient Input/Output Validation_, [refer to the OWASP guide](https://owasp.org/www-project-mobile-top-10/2023-risks/m4-insufficient-input-output-validation.html). -#### Insecure Communication +### Insecure Communication Threat agents can intercept or modify insecure communications transferred between an app and the server. @@ -169,121 +168,122 @@ You may also use a package called [Http Certificate Pinning package](https://pub For more information on _Insecure Communication_, [refer to the OWASP guide](https://owasp.org/www-project-mobile-top-10/2023-risks/m5-insecure-communication.html). -#### Inadequate Privacy Controls +### Inadequate Privacy Controls Privacy controls are concerned with protecting personally identifiable information (PII), such as names and addresses, credit card information, email and IP addresses, health information, religion, sexuality, and political opinions. This information is valuable to attackers for a number of reasons. For example, an attacker could impersonate the victim to commit fraud, misuse the victim's payment details, blackmail the victim with sensitive information, or harm the victim by destroying or tampering with their critical data. - - **How to prevent it?**: - The best way to prevent privacy violations is to minimize the collection and processing of Personally Identifiable Information (PII). This requires a full understanding of the app's PII usage. - - Evaluate whether all personally identifiable information is necessary, whether less sensitive alternatives can be used, or whether personally identifiable information can be reduced, anonymized, or deleted after a certain period. Allow users to consent to the optional use of personally identifiable information with clear awareness of the associated risks. - - Store or transfer PII only when absolutely necessary, with strict authentication and authorization controls. Implement defense-in-depth for critical data, such as encrypting health information with device TPM keys to protect against sandbox bypasses. - - Threat modeling can identify the most likely privacy risks, focusing security efforts accordingly. Use static and dynamic security tools to uncover vulnerabilities like improper logging or accidental data leakage. - -:::note -In some cases, we don't pay much attention to the fact that the data we store could be used by an attacker to harm the user or even the company. It is important to always be aware of what data is stored and how it is used. +:::tip +- The best way to prevent privacy violations is to minimize the collection and processing of Personally Identifiable Information (PII). This requires a full understanding of the app's PII usage. +- Evaluate whether all personally identifiable information is necessary, whether less sensitive alternatives can be used, or whether personally identifiable information can be reduced, anonymized, or deleted after a certain period. Allow users to consent to the optional use of personally identifiable information with clear awareness of the associated risks. +- Store or transfer PII only when absolutely necessary, with strict authentication and authorization controls. Secure personal data, such as encrypting health information with device TPM keys to protect against sandbox bypasses. +- Threat modeling can identify the most likely privacy risks, focusing security efforts accordingly. Use static and dynamic security tools to uncover vulnerabilities like improper logging or accidental data leakage. ::: -More information on _M6: Inadequate Privacy Controls_ [here.](https://owasp.org/www-project-mobile-top-10/2023-risks/m6-inadequate-privacy-controls.html) - -- **M7: Insufficient Binary Protection**: Attackers target app binaries to extract valuable secrets like API keys or cryptographic secrets, access critical business logic or pre-trained AI models, or investigate weaknesses in backend systems. They may also manipulate binaries to access paid features for free, bypass security checks, or insert malicious code. Repackaging attacks can exploit unsuspecting users, such as modifying payment identifiers and redistributing compromised apps to divert payments to attackers. Protecting app binaries is crucial to prevent data theft, fraud, and malicious exploitation. +For more information on _Inadequate Privacy Controls_, [refer to the OWASP guide.](https://owasp.org/www-project-mobile-top-10/2023-risks/m6-inadequate-privacy-controls.html) - - **How to prevent it?**: - - **Minimize risk exposure**: Apps should only access the minimal information needed to function, as all data in the binary is vulnerable to leaks or manipulation. - - **Defend against reverse engineering**: Use obfuscation tools to make binaries incomprehensible. Native compilation, interpreters, or nested virtual machines can further complicate reverse engineering, though this may impact compatibility. Test obfuscation quality using reverse-engineering tools. - - **Strengthen security mechanisms**: Obfuscation makes skipping security checks harder. Reinforce local security checks through backend validation and implement integrity checks to detect code tampering, though attackers may still bypass local checks. - - **Prevent malicious redistribution**: Integrity checks at app launch can detect unauthorized modifications and redistribution. Violations can be reported to remove fake apps from stores, and specialized services are available to support detection and removal efforts. +### Insufficient Binary Protection -To prevent reverse engineering, tampering, malware installation, etc., there is an interesting package called FreeRASP that can help you with that. You can find more information about FreeRASP. +Attackers target app binaries to extract valuable secrets like API keys or cryptographic secrets, access critical business logic or pre-trained AI models, or investigate weaknesses in backend systems. They may also manipulate binaries to access paid features for free, bypass security checks, or insert malicious code. Repackaging attacks can exploit unsuspecting users, such as modifying payment identifiers and redistributing compromised apps to divert payments to attackers. Protecting app binaries is crucial to prevent data theft, fraud, and malicious exploitation. -- [FreeRASP](https://pub.dev/packages/freerasp) +:::tip +- Apps should only access the minimal information needed to function, as all data in the binary is vulnerable to leaks or manipulation. +- Use obfuscation tools to make binaries incomprehensible. Native compilation, interpreters, or nested virtual machines can further complicate reverse engineering Test obfuscation quality using reverse-engineering tools. +- Obfuscation makes skipping security checks harder. Reinforce local security checks through backend validation and implement integrity checks to detect code tampering, though attackers may still bypass local checks. +- Integrity checks at app launch can detect unauthorized modifications and redistribution. Violations can be reported to remove fake apps from stores, and specialized services are available to support detection and removal efforts. +::: -Another important part is obfuscation, you can find more information in the official Flutter documentation. +Tools and services such as FreeRASP and Aproov can help mitigate the likelihood of a compromised app binary or repackaging attack. -- [Obfuscating Dart Code](https://flutter.dev/docs/deployment/obfuscate) +- [Approov](https://approov.io/docs/latest/approov-usage-documentation/) +- [FreeRASP](https://pub.dev/packages/freerasp) This is a great article that talks about how to secure your API Keys. - [Securing API Keys](https://nshipster.com/secrets/) +- [Obfuscating Dart Code](https://flutter.dev/docs/deployment/obfuscate) -There are tools like AWS Secrets Manager and Google Cloud Secret Manager that helps the user to secure the API keys and secrets. - -- [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) -- [AWS Secrets Manager video](https://www.youtube.com/watch?v=-9nOyaM3kZk&t=26s) -- [Google Cloud Secret Manager](https://cloud.google.com/secret-manager) - -:::note[Take into account] - -Tools like **FreeRASP** and **obfuscation** techniques improve application security, they can't guarantee complete protection against cyber attacks. API keys and secrets stored on the client side are always vulnerable to extraction through reverse engineering, among other techniques. +:::caution +There is no such thing as perfect security against app repackaging attacks. API keys and secrets stored on the client side are always vulnerable to extraction through reverse engineering. -One possible solution for increased security would be to implement a custom backend as it would protect these sensitive keys. This backend would handle API calls securely, keeping secrets hidden from the client. +To protect sensitive API's, implement a custom-backend which acts as middleware between the app and the sensitive api's so that the API keys never reach the front-end. ::: -More information on _M7: Insufficient Binary Protection_ [here.](https://owasp.org/www-project-mobile-top-10/2023-risks/m7-insufficient-binary-protection.html) +More information on _Insufficient Binary Protection_, [refer to the OWASP guide.](https://owasp.org/www-project-mobile-top-10/2023-risks/m7-insufficient-binary-protection.html) + +### Security Misconfiguration -- **M8: Security Misconfiguration**: security misconfiguration occurs when mobile apps have improperly configured security settings, permissions, or controls, leading to vulnerabilities and unauthorized access. Threat agents, such as attackers with physical device access or malicious apps, exploit these weaknesses to access sensitive data or execute unauthorized actions within the vulnerable app's context. Proper configuration is crucial to mitigate these risks. +Security misconfiguration occurs when mobile apps have improperly configured security settings, permissions, or controls, leading to vulnerabilities and unauthorized access. Threat agents, such as attackers with physical device access or malicious apps, exploit these weaknesses to access sensitive data or execute unauthorized actions within the vulnerable app's context. Proper configuration is crucial to mitigate these risks. - - **How to prevent it?**: - - **Secure Default Configurations**: Ensure default settings do not expose sensitive data or unnecessary permissions. - - **Avoid Default Credentials**: Do not use hardcoded default credentials. - - **Insecure Permissions**: Avoid overly permissive file permissions (for example, read or write). - - **Least Privilege Principle**: Request only necessary permissions for the app's functionality. - - **Secure Network Configuration**: Use encrypted traffic (avoid cleartext) and implement certificate pinning. - - **Disable Debugging**: Turn off debugging features in production apps. - - **Disable Backup Mode (Android)**: Prevent app data from being included in device backups. - - **Limit Attack Surface**: Only export activities, content providers, and services that are required. +:::tip +- Ensure default settings do not expose sensitive data or unnecessary permissions. +- Do not use hardcoded credentials. +- Request only necessary permissions for the app's functionality. +- Encrypt app communications and implement certificate pinning. +- Turn off debugging features in production apps. +- Prevent app data from being included in device backups. +- Only export activities, content providers, and services that are required. +::: :::caution Don't add permissions that are not necessary for the app to work. It's easy for an attacker to exploit these permissions to gain access to sensitive data. + +In general, you want to respect the **principle of least privilege**: only request the permissions that are absolutely necessary for the app to function. ::: -More information on _M8: Security Misconfiguration_ [here.](https://owasp.org/www-project-mobile-top-10/2023-risks/m8-security-misconfiguration.html) +For more information on _Security Misconfiguration_, [refer to the OWASP guide.](https://owasp.org/www-project-mobile-top-10/2023-risks/m8-security-misconfiguration.html) -- **M9: Insecure Data Storage**: insecure data storage in mobile apps exposes sensitive information to various threat agents, including skilled attackers, malicious insiders, state-sponsored actors, cybercriminals, script kiddies, data brokers, competitors, and activists. These agents exploit vulnerabilities like weak encryption, insecure storage, and improper handling of credentials. To mitigate these risks, mobile app developers and organizations must implement strong security measures, including robust encryption, secure data storage practices, and mobile app security best practices. +### Insecure Data Storage -- **How to prevent it?**: - - **Use strong encryption**: Employ robust encryption algorithms to protect data at rest and in transit. Ensure proper key management. - - **Secure data transmission**: Use secure communication protocols like HTTPS or SSL/TLS to protect data during transmission. - - **Implement secure storage mechanisms**: Store sensitive data in secure locations, such as Keychain (iOS) or Keystore (Android), to prevent unauthorized access. - - **Employ proper access controls**: Use strong authentication, role-based access controls, and validate user permissions to limit access to sensitive data. - - **Validate input and sanitize data**: Prevent injection attacks by validating and sanitizing user input to ensure only valid data is stored. - - **Apply secure session management**: Use secure session tokens, set proper session timeouts, and securely store session data. - - **Regularly update and patch dependencies**: Keep all libraries and dependencies up to date and apply security patches promptly. - - **Stay informed**: Monitor security advisories and platform updates to address emerging threats and vulnerabilities. +Insecure data storage in mobile apps exposes sensitive information to various threat agents, including skilled attackers, malicious insiders, state-sponsored actors, cybercriminals, script kiddies, data brokers, competitors, and activists. These agents exploit vulnerabilities like weak encryption, insecure storage, and improper handling of credentials. -If you are using Firestore to store your data, it would be interesting adding some security rules to prevent unauthorized access. You can find more information in the official documentation. +:::tip +- Employ robust encryption algorithms to protect data at rest and in transit, such as AES-256. +- Use secure communication protocols like HTTPS or SSL/TLS to protect data during transmission. +- Store sensitive data generated on-device in secure locations, such as Keychain on iOS or Keystore on Android to prevent unauthorized access. +- Use strong authentication, role-based access controls, and validate user permissions to limit access to sensitive data. +- Prevent injection attacks by validating and sanitizing user input to ensure only valid data is stored. +- Use secure session tokens, set proper session timeouts, and securely store session data. +- Keep all libraries and dependencies up to date and apply security patches promptly. +- Monitor security advisories and platform updates to address emerging threats and vulnerabilities. +::: + +If you are using Firestore to store your data, be sure to configure the relevant Firestore security rules for your application. - [Firestore Security Rules](https://firebase.google.com/docs/firestore/security/get-started) -Use **secure storage** package to store sensitive data in Flutter. +For sensitive data generated on-device, use the **secure storage** package to store sensitive data in Flutter. - [Secure Storage](https://pub.dev/packages/flutter_secure_storage) -More information on _M9: Insecure Data Storage_ [here.](https://owasp.org/www-project-mobile-top-10/2023-risks/m9-insecure-data-storage.html) - -- **M10: Insufficient Cryptography**: Threat agents exploiting insecure cryptography in mobile apps aim to compromise the confidentiality, integrity, and authenticity of sensitive information. They include attackers targeting cryptographic algorithms or implementations to decrypt sensitive data, malicious insiders manipulating processes or exposing encryption keys, state-sponsored actors conducting cryptanalysis for intelligence gathering, cybercriminals exploiting weak encryption for data theft or financial fraud, and attackers leveraging vulnerabilities in cryptographic protocols or libraries. Mitigating these risks requires robust cryptographic practices and secure implementation. +For more information on _Insecure Data Storage_, [refer to the OWASP guide.](https://owasp.org/www-project-mobile-top-10/2023-risks/m9-insecure-data-storage.html) - - **How to prevent it?**: - To prevent vulnerabilities in mobile app cryptography, implement best practices like using strong and widely accepted encryption algorithms such as AES, RSA, or ECC, ensuring key lengths adhere to industry standards for strong cryptographic protection, and following secure key management practices by storing keys securely in key vaults or hardware security modules. Encryption and decryption processes should utilize established libraries to avoid errors associated with custom implementations. Encryption keys must be securely stored using operating system-provided mechanisms or hardware-based options and should not be stored in plain text. - Use secure transport protocols like HTTPS with proper certificate validation to protect data in transit. Validate and authenticate the integrity and authenticity of encryption processes using certificates or digital signatures. Regular updates to cryptographic components are essential to mitigate vulnerabilities, supported by security testing such as vulnerability assessments and penetration testing. Follow industry standards and best practices from organizations like NIST and IETF. - Adopt strong hash functions like SHA-256 or bcrypt, apply salting to hashed passwords to defend against precomputed attack tables, and use Key Derivation Functions like PBKDF2 or scrypt to strengthen password-based cryptography and resist brute-force attacks. +### Insufficient cryptography -This article talks about cryptography in Flutter and how to use it. +Threat agents exploiting insecure cryptography in mobile apps aim to compromise the confidentiality, integrity, and authenticity of sensitive information. They include attackers targeting cryptographic algorithms or implementations to decrypt sensitive data, malicious insiders manipulating processes or exposing encryption keys, state-sponsored actors conducting cryptanalysis for intelligence gathering, cybercriminals exploiting weak encryption for data theft or financial fraud, and attackers leveraging vulnerabilities in cryptographic protocols or libraries. Mitigating these risks requires robust cryptographic practices and secure implementation. -- [Cryptography in Flutter](https://medium.com/flutterdevs/cryptography-in-flutter-7b3b1e3b3b3b) +:::tip +- Use strong and widely accepted encryption algorithms such as AES-256, RSA, or ECC, ensuring key lengths adhere to industry standards for strong cryptographic protection. +- Follow secure key management practices by storing keys securely in key vaults and making use of hardware security modules for trusted access. +- Encryption and decryption processes should utilize established, peer-reviewed libraries to avoid errors associated with custom implementations, as implementing cryptography correctly is incredibly difficult to do and new vulnerabilities are continually identified, even in major projects. +- Encryption keys must be securely stored using operating system-provided mechanisms or hardware-based options and should not be stored in plain text. +- Use secure transport protocols like HTTPS with proper certificate validation to protect data in transit. +- Validate and authenticate the integrity and authenticity of encryption processes using certificates or digital signatures. Regular updates to cryptographic components are essential to mitigate vulnerabilities, supported by security testing such as vulnerability assessments and penetration testing. Follow industry standards and best practices from organizations like NIST and IETF. +- Adopt strong hash functions like SHA-256 or bcrypt, apply salting to hashed passwords to defend against precomputed attack tables, and use _key derivation functions_ like _PBKDF2_ or _scrypt_ to strengthen password-based cryptography and harden your application against brute-force attacks. +::: -In this article, the author focused on using the **crypto** package to add more security to the application. +Check out the following guides for hardening your app's cryptography: +- [Cryptography in Flutter](https://medium.com/flutterdevs/cryptography-in-flutter-7b3b1e3b3b3b) - [Unlocking Secure Flutter Apps: A Guide to Building with Dart's Cryptography](https://30dayscoding.com/blog/building-flutter-apps-with-darts-cryptography) - [Crypto Package](https://pub.dev/packages/crypto) -More information on _M10: Insufficient Cryptography_ [here.](https://owasp.org/www-project-mobile-top-10/2023-risks/m10-insufficient-cryptography.html) +For more information on _Insufficient Cryptography_, [refer to the OWASP guide.](https://owasp.org/www-project-mobile-top-10/2023-risks/m10-insufficient-cryptography.html) ## OWASP MAS Checklist -The **OWASP Mobile Application Security (MAS) Checklist** is a comprehensive guide to securing mobile apps against common security threats. The checklist will provide you with a detailed list of security best practices, including secure coding guidelines, secure data storage, secure communication, and secure authentication mechanisms, so if you are interested in increasing the security of the above points, this will be a good starting point. -You can find the OWASP MAS checklist here [here.](https://mas.owasp.org/checklists/) +The [**OWASP Mobile Application Security (MAS) Checklist**](https://mas.owasp.org/checklists/) is a comprehensive guide to securing mobile apps against common security threats. The checklist will provide you with a detailed list of security best practices, including secure coding guidelines, secure data storage, secure communication, and secure authentication mechanisms. ## Other OWASP Resources From be62e59cb65fcf98480ba4bf2ab905e33f818e61 Mon Sep 17 00:00:00 2001 From: Joanna May Date: Thu, 23 Jan 2025 11:17:51 -0600 Subject: [PATCH 5/8] fix: formatting --- cspell.json | 13 ++----- .../docs/security/security_in_mobile_apps.mdx | 35 ++++++++++++------- 2 files changed, 24 insertions(+), 24 deletions(-) diff --git a/cspell.json b/cspell.json index 5df332b..bcd3c84 100644 --- a/cspell.json +++ b/cspell.json @@ -1,17 +1,8 @@ { "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json", "version": "0.2", - "ignorePaths": [ - "node_modules/**", - ".**/" - ], - "files": [ - "**/*.md", - "**/*.mdx", - "**/*.tsx", - "**/*.ts", - "**/*.json" - ], + "ignorePaths": ["node_modules/**", ".**/"], + "files": ["**/*.md", "**/*.mdx", "**/*.tsx", "**/*.ts", "**/*.json"], "words": [ "ABAP", "Abuild", diff --git a/src/content/docs/security/security_in_mobile_apps.mdx b/src/content/docs/security/security_in_mobile_apps.mdx index e8befb9..54c2f65 100644 --- a/src/content/docs/security/security_in_mobile_apps.mdx +++ b/src/content/docs/security/security_in_mobile_apps.mdx @@ -3,7 +3,7 @@ title: Security in Mobile Apps description: Mobile app security threats and how to protect your app using OWASP Mobile's 10 best practices. --- -Mobile app security is a critical concern for developers and users alike. The [Open Web Application Security Project (OWASP)](https://owasp.org/) maintains industry-accepted mobile application security guidelines that should be followed when building multiplatform mobile applications. +Mobile app security is a critical concern for developers and users alike. The [Open Web Application Security Project (OWASP)](https://owasp.org/) maintains industry-accepted mobile application security guidelines that should be followed when building multiplatform mobile applications. :::danger By far, the most common security threat is **social engineering**. Be sure to educate your team and create well-defined trust structures which require face-to-face confirmation for any proposed changes that affect security. @@ -52,7 +52,7 @@ The **Open Worldwide Application Security Project (OWASP)** is a globally recogn ### OWASP Mobile Top 10 Security Risks in 2024 -The OWASP Mobile Top 10 is a list of the most critical security risks for mobile apps and is updated periodically to reflect emerging threats and trends. +The OWASP Mobile Top 10 is a list of the most critical security risks for mobile apps and is updated periodically to reflect emerging threats and trends. The latest version, OWASP Mobile Top 10 2024, highlights the following risks: @@ -72,10 +72,11 @@ Instead of shipping sensitive API keys in your app, create a microservice or clo ::: :::tip + - , Use the Android Keystore or iOS Keychain to store sensitive user information. - Use strong encryption and hashing algorithms during credential storage and transmission. - Avoid weak authentication mechanisms, including common/weak passwords or insecure authentication flows. -::: + ::: [Dart-crypt](https://github.com/hoylen/dart-crypt) allows you to salt and hash passwords easily. @@ -90,13 +91,14 @@ For more information on _Improper Credential Usage_, [refer to the OWASP guide]( Attackers can exploit vulnerabilities in the mobile app supply chain, such as inserting malicious code during development or exploiting flaws in third-party libraries, SDKs, or hardcoded credentials. :::tip + - Leverage human-led code review (with automated tests, checks and analyzers). - Ensure secure app signing and distribution to block malicious actors. Services like [Codemagic](https://codemagic.io/) can drastically simplify the code-signing process. - Use trusted, validated third-party libraries to minimize risks. - Implement a process that requires both a human and an automated vulnerability checker (such as dependabot) to review package updates and patches in your codebase. - Stay up-to-date on supply chain incidents and open source package vulnerabilities. - Carefully scan pull requests on your open source projects — many open source projects have accidentally merged malicious code by accident. -::: + ::: You can check the [Software supply chain security for Flutter and its ecosystem video](https://www.youtube.com/watch?v=7LFftXcw1jA) from the Flutter Forward 2023 conference. @@ -108,8 +110,8 @@ For more information on _Inadequate Supply Chain Security_, [refer to the OWASP Threat agents that exploit authentication and authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools. - :::tip + - Use server-side authentication. - Encrypt local data. - Use device-specific tokens instead of storing passwords or using weak identifiers. @@ -118,7 +120,7 @@ Threat agents that exploit authentication and authorization vulnerabilities typi - Enforce all controls server-side; assume client-side can be bypassed. - Use biometrics (FaceID, TouchID) for secure access to sensitive data. - Perform local integrity checks if offline functionality is necessary. -::: + ::: For more on data safety, check out the [Encryption and Decryption in Flutter](https://medium.com/@laithalsahore19/explore-encrypt-decrypt-data-in-flutter-e1e64c86b0ee) overview. @@ -131,11 +133,12 @@ For more information on _Insecure Authentication/Authorization_, [refer to the O Insufficient validation and sanitization of user inputs or network data in mobile apps can lead to critical vulnerabilities, including SQL injection, command injection, and XSS attacks. :::tip + - Use strict input validation, set length limits, and reject unexpected or malicious input. - Sanitize output to prevent XSS (cross-site scripting). - Use parameterized queries to block SQL injection. - Work with external security vendors which can evaluate and test your application and its servers. -::: + ::: Use the [Formz](https://pub.dev/packages/formz) package to validate forms in Flutter and prevent incorrect data to be sent to the backend. @@ -152,13 +155,14 @@ When creating an app, assume threats can originate from any of the following: - Malware on the mobile device itself. :::tip + - Use SSL/TLS for all data transmissions to backend services and third-party entities and avoid mixed SSL sessions. - Only accept certificates signed by trusted certificate authorities (CA's) and never allow expired or mismatched certificates. - Use current, industry accepted encryption algorithms with appropriate key lengths (AES-128 is a good start). Encryption algorithms are subject to mathematical analysis: some older algorithms have been identified by mathematicians and experts as being easier to exploit. - Pin certificates and require SSL chain verification. - Never transmit sensitive data via unencrypted channels (like SMS or via push notifications). - During security testing, conduct traffic analysis to verify no plaintext data transmissions. -::: + ::: If you're using Firebase, you can implement [Firebase App Check](https://firebase.google.com/docs/app-check) to protect your backend from unauthorized clients accessing it. @@ -175,11 +179,12 @@ Privacy controls are concerned with protecting personally identifiable informati This information is valuable to attackers for a number of reasons. For example, an attacker could impersonate the victim to commit fraud, misuse the victim's payment details, blackmail the victim with sensitive information, or harm the victim by destroying or tampering with their critical data. :::tip + - The best way to prevent privacy violations is to minimize the collection and processing of Personally Identifiable Information (PII). This requires a full understanding of the app's PII usage. - Evaluate whether all personally identifiable information is necessary, whether less sensitive alternatives can be used, or whether personally identifiable information can be reduced, anonymized, or deleted after a certain period. Allow users to consent to the optional use of personally identifiable information with clear awareness of the associated risks. - Store or transfer PII only when absolutely necessary, with strict authentication and authorization controls. Secure personal data, such as encrypting health information with device TPM keys to protect against sandbox bypasses. - Threat modeling can identify the most likely privacy risks, focusing security efforts accordingly. Use static and dynamic security tools to uncover vulnerabilities like improper logging or accidental data leakage. -::: + ::: For more information on _Inadequate Privacy Controls_, [refer to the OWASP guide.](https://owasp.org/www-project-mobile-top-10/2023-risks/m6-inadequate-privacy-controls.html) @@ -188,11 +193,12 @@ For more information on _Inadequate Privacy Controls_, [refer to the OWASP guide Attackers target app binaries to extract valuable secrets like API keys or cryptographic secrets, access critical business logic or pre-trained AI models, or investigate weaknesses in backend systems. They may also manipulate binaries to access paid features for free, bypass security checks, or insert malicious code. Repackaging attacks can exploit unsuspecting users, such as modifying payment identifiers and redistributing compromised apps to divert payments to attackers. Protecting app binaries is crucial to prevent data theft, fraud, and malicious exploitation. :::tip + - Apps should only access the minimal information needed to function, as all data in the binary is vulnerable to leaks or manipulation. - Use obfuscation tools to make binaries incomprehensible. Native compilation, interpreters, or nested virtual machines can further complicate reverse engineering Test obfuscation quality using reverse-engineering tools. - Obfuscation makes skipping security checks harder. Reinforce local security checks through backend validation and implement integrity checks to detect code tampering, though attackers may still bypass local checks. - Integrity checks at app launch can detect unauthorized modifications and redistribution. Violations can be reported to remove fake apps from stores, and specialized services are available to support detection and removal efforts. -::: + ::: Tools and services such as FreeRASP and Aproov can help mitigate the likelihood of a compromised app binary or repackaging attack. @@ -217,6 +223,7 @@ More information on _Insufficient Binary Protection_, [refer to the OWASP guide. Security misconfiguration occurs when mobile apps have improperly configured security settings, permissions, or controls, leading to vulnerabilities and unauthorized access. Threat agents, such as attackers with physical device access or malicious apps, exploit these weaknesses to access sensitive data or execute unauthorized actions within the vulnerable app's context. Proper configuration is crucial to mitigate these risks. :::tip + - Ensure default settings do not expose sensitive data or unnecessary permissions. - Do not use hardcoded credentials. - Request only necessary permissions for the app's functionality. @@ -224,7 +231,7 @@ Security misconfiguration occurs when mobile apps have improperly configured sec - Turn off debugging features in production apps. - Prevent app data from being included in device backups. - Only export activities, content providers, and services that are required. -::: + ::: :::caution Don't add permissions that are not necessary for the app to work. It's easy for an attacker to exploit these permissions to gain access to sensitive data. @@ -239,6 +246,7 @@ For more information on _Security Misconfiguration_, [refer to the OWASP guide.] Insecure data storage in mobile apps exposes sensitive information to various threat agents, including skilled attackers, malicious insiders, state-sponsored actors, cybercriminals, script kiddies, data brokers, competitors, and activists. These agents exploit vulnerabilities like weak encryption, insecure storage, and improper handling of credentials. :::tip + - Employ robust encryption algorithms to protect data at rest and in transit, such as AES-256. - Use secure communication protocols like HTTPS or SSL/TLS to protect data during transmission. - Store sensitive data generated on-device in secure locations, such as Keychain on iOS or Keystore on Android to prevent unauthorized access. @@ -247,7 +255,7 @@ Insecure data storage in mobile apps exposes sensitive information to various th - Use secure session tokens, set proper session timeouts, and securely store session data. - Keep all libraries and dependencies up to date and apply security patches promptly. - Monitor security advisories and platform updates to address emerging threats and vulnerabilities. -::: + ::: If you are using Firestore to store your data, be sure to configure the relevant Firestore security rules for your application. @@ -264,6 +272,7 @@ For more information on _Insecure Data Storage_, [refer to the OWASP guide.](htt Threat agents exploiting insecure cryptography in mobile apps aim to compromise the confidentiality, integrity, and authenticity of sensitive information. They include attackers targeting cryptographic algorithms or implementations to decrypt sensitive data, malicious insiders manipulating processes or exposing encryption keys, state-sponsored actors conducting cryptanalysis for intelligence gathering, cybercriminals exploiting weak encryption for data theft or financial fraud, and attackers leveraging vulnerabilities in cryptographic protocols or libraries. Mitigating these risks requires robust cryptographic practices and secure implementation. :::tip + - Use strong and widely accepted encryption algorithms such as AES-256, RSA, or ECC, ensuring key lengths adhere to industry standards for strong cryptographic protection. - Follow secure key management practices by storing keys securely in key vaults and making use of hardware security modules for trusted access. - Encryption and decryption processes should utilize established, peer-reviewed libraries to avoid errors associated with custom implementations, as implementing cryptography correctly is incredibly difficult to do and new vulnerabilities are continually identified, even in major projects. @@ -271,7 +280,7 @@ Threat agents exploiting insecure cryptography in mobile apps aim to compromise - Use secure transport protocols like HTTPS with proper certificate validation to protect data in transit. - Validate and authenticate the integrity and authenticity of encryption processes using certificates or digital signatures. Regular updates to cryptographic components are essential to mitigate vulnerabilities, supported by security testing such as vulnerability assessments and penetration testing. Follow industry standards and best practices from organizations like NIST and IETF. - Adopt strong hash functions like SHA-256 or bcrypt, apply salting to hashed passwords to defend against precomputed attack tables, and use _key derivation functions_ like _PBKDF2_ or _scrypt_ to strengthen password-based cryptography and harden your application against brute-force attacks. -::: + ::: Check out the following guides for hardening your app's cryptography: From b50fc45f299a8859e9d48b973227a8d79177323d Mon Sep 17 00:00:00 2001 From: Joanna May Date: Thu, 23 Jan 2025 11:19:47 -0600 Subject: [PATCH 6/8] fix: spelling --- cspell.json | 16 +++++++++++++--- .../docs/security/security_in_mobile_apps.mdx | 2 +- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/cspell.json b/cspell.json index bcd3c84..f2424b1 100644 --- a/cspell.json +++ b/cspell.json @@ -1,10 +1,20 @@ { "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json", "version": "0.2", - "ignorePaths": ["node_modules/**", ".**/"], - "files": ["**/*.md", "**/*.mdx", "**/*.tsx", "**/*.ts", "**/*.json"], + "ignorePaths": [ + "node_modules/**", + ".**/" + ], + "files": [ + "**/*.md", + "**/*.mdx", + "**/*.tsx", + "**/*.ts", + "**/*.json" + ], "words": [ "ABAP", + "Approov", "Abuild", "Agda", "AMPL", @@ -123,4 +133,4 @@ "Zephir", "Zimpl" ] -} +} \ No newline at end of file diff --git a/src/content/docs/security/security_in_mobile_apps.mdx b/src/content/docs/security/security_in_mobile_apps.mdx index 54c2f65..5d2e226 100644 --- a/src/content/docs/security/security_in_mobile_apps.mdx +++ b/src/content/docs/security/security_in_mobile_apps.mdx @@ -200,7 +200,7 @@ Attackers target app binaries to extract valuable secrets like API keys or crypt - Integrity checks at app launch can detect unauthorized modifications and redistribution. Violations can be reported to remove fake apps from stores, and specialized services are available to support detection and removal efforts. ::: -Tools and services such as FreeRASP and Aproov can help mitigate the likelihood of a compromised app binary or repackaging attack. +Tools and services such as FreeRASP and Approov can help mitigate the likelihood of a compromised app binary or repackaging attack. - [Approov](https://approov.io/docs/latest/approov-usage-documentation/) - [FreeRASP](https://pub.dev/packages/freerasp) From 1b6853bf856a5809c417bead66eeb9377b107ce7 Mon Sep 17 00:00:00 2001 From: Joanna May Date: Thu, 23 Jan 2025 11:21:47 -0600 Subject: [PATCH 7/8] fix: formatting --- cspell.json | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/cspell.json b/cspell.json index f2424b1..9d5c58d 100644 --- a/cspell.json +++ b/cspell.json @@ -1,17 +1,8 @@ { "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json", "version": "0.2", - "ignorePaths": [ - "node_modules/**", - ".**/" - ], - "files": [ - "**/*.md", - "**/*.mdx", - "**/*.tsx", - "**/*.ts", - "**/*.json" - ], + "ignorePaths": ["node_modules/**", ".**/"], + "files": ["**/*.md", "**/*.mdx", "**/*.tsx", "**/*.ts", "**/*.json"], "words": [ "ABAP", "Approov", @@ -133,4 +124,4 @@ "Zephir", "Zimpl" ] -} \ No newline at end of file +} From 89306f200e2baed06b2591f13c070e3c54d419be Mon Sep 17 00:00:00 2001 From: Joanna May Date: Fri, 24 Jan 2025 14:02:42 -0600 Subject: [PATCH 8/8] fix: typo --- src/content/docs/security/security_in_mobile_apps.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/security/security_in_mobile_apps.mdx b/src/content/docs/security/security_in_mobile_apps.mdx index 5d2e226..92fdef8 100644 --- a/src/content/docs/security/security_in_mobile_apps.mdx +++ b/src/content/docs/security/security_in_mobile_apps.mdx @@ -73,7 +73,7 @@ Instead of shipping sensitive API keys in your app, create a microservice or clo :::tip -- , Use the Android Keystore or iOS Keychain to store sensitive user information. +- Use the Android Keystore or iOS Keychain to store sensitive user information. - Use strong encryption and hashing algorithms during credential storage and transmission. - Avoid weak authentication mechanisms, including common/weak passwords or insecure authentication flows. :::