-
Notifications
You must be signed in to change notification settings - Fork 28
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
85 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,85 @@ | ||
# Owasp checklist mobile security | ||
|
||
## V1 - Arcitechture, design, threat modelling | ||
|
||
* [ ] Verify all application components are identified and are known to be needed. | ||
* [ ] Verify that security controls are never enforced only on the client side, but on the respective remote endpoints. | ||
* [ ] Verify that a high-level architecture for the mobile app and all connected remote services has been defined and security has been addressed in that architecture. | ||
* [ ] Verify that data considered sensitive in the context of the mobile app is clearly identified. | ||
* [ ] Verify all app components are defined in terms of the business functions and/or security functions they provide. | ||
* [ ] Verify that a threat model for the mobile app and the associated remote services, which identifies potential threats and countermeasures, has been produced. | ||
* [ ] Verify that all security controls have a centralized implementation. | ||
* [ ] Verify that there is an explicit policy for how cryptographic keys (if any) are managed, and the lifecycle of cryptographic keys is enforced. Ideally, follow a key management standard such as NIST SP 800-57. | ||
* [ ] Verify that a mechanism for enforcing updates of the mobile app exists. | ||
* [ ] Verify that security is addressed within all parts of the software development lifecycle. | ||
|
||
## V2 - Data storage and Privacy | ||
|
||
* [ ] Verify that system credential storage facilities are used appropriately to store sensitive data, such as PII, user credentials or cryptographic keys. | ||
* [ ] Verify that no sensitive data is stored outside of the app container or system credential storage facilities. | ||
* [ ] Verify that no sensitive data is written to application logs. | ||
* [ ] Verify that no sensitive data is shared with third parties unless it is a necessary part of the architecture. | ||
* [ ] Verify that the keyboard cache is disabled on text inputs that process sensitive data. | ||
* [ ] Verify that no sensitive data is exposed via IPC mechanisms. | ||
* [ ] Verify that no sensitive data, such as passwords or pins, is exposed through the user interface. | ||
* [ ] Verify that no sensitive data is included in backups generated by the mobile operating system. | ||
* [ ] Verify that the app removes sensitive data from views when backgrounded. | ||
* [ ] Verify that the app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use. | ||
* [ ] Verify that the app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode. | ||
* [ ] Verify that the app educates the user about the types of personally identifiable information processed, as well as security best practices the user should follow in using the app. | ||
|
||
## V3 - Cryptography | ||
|
||
* [ ] Verify that the app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption. | ||
* [ ] Verify that the app uses proven implementations of cryptographic primitives. | ||
* [ ] Verify that the app uses cryptographic primitives that are appropriate for the particular use-case, configured with parameters that adhere to industry best practices. | ||
* [ ] Verify that the app does not use cryptographic protocols or algorithms that are widely considered depreciated for security purposes. | ||
* [ ] Verify that the app doesn't re-use the same cryptographic key for multiple purposes. | ||
* [ ] Verify that all random values are generated using a sufficiently secure random number generator. | ||
|
||
## V4 - Authentication and Session Management | ||
|
||
* [ ] Verify that if the app provides users with access to a remote service, an acceptable form of authentication such as username/password authentication is performed at the remote endpoint. | ||
* [ ] Verify that the remote endpoint uses randomly generated session identifiers, if classical server side session management is used, to authenticate client requests without sending the user's credentials. | ||
* [ ] Verify that the remote endpoint uses server side signed tokens, if stateless authentication is used, to authenticate client requests without sending the user's credentials. | ||
* [ ] Verify that the remote endpoint terminates the existing session when the user logs out. | ||
* [ ] Verify that a password policy exists and is enforced at the remote endpoint. | ||
* [ ] Verify that the remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. | ||
* [ ] Verify that sessions are terminated at the remote endpoint or tokens expire after a predefined period of inactivity. | ||
* [ ] Verify that biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain/keystore. | ||
* [ ] Verify that a second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced. | ||
* [ ] Verify that step-up authentication is required to enable actions that deal with sensitive data or transactions. | ||
* [ ] Verify that the app informs the user of all login activities with his or her account. Users are able view a list of devices used to access the account, and to block specific devices. | ||
|
||
|
||
## V5 - Network Communication | ||
|
||
* [ ] Verify that data is encrypted on the network using TLS. The secure channel is used consistently throughout the app. | ||
* [ ] Verify that the app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a valid CA are accepted. | ||
- Generate self-signed certificate and and make burp use that. | ||
|
||
* [ ] Verify that the app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if signed by a trusted CA. | ||
* [ ] Verify that the app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery. | ||
* [ ] Verify that the app only depends on up to date connectivity- and security libraries. | ||
|
||
## V6 - Platform Interaction | ||
|
||
* [ ] Verify that the app only requires the minimum set of permissions necessary. | ||
* [ ] Verify that all inputs from external sources and the user are validated and if necessary sanitized. This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and network sources. | ||
* [ ] Verify that the app does not export sensitive functionality via custom URL schemes, unless these mechanisms are properly protected. | ||
* [ ] Verify that the app does not export sensitive functionality through IPC facilities, unless these mechanisms are properly protected. | ||
* [ ] Verify that JavaScript is disabled in WebViews unless explicitly required. | ||
* [ ] Verify that WebViews are configured to allow only the minimum set of protocol handlers required (ideally, only https). Potentially dangerous handlers, such as file, tel and app-id, are disabled. | ||
* [ ] If native methods of the app are exposed to a WebView, verify that the WebView only renders JavaScript contained within the app package. | ||
* [ ] Verify that object serialization, if any, is implemented using safe serialization APIs. | ||
|
||
## V7 - Code Quality and Build Settings | ||
* [ ] Verify that the app is signed and provisioned with valid certificate. | ||
* [ ] Verify that the app has been built in release mode, with settings appropriate for a release build (e.g. non-debuggable). | ||
* [ ] Verify that debugging symbols have been removed from native binaries. | ||
* [ ] Verify that debugging code has been removed, and the app does not log verbose errors or debugging messages. | ||
* [ ] Verify that all third party components used by the mobile app, such as libraries and frameworks, are identified, and checked for known vulnerabilities. | ||
* [ ] Verify that the app catches and handles possible exceptions. | ||
* [ ] Verify that error handling logic in security controls denies access by default. | ||
* [ ] Verify that in unmanaged code, memory is allocated, freed and used securely. | ||
* [ ] Free security features offered by the toolchain, such as byte-code minification, stack protection, PIE support and automatic reference counting, are activated. |