Apple iOS Mobile Application Security - Best Practices

Page Visited: 2543

Read Time:7 Minute, 32 Second

Security in Smartphones:

In today’s world, security in smartphones is one of the most important elements for mobile companies. As people are almost completely dependent on technology, they deal with a lot of confidential and sensitive data such as banking, health, and personal information.

iOS is considered as one of the most secure operating systems developed by Apple, but that doesn’t mean the users neglect the practices for enhancing the security of the Apple devices.

To know more about What are OWASP Mobile TOP 10-2016 Vulnerabilities? | Its Security Risks & Prevention Techniques | Click Here – OWASP Mobile TOP 10-2016 Vulnerabilities

Top 10 Security Practices for iOS Mobile Application:

Below are the best practices and concrete techniques for iOS mobile application security:

Prime security concerns to be tested and validated in the iOS mobile application.

1. Weak Server Side Control

Mobile applications should not entirely rely on client-side validations as they can be bypassed very easily. Any entity that acts as a source of untrustworthy input to a backend API service, web service, or traditional web server application. Examples of such entities include a user, malware, or a vulnerable app on a mobile device.

2. Insecure Data Storage

It is important to threat-model your mobile app to understand the information assets it processes and how the underlying APIs handle those assets. These APIs should store sensitive information securely. Areas most often found with data being stored insecurely include the following:
• SQLite databases
• Log Files
• Plist Files
• XML Data Stores or Manifest Files
• Binary data stores
• Cookie stores
• SD Card
• Cloud synced

When applying encryption and decryption to sensitive information assets, malware may perform a binary attack on the app in order to steal encryption or decryption keys. Once it steals the keys, it will decrypt the local data and steal sensitive information.

What happens if the decision is lost/Stolen. Are we protecting our app’s data properly?

3. Insufficient Transport Layer Protection

We should know if all the connections are properly encrypted.
Sensitive data is transmitted using the GET method.
If using SSL, all SSL-related security checks like SSL Certificate validity, cipher strengths, etc.

4. Unintended Data Leakage

It is to be tested whether the application is handling below mentioned types of features properly or not.
• URL Caching (Both request and response)
• Keyboard Press Caching
• Copy/Paste buffer Caching
• Application backgrounding
• Logging
• HTML5 data storage
• Browser cookie objects
• Analytics data sent to 3rd parties
• The snapshots, when the application navigates from active to passive mode.

5. Poor Authorization and Authentication

• If you are porting a web application to its mobile equivalent, authentication requirements of mobile applications should match that of the web application component. Therefore, it should not be possible to authenticate with less authentication factors than the web browser.
• Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through run-time manipulation or modification of the binary. If there is a compelling business requirement for offline authentication.
• Where possible, ensure that all authentication requests are performed 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.
• 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. This will ensure that the stored application data will only be accessible upon successfully entering the correct credentials. There are additional risks that the data will be decrypted via binary attacks.
• Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device.
• Ideally, mobile applications should utilize a device-specific authentication token that can be revoked within the mobile application by the user. This will ensure that the app can mitigate unauthorized access from a stolen/lost device.
• Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-location.
• Persistent authentication within mobile applications should be implemented as opt-in and not be enabled by default.
• Developers should assume all client-side authorization and authentication controls can be bypassed by malicious users. Authorization and authentication controls must be re-enforced on the server-side whenever possible.
• Due to offline usage requirements, mobile apps may be required to perform local authentication or authorization checks within the mobile app’s code. If this is the case, developers should instrument local integrity checks within their code to detect any unauthorized code changes.

6. Broken Cryptography

6.1 Reliance Upon Built-In Code Encryption Processes
By default, iOS applications are protected (in theory) from reverse engineering via code encryption. The iOS security model requires that apps be encrypted and signed by trustworthy sources in order to execute in non-jailbroken environments. Upon start-up, the iOS app loader will decrypt the app in memory and proceed to execute the code after its signature has been verified by iOS. This feature, in theory, prevents an attacker from conducting binary attacks against an iOS mobile app.
6.2 Poor Key Management Processes
6.3 Creation and Use of Custom Encryption Protocols
6.4 Use of Insecure and/or Deprecated Algorithms

7. Client-Side Injection

SQLite Injection: When designing queries for SQLite be sure that user-supplied data is being passed to a parameterized query. This can be spotted by looking for the format specifier used. In general, dangerous user-supplied data will be inserted by a “%@” instead of a properly parameterized query specifier of “?”.

JavaScript Injection (XSS, etc): Ensure that all UIWebView calls do not execute without proper input validation. Apply filters for dangerous JavaScript characters if possible, using a whitelist over the blacklist character policy before rendering. If possible call mobile Safari instead of rending inside of UIWebkit which has access to your application.

Local File Inclusion: Use input validation for NSFileManager calls.

XML Injection: Use libXML2 over NSXMLParser.

Format String Injection: Several Objective C methods are vulnerable to format string attacks:
NSLog, [NSString stringWithFormat:], [NSString initWithFormat:], [NSMutableString appendFormat:], [NSAlert informativeTextWithFormat:], [NSPredicate predicateWithFormat:], [NSException format:], NSRunAlertPanel.
Do not let sources outside of your control, such as user data and messages from other applications or web services, control any part of your format strings.

Classic C Attacks: Objective C is a superset of C, avoid using old C functions vulnerable to injection such as strcat, strcpy, strncat, strncpy, sprint, vsprintf, gets, etc.

Moreover, client-side validations alone are not sufficient for the good security of an application, it should also have server-side validations implemented with whitelisting of various inputs.

8. Security Decisions Via Untrusted Inputs

If the mobile applications can accept data from all kinds of sources. In most cases, this will be an Inter-Process Communication (IPC) mechanism. In general, try and adhere to the following IPC design patterns:
• If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications.
• Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action
• All input received from IPC entry points must undergo stringent input validation in order to prevent input-driven attacks
• Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios.

9. Improper Session Handling

Failure to Invalidate Sessions on the backend
Lack of Adequate Timeout Protection
Failure to Properly Rotate Cookies
Insecure Token Creation

10. Lack of Binary Protections

It is a very important part of iOS app security where we will analyze and reverse engineer a mobile app’s code, then modify it to perform some hidden functionality.

Additional iOS Mobile Application Security Practices:

Apart from above mentioned top 10 mobile security issues, we also need to ensure about below-mentioned points.

Account Lockout Implemented or not
Application is Vulnerable to XSS – Proper encoding and validations should be present
Malicious File Upload
iOS snapshot/backgrounding Vulnerability
Application does not have Logout Functionality
Sensitive information in Application Log Files
Sensitive information sent as a query string parameter
Sensitive information in Memory Dump
Weak Password Policy
Autocomplete is not set to OFF
Application is accessible on Rooted or Jail Broken Device
Back-and-Refresh attack
Usage of Persistent Cookies
Improper exception Handling: In code
Insecure Application Permissions
Application build contains Obsolete Files
Operation on a resource after expiration or release
Cached Cookies or information not cleaned after application removal
Clipboard is not disabled
Use of Insecure and/or Deprecated Algorithms
Unencrypted Credentials in Databases (sqlite db)
Store sensitive information outside App Sandbox (on SDCard)
Store Encryption Key Locally/Store Sensitive Data in Cleartext
Direct Reference to internal resource without authentication
Improper Input Validation – Server Side
Detailed Error page shows internal sensitive information
Application allows HTTP Methods besides GET and POST
Cacheable HTTPS Responses
Path Attribute not set for a cookie
HttpOnly Attribute not set for a cookie
Secure Attribute not set for a cookie
Lack of Adequate Timeout Protection