As the general trend suggests use of mobile apps are on the rise day by day. More than half of all time spent of digital media is spent on mobile apps. The average time spent on mobile apps is increased by 21% over the past year. With the growing usage of mobile apps by users for all purposes such as banking, e-mails, payments; the focus of the malicious users has shifted towards the mobile apps too.
Source: https://www.arxan.com/resources/state-of-application-security/
Mobile apps provide ease of use and access. In order to stay competitive in the market and in a hurry to launch applications, often businesses do not pay attention to the security of the application. The infographic [2] below shows the amount budgeted for security by organizations.
The information Security Community is
trying to spread awareness for the same to make businesses realize the need for
securing mobile apps. This blog is one such effort to spread the awareness and
to guide on how to secure the mobile applications at the development level.
Source: https://www.arxan.com/resources/state-of-application-security/
Source: https://www.arxan.com/resources/state-of-application-security/
On a broader level Mobile applications
are affected by following top ten vulnerability classifications formulated by
OWASP.
The different controls which need to be
taken into account for securing mobile applications are discussed below. These
help is ensuring that security is implemented during development itself and is
not left as an added testing effort after the development.
- Increase Code Complexity and Use
Obfuscation -
As seen in the infographic above, Lack of Binary Protection is
the major vulnerability that is not addressed in majority of the mobile apps.
This has many implications. It is very easy to reverse engineer the original
java code (for android) and repackage the same for malicious purposes or to
gain competitive advantage. iOS applications can also be reverse engineered as
the application classes and protocols are stored within the object file. Reverse
engineering of apps can provide valuable insight into how the app works.
By making them more complex internally,
it will be more difficult for attackers to see the clear operation of the app,
which may reduce the number of attack vectors. It is recommended that the code
be obfuscated to increase the difficulty of examination by malicious users. Obfuscate
all sensitive application code where feasible by running a code obfuscation
program using either third party commercial software or open source solutions.
- Exercise caution while using borrowed code -
For the reason of meeting
project timelines and making work load easier, many developers tend to use existing
free code available in the web and customize it to build the application around
it. Appropriate are must be taken to ensure there is no malicious code plugged
into the code. Use codes from a trusted third party. Care should be taken to do
a full secure code review of the code before use.
- Lock-down application permissions –
For
securing applications we should follow the principle of least privilege assignment
of permissions. At the architecture level, the application should be assigned
only the minimum required permissions. The permissions may include numerous
hidden paths to personal data stored on devices like contact lists, device
memory, SMS folders, GPS locations, etc. All such permission need to be
provided only if needed. For instance, read-write (rw-) permissions should not
be granted when only read (r--) permissions are required.
- Restricting debuggers and Tracers –
By incorporating a system call, an application can instruct the operating
system to not allow a debugger to attach to a process. By preventing a debugger
from attaching, an attacker will not be able to interfere or analyze with the
low-level runtime variables and system info. An attacker must first work around
the debugging restrictions in order to attack an application at the base level.
This adds further complexity to an attack.
An application can be coded to
determine whether it is being tracked by a debugger or other debugging tool. If
it is being traced, the application can be programmed to respond with actions
for possible attack scenarios, such as notifying a server administrator, discard
or disallow access to encryption/decryption keys or other such response actions
to defend itself.
- Insecure storage -
Data is stored by the application in /data/data/<application name> or in /sdcard. The data
in /data/data/<application name> cannot be accessed by another application
unless the application explicitly provides permissions for access or if the
device is rooted. Data that is stored in /sdcard can be accessed by any application
without any special permission or rooting. Hence, it is common for malicious
applications to access data stored in external memory i.e. /sdcard.
When evaluating an application’s
storage, ensure that both online and offline storage is evaluated. The focus
should be on the code that allows storage of the data locally and ensure that
no sensitive data is stored on the client side. Minimize the sensitive data
that needs to be stored on the device. If any data needs to be stored, then it
should be protected in storage by encrypting it using a strong algorithm prior
to storage.
- Insecure storage in process memory -
Data
processed by the application may be stored within memory longer than necessary,
which makes it more susceptible to attack. When using sensitive data such as
encryption keys, do not keep them in RAM longer than required. An attacker with
access to the phone may be able to dump the memory of the process to gain
access to sensitive information.
- Secure communications to server -
Ensure
the communication between the application and the servers is always secure and that
data transmitted cannot be intercepted or exploited by MITM attacks. Make use
of encryption and SSL certificates (TLS 1.2) to ensure data is not intercepted
during transmission. In fact HTTPS is often neglected and HTTP is preferred.
And even if developers use HTTPS technologies they may still overlook numerous
aspects of certificate verification so, once again, this field required extra
attention.
- Sensitive Data Disclosure -
If the
application logs data at the Client-side it can be easily retrieved by an
attacker if he is able to gain access to the device. Sensitive data such as
passwords, card number should never be logged. Another control to ensure is to
prevent caching. Developers can configure iOS and Android applications to not
cache web data, particularly secure (HTTPS) traffic, as this may contain
sensitive or private information. The server headers should be set
appropriately to instruct the browser/app not to cache data. Given the
widespread use of mobile apps in public places, it is beneficial to store and
display partial phone number on the device to protect privacy.
Ensure apps do not display system info
in warnings and error pages and are tested thoroughly to avoid crashes. Consider
disabling NSAssert for iOS, as this setting will cause an app to crash if an
assertion fails. From a security perspective, handling a failed assertion can
be performed in more graceful manner than to crash the application and generate
logs. Also, the crash logs should not be sent in plaintext over an unencrypted
network.
- Use strong passwords and not PINs -
Android applications usually require a
PIN for authentication instead of a password, the reason being ease of use, as
it is cumbersome to enter a long password from a mobile device. However, it is
important to point out that PINs are easier to brute force. For stronger
security passwords should be used instead of PINs. Also if security is of
utmost importance such as for banking applications it is recommended to have a
session timeout and not to keep the user logged in.
- Perform data validation -
Data validation issues in apps are not
considered seriously during performing a code review after development.
However, this is a primary point of entry for attackers. All data validation
issues like buffer overflow, format string issues, can become applicable for
mobile applications as well. When using native code, special care needs to be
taken when data is read from an untrusted source.
- Release regular patches -
Responsibility towards keeping the app
secure does not end with the release of the app. Hackers use new ways to launch
attacks and exploit the potential vulnerabilities. Periodic security updates ensure
your app addresses all security loopholes which may exist or come up.
Source:http://www.mcafee.com/in/resources/white-papers/foundstone/wp-secure-coding-android-applications.pdf
Source:http://www.mcafee.com/in/resources/white-papers/foundstone/wp-secure-coding-android-applications.pdf
Author:
Vishnu Kamat currently serves as a Associate Consultant - Web and Mobile Application Penetration Testing team at SISA Information Security Pvt. Ltd. Bangalore. His work focuses on Application Penetration testing, Digital Forensics, Code Review, PA DSS and Information Security Assessments.
Thank you for sharing.
ReplyDelete