Mobile App Security – Developer Tips

Developing hybrid mobile apps to work in both online-offline mode exposed me to security flaws/loopholes in android system, that needs to be considered in mobile app. Recommend a visit to Open Web Application Security Project (OWASP) for tips to improve the security

Here are pointers that i noted specific to mobile over time. To start with I recommend an approach to security flaws in mobile app to be holistic and wholesome. Identify all possible areas of application attack, including client application, API back-end, server and database related vulnerabilities. An entry point at any of these places may cause a threat to the whole application/it’s data. Are you sure that there is no security vulnerability in code connecting with API back-end(social network)?

Mobile application may unintentionally leak sensitive data to attacker. One Commonly observes that developers leave private key in plain form in source code after implementing cryptography to safeguard data. .

  • Ensure that code used for logging during development phase does not have data that make application prone to leaks.
  • Do not keep any sensitive data to be present as part of the code. Any attacker with access to the binary can decompile the app and view sensitive data in the source code.
  • When user copies sensitive data( ex: security answer) from the app, & place the data on device clipboard, data is available for copy (hacked) to other apps without knowledge of the first app.
  • Native apps can be easily reverse engineered and Java source code viewed. The attacker can see source code and any sensitive data hard-coded in the code. The hacker can modify the code in the app,re-compile it and distribute the apps in the third party markets.

Mobiles allow to store data at client side. Does your app stores sensitive ,confidential and private data on the device? An attacker with physical access to the device gains access to this data and can perform anything. A malicious app gains access to this data in a rooted/ Jailbroken device.  Be aware that data stored on SD card can be vulnerable as it is possible for other apps to read this data from the SD card.

  • Avoid storing private or sensitive data on SDCard.  To store data in SDCard, encrypt the data and keep it away from attacker’s control.
  • Please do not print sensitive information like username, password, web service URL, request or response, etc in the LogCat.
  • To  store app data across user sessions, choose Internal Storage  in private(Context.MODE_PRIVATE) mode. The created file can be accessed by calling application(or all apps sharing the same user ID).
  • Input validation is required in mobile applications. On no input validation is in place, the mobile app becomes source of security flaws for server code like SQL injection, Command Injection, Cross Site Scripting vulnerabilities.

App should expire sessions found inactive for a particular period of time, so that attackers cannot make malicious requests to the server. All requests should be time stamped on client side and expire after a period of time as defined on the server side. A shared secret known only by the client and server, used by the client to sign requests, prevents the server from accepting those that are  modified. Limit the amount of time a request is valid, as the longer a request is valid.

In Mobile Web app development,  WebView class has major role to display web pages as a part of activity layout and does not include navigation controls or an address bar. While WebView helps to display content from locally stored HTML or fetch HTML and other content from server, WebView and associated components needs to be restricted to access local data. Beware of major security concerns with setAllowFileAccess() and setAllowContentAccess() methods

Restrict Content Provider using exported flag set as false. It’s not the case that every time we develop Content Provider for data exchange between applications but Content Provider can be developed for single application or private.

Be aware of the safeguards that can be implemented for data Exchange that happens between activities of a app or between apps on the device.

  • Use LocalBroadcastManager for broadcast data within process/app. When you broadcast data, the data won’t leave your app, there is no worry about leaking private data. Do not pass sensitive information through Broadcast & Intent.
  • Prior to processing Intent received by onReceive() method of BroadcastReceiver, program needs to validate the caller’s package name, action and other related information. When permission attribute is set, the receiver gets protected. Only broadcasters who are granted this permission (by requesting it with the <uses-permission> tag in their AndroidManifest.xml) will be able to send Intent to the receiver and this helps to secure the android application from malicious intents.
  • Set exported flag as false if the activity is only for the internal use of the application. <activity android:name=”view.MyActivity” android:exported=”false”> </activity>

Precautions related to Server Requests

Servers connected to mobile application should treat every request from the application as a possible attack and should confirm the authenticity of every request. All communications via app should be safeguarded to prevent attackers from reading wireless communications.

  • Verify for special characters in input of mobile app to help in preventing XSS attack.
  • URLEncode and HTMLEncode can be used to encode the output data received as input.

To end, today one sees new innovations around reward points and mobile wallets. This may not involve integrating with payment gateway of banks that demand highest level of security. Still, Do not make them easy to break and steal.  Any leak in areas(like rewards) has significant impact on the app branding.  Ensure that code working with mobile wallet adheres to security guidelines, similar to money related transactions.