As we all know that over the last few years mobile is a great source of business which leads to the existence of Mobile Apps. Nowadays if we look to the products then we will find that all products have their mobile apps too. So to make the app bug free and to provide users a great experience it is required for testers to follow certain checklist so that they can cover all the cases.
The below checklist will help the testers to test the app thoroughly, effectively and efficiently.
Insecure Data Storage
Insufficient Transport Layer Protection
Unintended Data Leakage
Poor Authorization and Authentication
Client Side Injection
Security Decisions via Untrusted Inputs
Improper Session Handling
Lack of Binary Protections
1. Insecure Data Storage:
Basically, Insecure data storage uncertainty occurs when development teams assume that users or malware will not have access to a mobile device’s file system and sensitive information stored on the device whereas Filesystems are easily accessible. Organizations should look for a malicious user or malware to inspect sensitive data stores. When data is not protected properly, specialized tools are all that is needed to view application data. To protect the data app should not be installed on “Rooted” device or “jailbroken” device.
Checklist to Test Insecure Data:-
- SQLite Databases
- Log Files
- SD Card
- XML Data Stores or Manifest Files
- Binary data stores
- Cookie stores
2. Insufficient Transport Layer Protection:
Mobile applications do not protect network traffic all the time. They may use SSL/TLS during authentication. This inconsistency leads to the risk of exposing data and session IDs to interception.
Checklist to test for sufficient transport layer protection:-
- Check that all connections(not only the ones you own), to servers are properly encrypted?
- Check that the SSL certificates are in date.
- Check whether the SSL certificates are self-signed or not.
- Check that the SSL is using high enough cipher strengths.
- Will your application accept user accepted certificates as authorities?
3. Unintended Data Leakage:
Unintended data leakage occurs when a developer accidentally places sensitive information or data in a location on the mobile device which is easily accessible by other apps on the device. It is easy to detect data leakage by inspecting all mobile device locations that are accessible to all apps for the app’s sensitive information. To protect the data from unintended leakage check whether any inappropriate data save on device while operating app.
4. Poor Authorization and Authentication:
Poor or missing authentication schemes allow a hacker to anonymously execute functionality within the mobile app or backend server used by the mobile app. Input factor like Form can be the main reason for Weaker authentication of mobile apps. The form factor highly encourages short passwords that are often purely based on 4-digit PINs.
Checklist to Test for Poor Authentication:-
- Wherever possible ensure that all authentication requests are performed on server-side. Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication.
- Check that if client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials.
- Check that mobile application should utilize a device-specific authentication token that can be nullified within the mobile application by the user. This will ensure that the app can reduce unauthorized access from a stolen/lost device.
5. Broken Cryptography:
In order to utilize this weakness, a hacker must successfully return encrypted code or sensitive data to its original unencrypted form due to weak encryption algorithms or flaws within the encryption process.
Checklist to Test for Broken Cryptography:-
- Check that the mobile app use a process behind the encryption/decryption that is fundamentally distorted and can be exploited by the hacker to decrypt sensitive data.
- Check that, the mobile app implements an encryption/decryption algorithm that is weak in nature and can be directly decrypted by the hacker.
6. Client Side Injection:
Client-side injection results in the execution of malicious code on the mobile device via the mobile app. Typically, this malicious code is provided in the form of data that the hacker inputs to the mobile app through different means. The data is malformed and is processed (like all other data) by the underlying frameworks supporting the mobile app. During processing, this special data forces a context switch and the framework reinterprets the data as executable code. The code is malicious in nature and executed by the app.
Checklist to test for Client Side Injection:-
- To identify whether an application is vulnerable to injection is the find the sources of input and validate that user/application supplied data is being subject to input validation, disallowing code injection.
- Another way to check whether the application is handling data correctly is to check the code using Code Analysis Tools. Code analysis tools can help a security analyst to find the use of interpreters and trace the data flow through the application.
- Another way is Manual penetration testers can also confirm these issues by crafting exploits(attacks using third-party tools or manually) that confirm the vulnerability.
7. Security Decisions via Untrusted Inputs:
Developers generally use hidden fields and values or any hidden functionality to distinguish higher level users from lower level users. An attacker can intercept the calls (IPC or web service calls) and temper with such sensitive parameters. Weak implementation of such functionalities leads to improper behavior of an app and even granting higher level permissions to an attacker.This can easily be exploited through hooking functionality.
Checklist to Test for Security decision via untrusted inputs:-
- Check that if there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications.
- Check that sensitive actions which are triggered by IPC entry points should require user interaction before performing the action.
- Check that all input received from IPC entry points must undergo stringent (authorized regulations) input validation in order to prevent input driven attacks.
- Check that any sensitive information is not passed through IPC mechanisms, as it may be susceptible to being read by third-party applications under certain scenarios.
8. Improper Session Handling:
Improper session handling occurs when the session token is unintentionally shared with the hacker during a subsequent transaction between the mobile app and the backend servers.
Checklist for test for Improper session handling:-
- Timeout protection- Check that any mobile app you create must have adequate timeout protection on the backend components. This helps to prevent the malicious potential for an unauthorized user to gain access to an existing session and assume the role of that user.
- High-security applications should be given 15 minutes Timeout Protection.
- Medium-security applications should be given 30 minutes Timeout Protection.
- Low-security applications should be given 1-hour Timeout Protection.
2. Properly Rotate Cookies- Another major problem with session management implementations is the failure to properly reset cookies during authentication state changes. Authentication state changes include events like:
- Switching from an anonymous user to a logged in user
- Switching from any logged in user to another logged in user
- Switching from a regular user to a privileged user
3. Insecure Token Creation- In addition to properly disapprove tokens (on the server side) during key application events, it’s also crucial that the tokens themselves are generated properly. Just as with encryption algorithms, developers should use well-established and industry-standard methods of created tokens.
9. Lack of Binary Protections:
However, an application with binary protection can still be reversed by a dedicated hacker and therefore binary protection is not a perfect security solution. At the end of the day, binary protection only slows down a security review.
Checklist for test for Binary protection:-
- Check that can anyone code-decrypt this app (iPhone specific) using an automated tool like ClutchMod or manually using GDB?
- Check that can anyone reverse engineer this app (Android specific) using an automated tool like dex2jar?
- Check that can anyone use an automated tool like Hopper or IDA Pro to easily visualize the control-flow and pseudo-code of this app?
- Check that can anyone modify the app’s binary executable using a hex editor to get it to bypass a security control?