Key Challenges 04

Security Vulnerabilities 05
Unsecure libraries 06
Choice of language 06
Reverse engineering 07
IP theft 07
Preventing Security Vulnerabilities 08
Anti-tampering and anti-debugging techniques 08
Code obfuscation 08
Enable and enhance data encryption and decryption 09
Secured API 10
Data permissions 11
Rooted devices and emulators 11
Session handling 12
Implement SSL and certificate pinning 13
Support for offline environment 14
Global device compatibility 14
Anti-memory dumping 14
Cheat tool detection 16
Integrations with tools 16
The Balancing Act Between Security and Performance 17
Using CDNs 17
Web-application firewall 17
Scaling and Automating Mobile AppSec to Reduce Costs 18
Replacing penetration testing with automation 18
Enhancing employee productivity 21
Automating DevSecOps processes 21
One-Time Solution for App Security Needs 22

MOBILE APP SECURITY WHITE PAPER

Organizations today rely heavily on mobile applications
to expand their scope and achieve better
communication with customers as well as business
partners. This worldwide digital race has led to
companies buying more codes and further
supplementing them with open source libraries.

A recent report by Risk Based Security revealed that in

the first half of 2020 alone, 36 billion records were
exposed to data breaches. Hence, in the current
landscape where app usage is increasing multifold and
user information is constantly under threat, application
security becomes crucial.

MOBILE APP SECURITY WHITE PAPER

KEY CHALLENGES

While physical data servers hosted in data centers were previously in use, the current trend is
storage on the cloud. The lure of on-demand scalability and access to development services
offered by cloud storage providers, such as Google Cloud, Azure, and AWS, is hard to resist.
Businesses also often expose their server-side systems while releasing their early apps to the
market. The servers where the app is hosted (including any third-party server that the app
may be accessing) should have security measures in place.

One of the other major challenges that businesses face today is that the software developed
by them is often developed using open-source components rather than being made
in-house. Though this greatly reduces the time-to-market for the software, it exposes the
companies to severe corporate risk.

The haste in releasing the application to the market precedes the security needs and
performance testing is seen as a bottleneck to the release process. The attacks to these
applications can sometimes take as much as two weeks to be detected due to incident
overload and alert fatigue, while the risk keeps increasing.

The increasing incidence of bot usage on websites is also a major challenge for software
developers. While some bots, such as chatbots and search engine bots, are helpful, most of
them (over 70 percent) can be harmful. These malicious bots can scrape information from the
website and spam forums, use stolen credentials to gain unauthorized access to the website,
or engage in other such activities while being disguised as a human user.

MOBILE APP SECURITY WHITE PAPER

04
SECURITY VULNERABILITIES

Once an attacker has identified a flaw in the system and determined how to access it, they
can target the confidentiality, integrity, or availability (called the CIA triad) of data stored in an
application as well as of its creators and users. If the operating system, framework, or
compiler is vulnerable, hackers can gain access to the app data usually stored in binary data
stores, cookies, SQL databases, and sometimes even as plain text.

Another method of breaching app security is by stealing hard-coded data using APIs. They
are favored cyber attack targets which are routinely exploited by hackers and malware. Often,
developers use the same hard-coded credential across applications. Code injections on the
client side can also lead to the execution of malicious code on the mobile device.

This malicious code is often injected via user forms that do not have any restrictions on the
input characters, letting hackers gain access to private information.

Memory leakage is also possible from memory dumps that are used by developers to store
information during a crash so as to troubleshoot issues and identify the cause behind the
crash. Hackers can also gain access to sensitive information through cached data and login
details. For example, any input given to the keyboard is stored in the Android user dictionary
to facilitate auto-correction features in the future. The user dictionary, which can easily be
accessed by any application without any permission, could lead to the leakage of sensitive
data.

MOBILE APP SECURITY WHITE PAPER

05
 SECURITY VULNERABILITIES

Some other common application vulnerabilities have been listed below:

UNSECURE LIBRARIES
Dependence on open-source libraries poses a threat to the
security of applications if they have not been tested properly by
the open source community or the community is not large
enough yet to both develop and secure its output. A recent
study conducted by Veracode revealed that seven in 10
applications had a security vulnerability that could be traced
back to an unsecure library.

CROSS-SITE
INSECURE Many flaws in these open libraries are never even assigned a
DESERIALIZATION
SCRIPTING

30% 23.5% common vulnerabilities and exposures (CVE) ID. Hence,

developers cannot rely on CVEs alone to identify risks
represented by languages and libraries. According to the report,
the most common vulnerability is cross-site scripting (found in 30
20.3% percent of libraries), followed by insecure deserialization (23.5
BROKEN
ACCESS
CONTROL percent), and broken access control (20.3 percent).

CHOICE OF LANGUAGE
The choice of language also makes a difference to the level of
threat an application is exposed to. Some languages have
RISKS OF A SECURITY FLAW

greater transitive dependencies than others. For example, in

more than 80 percent of JavaScript, Ruby, and PHP applications,
most of the libraries have transitive dependencies. The inclusion
of a PHP library increases the risks of a security flaw by more than
50 percent (State of Software Security). It was found that as much
as 40 percent of PHP libraries had an XSS flaw. The Lodash library
PHP LIBRARY also had about 401 versions with a security flaw.

MOBILE APP SECURITY WHITE PAPER

06
SECURITY VULNERABILITIES

REVERSE ENGINEERING
Reverse engineering of android applications can give hackers access to login credentials, details
of the libraries, and classes used, flaws in the design of the app as well as the type of encryption
used. This can pose a threat to multiple devices that can now be hacked using the same
decryption method. The two main categories of reverse engineering used are as follows:

STATIC:
This refers to inspecting the contents of an application
(extracting the design of the app without actually
running it).

DYNAMIC:
Extracting information about the app by running it in a
target or controlled environment. This uses various tools
to inspect the processing of an application while it is
running. This type of reverse engineering is also known
as debugging.

IP THEFT
Hackers can obtain the code base of an app to create illegal
clones. They might also steal the intellectual property of the
company that owns the app. If an app is successful, it attracts
more such clones on app stores. Such examples include Fortnite
and Google, which were not available on Google Play but had
their clones on the play store due to their increasing popularity.

MOBILE APP SECURITY WHITE PAPER

07
PREVENTING SECURITY VULNERABILITIES

ANTI-TAMPERING AND ANTI-DEBUGGING

TECHNIQUES
Anti-debugging techniques are one of the best ways to protect
against reverse engineering of mobile apps. While mobile app
debuggers are used in app development, they are also widely
used by hackers to study an app’s runtime behavior. Since
debugging is one of the most common ways of launching
security attacks, one of the simplest ways to identify debugging
is to use API calls, such as the Windows debugging API. Dynamic
checks can also be injected into the code and compiled to detect
debugs during runtime. If any changes to the executable code
are identified, the app responds by shutting down. Debugs often
use exceptions in the code so they can be identified if only
certain exceptions are not being executed during runtime. The
flaws in the bugs can also be uncovered and nullified by
introducing instructions in the code that are known to cause a
disruption in its intended behavior.

CODE OBFUSCATION

Code obfuscation refers to the modification of an app’s code so

that it becomes difficult to read or comprehend. Obfuscations
help in hiding the purpose and logic of an app while its
functionality remains unchanged. The various techniques used
for obfuscation are classified based on the information targeted.
While some target the lexical structure of the software (name
obfuscation), others target the control flow (control flow
obfuscation). Some obfuscation techniques also remove debug
information, such as source file and line number, parameter type,
as well as Java annotations.

MOBILE APP SECURITY WHITE PAPER

08
PREVENTING SECURITY VULNERABILITIES

However, code obfuscation alone is not enough to prevent complex security attacks. While it
does make it difficult for hackers to reverse-engineer the app, the availability of automated
deobfuscation tools, such as Hopper and IDA Pro, that facilitate reverse engineering can
compromise the application data. Advanced malware can attack specific security flaws in the
mobile OS and use several different techniques to achieve the intended goal. For example,
the Android Accessibility APIs, which help disabled people use smartphones, can be misused
to create mobile trojans, which can, in turn, enable malware to act as a screen recorder and
remotely control the device.

ENABLE AND ENHANCE DATA ENCRYPTION AND DECRYPTION

Data encryption is all the more important in the case of mobile devices where physical access
to the user device is an extremely likely scenario. Cryptography ensures authenticity,
confidentiality and data integrity even in the face of an attack. Data encryption helps in
converting plain text into cipher-text which conceals the original code. There are two kinds of
encryption:

SECRET SAME KEY SECRET

KEY KEY

PLAIN TEXT CIPHER TEXT PLAIN TEXT

SYMMETRIC ENCRYPTION

Symmetric key encryption, where the same key is used for both encryption and decryption.
This is a fast technique, more suitable for bulk data processing. However, since anyone with
the key can decrypt the encrypted content, it requires careful handling of the key.

MOBILE APP SECURITY WHITE PAPER

09
PREVENTING SECURITY VULNERABILITIES

DIFFERENT KEY

PUBLIC PRIVATE
KEY KEY

ORIGINAL TEXT SCRAMBLED DATA ORIGINAL TEXT

ASYMMETRIC ENCRYPTION

Asymmetric of public key encryption, where there is a separate public key and a private key.
A message encrypted within the public key can only be decrypted by the private key. Hence,
while the public key can be freely distributed, the private key must be kept secure. This
option is slower than symmetric encryption and is used to encrypt small amounts of data.

Hashing is another form of cryptography that is not encryption but is often used for integrity
verification. Message authentication codes (MACs) combine other cryptographic techniques
with secret keys in order to facilitate both integrity and authenticity. However, MACs can be
verified only when multiple entities share a common key. HMAC is the most commonly used
MAC and relies on hashing as its foundation. Asymmetric cryptographic mechanisms can be
combined with hashing using “signatures.” Unlike MACs, private keys in signatures remain
only with the user. Key derivation functions (KDFs) are used to convert keys into other formats
or increase their length. While hashing functions and KDFs are similar and difficult to reverse,
KDFs have an additional requirement of randomness, making them a bit more secure.

SECURED API

API security testing includes multiple scanning processes that test the server side of the
application. Manual penetration testing of each server prior to release is an extremely
complex and time-taking process that can delay the time-to-market of an app.

MOBILE APP SECURITY WHITE PAPER

10
PREVENTING SECURITY VULNERABILITIES

Hence, automated API testing is imperative for all organizations. Several open-source and
commercial (licensed) tools are available to conduct automated API testing. The two most
commonly used APIs are SOAP (Simple Object Access Protocol) and REST (Representational
State Transfer). The requirements of the app and the potential threats it could face must be
analyzed to choose the right tools and conduct thorough and effective API testing.

DATA PERMISSIONS

Unlike web-based apps, mobile applications have access to a significant amount of user data
on the phone. Apps can access everything that has been granted access to by the user, and
often both developers and users do not pay enough attention to the actual requirements of
the app and the safety issues attached with it. Some of the most common permissions
granted to apps are contact information, phone calls, gallery access, ID and device data,
messaging, accounts, Wi-Fi, and GPS. To prevent misuse of data, optimal authentication
measures should be undertaken and AES (advanced encryption standard) with an encrypted
password of at least 128 bits should be in place to ensure security and non-disclosure.
Transport layer security (TLS) with 128-bit encryption methods should be used for data
transfer, and data should only be retained temporarily for as long as it is needed.
Communication with wearables should also be established by encryption methods for device
authentication and data transfer.

ROOTED DEVICES AND EMULATORS

Rooted devices are a major cause of security concern, especially for Android devices. These
devices are modified to let applications break out from the security sandbox on the device
OS. This exposes the device to security threats, such as password theft and malware. App
developers should, therefore, ensure that their apps are not allowed on rooted devices, or
the users are issued regular warnings when they run an app in a rooted environment.

MOBILE APP SECURITY WHITE PAPER

11
PREVENTING SECURITY VULNERABILITIES

Writing root-checking codes manually is a tiring and continuous process, as the techniques
available for rooting keep changing with time. However, products like PreEmptive
Protection-Dotfuscator Community Edition, which comes with the Visual Studio 2017 for
Windows, can inject root checks into apps. Root checks can detect rooted environments even
when the device is offline. To let Dotfuscator inject a root check into a [Link] app,
enable code injection followed by configuration of the checks via the user interface or by
annotating the source code with RootCheckAttribute. Both these methods allow the user to
specify various properties of the check.

SESSION HANDLING

Several applications allow very long or non-expiring user sessions or use predictable session
tokens. While this might have desired applications for app developers and businesses which
are always on the lookout to reduce friction for users and grant immediate access to
purchasing and checkout, improper session handling poses security threats for both the user
and the business itself. However, some checks and measures can be taken by organizations
to ensure proper session handling. They include:

Invalidation of sessions Proper generation of Adequate time-out

on both the app and the sufficiently long, protection on backend
server. complex, and components (about 15
pseudo-random tokens minutes or less for
by following high-security components
industry-standard and one hour for the
methods. low-security ones).

MOBILE APP SECURITY WHITE PAPER

12
PREVENTING SECURITY VULNERABILITIES

IMPLEMENT SSL AND CERTIFICATE PINNING

Certificate pinning is an operating procedure used on the client side that provides a defense
mechanism against man-in-the-middle attacks on unsecured networks. A developer pins a list of
trustworthy certificates to the application, which is then compared to the server certificate during
runtime. In case of a mismatch between the server and a local copy of the certificate, the
connection is disrupted, and no app data is further sent to the server. This ensures that the
application communicates only with dedicated and secure servers.

Sometimes an expired certificate is pinned to the app while the server has an updated certificate.
This would disrupt the connection and “brick” the application. To avoid this problem, apps must
have the updated certificates pinned to them even before release. SSL pinning can be achieved
either by pinning the whole certificate or its hashed public key. Using the hashed key is preferred
because the same key can also be used for an updated certificate, thereby reducing the chances of
the app “bricking.”

MOBILE APP SECURITY WHITE PAPER

13
PREVENTING SECURITY VULNERABILITIES

SUPPORT FOR OFFLINE ENVIRONMENT

With the increase in the usage of enterprise apps, such as customer

relationship management, billing systems, etc., organizations have
become bound to provide either partial or complete offline
functionality. This necessitates the storage of app data on the local
device, which is, in turn, synchronized with the cloud or server once
the device comes back online.

Since mobile applications can be physically accessed and local

storage is inherently risky, developers should make sure that the data
is only stored within the app with no option of back-up.

GLOBAL DEVICE COMPATIBILITY

It should always be ensured that the security frameworks developed

for an app is compatible across all kinds of mobile devices and
operating systems. If not, the apps will be vulnerable to security risks
on devices where the security framework is not supported. Ensuring
universal compatibility also addresses the issue of device
fragmentation.

ANTI-MEMORY DUMPING

Memory dumping is a part of reverse engineering wherein a snapshot

of the executable state is taken. Usually, a snapshot is taken once the
decryption process is over and the original entry point (OEP) is
reached. The snapshot is then saved to a disk and the dumped state
can be reverse-engineered as the original code has been uncovered.
Some anti-memory dumping techniques are given below:

MOBILE APP SECURITY WHITE PAPER

14
PREVENTING SECURITY VULNERABILITIES

NANOMITES:

In this technique, certain branch instructions are replaced with int 3h. The removed jump
instructions such as address, type (JCC, JMP, etc.), offset, etc., are then tabulated and
encrypted several times.

STOLEN BYTES (CODE SPLICING):

Attackers usually decrypt the entire code of the program in memory and move to its OEP for
execution. In code splicing, few data bytes are copied from the OEP and moved to a separate
location for execution. This can then be used to hide the original OEP.

SELF-UNMAPPING:

Here, the data of the app is mapped into the address space. The mapped view of the file can
be unmapped using UnmapViewofFile(). The data of the app is transferred to a separate
location and the absolute references are adjusted based on the new location. The previous
view can then be unmapped and the hacker will not have the new address space.

MOBILE APP SECURITY WHITE PAPER

15
PREVENTING SECURITY VULNERABILITIES

CHEAT TOOL DETECTION

Hackers often tamper gaming applications with repackaged, redistributed, and modified
versions and look for getting an undue advantage in the game (getting unlimited points,
coins, gems, etc.) or releasing fake copies of the application into the market. Cheat tools can
be nullified by preventing the execution of an app when such tools are running in the
background.

INTEGRATIONS WITH TOOLS

Development teams should make use of the available technologies and tools to always have
an edge over attackers and malware. The Crashlytics service offers a crash reporting solution
that can be used to review crash logs and make corrective changes in the app. Integration of
tools like TeamCity and Jenkins helps in conducting real-time security checks during the
development process.

When applications are being released by the minute and businesses are looking to gain a
competitive advantage, application security which is as important as the development,
should not be left on the back-burner.

MOBILE APP SECURITY WHITE PAPER

16
THE BALANCING ACT BETWEEN SECURITY AND PERFORMANCE

While integrating security frameworks into an app, developers must always make sure that
the security solutions do not impact the memory, CPU, or the user experience and
performance of the application. Additionally, security breaches or flaws identified by the
frameworks should immediately be flagged and the owner should be notified so that the
flaws can be fixed or damage control strategies can be thought of.
Some ways of balancing security with performance are highlighted below:

USING CDNS
Reducing the physical distance between users and servers delivering content to the
consumers can greatly enhance performance of applications. A global content delivery
network (CDN) can help achieve this by taking the content closer to the users as well as
dealing with unexpected traffic surges. While CDNs cannot resolve all performance
bottlenecks, they can definitely solve some of the issues faced by apps delivering content
from a single location in a fast and cost-effective manner.

WEB-APPLICATION FIREWALL
A web-application firewall (WAF) can be used to protect applications from security breaches
while delivering performance. It can filter the incoming traffic for web applications and be
used to either prevent the entry of bad traffic (a blacklist) or admit only pre-approved traffic
(a whitelist). WAFs can be deployed as hardware or software, or be provided by a cloud
service. They can protect against a range of attacks including distributed denial-of-service
(DDoS) attacks and brute-force attempts for gaining unauthorised access in an attempt to jam
the app servers.

MOBILE APP SECURITY WHITE PAPER

17
SCALING AND AUTOMATING MOBILE APPSEC TO REDUCE COSTS

With companies competing to release their apps into the market at an ever-faster pace,
manual penetration testing cannot match the needs of businesses today. The budgets kept
aside for app security is often too less to hire external counsel or conduct manual
assessments with the in-house teams, and this leads to negligence in proper security
measures. Automated testing tools come to the rescue of AppSec and DevOps leaders by
increasing the extent of testing while also saving costs and enhancing productivity for the
company.
There are three ways by which this can be achieved:

1. REPLACING PENETRATION TESTING WITH AUTOMATION

The costs for a single mobile app pen testing usually go up to $20,000 to $25,000, and when
apps today are updated so frequently, regular testing is a must. With such high testing costs,
organizations only manage to test their apps a few times a year. However, mobile AppSec
testing solutions can cut down testing costs by almost 85 percent through automated testing.
They let analysts use their cloud-based platform to upload an app binary, complete
configuration, run a fully automated test, and receive results in about 15 minutes. It allows
companies to conduct multiple tests in a day and still save costs compared to human
penetration testing done a few times a year. Moreover, these automated testing solutions
offer incremental testing of apps, i.e. developers need not wait for the entire app to be
developed to start the testing. Codes written each day can be tested on-the-go which would
enhance the security and substantially bring down risks.

MOBILE APP SECURITY WHITE PAPER

18
SCALING AND AUTOMATING MOBILE APPSEC TO REDUCE COSTS

RUNTIME APPLICATION SELF-PROTECTION

Runtime application self-protection (RASP) has been defined as a technology that is either
built into an application or linked to its runtime environment to control app execution and
prevent security attacks in real time. In addition to this, RASP also supplements and improves
the effectiveness of other tools in its ecosystem. The closest thing to RASP before it was
introduced to the market was web application firewall or WAF. It functions by inspecting the
incoming HTTP request traffic to identify potential attack payloads and unusual usage
patterns. RASP differs from WAF in its interaction with the application code. In contrast to
WAF, RASP uses contextual awareness to identify threats and say that a certain payload will
not exploit the application code. It inspects the data in terms of how the application will use
it, thereby reducing instances of false positives and offering greater efficiency in threat
identification. Hence, RASP can be seen as a second line of defense, next to WAF.
The following are the advantages of using RASP based automated testing:

RASP INSPECTS THE DATA IN TERMS OF HOW THE APPLICATION WILL USE IT,

THEREBY REDUCING INSTANCES OF FALSE POSITIVES AND OFFERING

GREATER EFFICIENCY IN THREAT IDENTIFICATION

BETTER DEFENSES

Once software has been developed, remediation efforts cannot solve for all of the security
vulnerabilities in the software building life-cycle. Many a time, organizations forgo
remediation due to roadblocks like a lack of access to the codebase, legacy frameworks, etc.,
before sending the applications to production. RASP implementations provide a way out of
this bottleneck by protecting applications at runtime against hitherto unknown threats. It can
also block or transform certain database queries and block content depending on the
deployment use case.

MOBILE APP SECURITY WHITE PAPER

19
SCALING AND AUTOMATING MOBILE APPSEC TO REDUCE COSTS

FASTER RELEASE

DevOps and application security were seen as two separate units till RASP came into the
picture. App development is an extremely complex, agile, and distributed process which
makes it difficult for developers to ensure the prevention of security breaches. Requirements
for pre-production testing also cause delays in development and release. RASP can be
integrated into the DevOps build and deployment processes without causing any delays.
Moreover, the detection and prevention features of RASP can be embedded into the
application release along with the automated CI/CD pipeline. This means that applications
are armed with their own defense mechanism irrespective of where they are in the SDLC. This
makes the entire process faster, smoother, and more efficient.

SMARTER RESPONSES

Since the security response teams are traditionally not a part of the development process, it
is difficult for them to correlate pre-production vulnerabilities to runtime attack data.
Applications and databases on the cloud have even lesser visibility into access or exfiltration
attempts. The noise generated by application firewall activity, vulnerability reports, testing
results, etc. makes threat detection an even more complex task. RASP helps the DevOps
team filter through the noise and enables faster and smarter responses and identification of
actual, specific risks during runtime. It tells the team exactly which apps are under attack and
how, thereby increasing remediation and risk management efficiencies.

MOBILE APP SECURITY WHITE PAPER

20
SCALING AND AUTOMATING MOBILE APPSEC TO REDUCE COSTS

2. ENHANCING EMPLOYEE PRODUCTIVITY

Many businesses such as banks, healthcare providers, retailers, and airlines depend on
security analysts to test each app manually. These analysts are roughly paid $5,000 per test,
which is cheaper than outsourcing the task. Manual testing also results in delays and
inefficiencies. RASP helps overcome all these difficulties by enhancing employee productivity
by almost 10 times, which can now be utilized for higher-value tasks and scale operations.

3. AUTOMATING DEVSECOPS PROCESSES

The integration of security testing into the rapid-release cycles of the app development
process is what gave rise to DevSecOps. Automation of the DevSecOps processes allows
organizations to achieve greater efficiencies and enables in-house testing of apps directly in
the continuous integration/continuous delivery (CI/CD) toolchain. This allows lesser
dependency on security analysts and enables more frequent testing of apps and feeding the
security bugs to the issue-tracking system to be fixed by the developers. DevSecOps solution
providers have developed several SDLC plugins that enable out-of-the-box integration into
CI/CD build tools, like Microsoft Azure DevOps, CircleCI, and Cloudbees Jenkins,
issue-tracking systems, like Jira, as well as vulnerability management, like Brinqa. The
US-based National Institute of Standards and Technology, in a recent report, stated that it
costs 30 times more to repair software defects post product release compared to what it
would cost if security vulnerabilities were identified in the production stage.

MOBILE APP SECURITY WHITE PAPER

21
ONE-TIME SOLUTION FOR APP SECURITY NEEDS

The numerous threats and challenges to mobile app security make it essential for businesses
to choose a well-rounded, efficient, and optimal security solution. Businesses, hence, must
consider several factors, like the sector they are in, common attacks to applications in the
same or similar spaces, requirements of the specific application, the types of users, etc.,
before zeroing in on any particular solution. In essence, organizations need to map the matrix
of threats to security controls in the application pipeline. This will help them plan out the type
of security tools they need to adopt in the build process and what they need at the
production stage.

The services provided by AppSealing are known for their exquisite risk handling and
future-proof solutions. AppSealing uses RASP to meet the security needs of applications
ranging from fintech, finance, e-commerce and crypto-currency, to gaming and O2O. In
addition, users get access to a synoptic view of the hacking attempts made on their app and
real-time threat status. These functionalities give app owners an edge over their competitors
and help them counter any kind of security threat, thereby letting them make better decisions
and plan expansion of operations.

START A FREE TRIAL

MOBILE APP SECURITY WHITE PAPER

22