Mr.

Tan Chiang Kang

UCCD3223 Mobile Applications Development

2
Threats
 In mobile devices, there are three primary targets for
attackers:
 Data: mobile devices can contain large amount of data,
many of which can be personal and even work related
(e.g. emails, chat conversations, financial documents).
 Identity: smartphones contains a lot of personal
information, e.g. email accounts, pictures, credit card
numbers, passwords, contact lists, date of birth etc,
which are useful for identity theft.
 Money: smartphones can be used to transfer money,
pay bills and even used as a method of payment.
3
How can they attack you?
 Attackers can harm you in many ways if your mobile
devices are compromised, for example:
 Turn your smartphone into a zombie machine to be used
for sending spam via SMS or email
 Can get your phone to make calls to premium rate
numbers which the owner will be charged for the calls
 Can record conversations you have with others without
you knowing
 Steal your identity and impersonate you elsewhere
 Attacker can erase data on your phone

4
Some Securities Measures
 OS Security: OS can offer the first layer of security.
OS that is designed to have less flaws and security
risks are harder to be attacked. Sandboxing is a
common idea used in mobile OS.
 Antivirus Software: various software to prevent
attacks such as malwares and hacking are also
available in many mobile devices
 Network security: encryption of transmitted data,
spam filters, telecom network surveillance and etc

5
Some Securities Measures
 Resource Monitoring: many smartphones offer
monitoring tools or apps to monitor battery usage,
memory usage, network traffic and etc for anomalies
 User awareness: The user should also be careful and
be vigilant of potential danger as many threats are due
to users’ ignorance and their lack of awareness on the
danger of certain actions

6
Android Security
 Android operating system itself provide some security
measures to protect the applications from
unauthorised theft of data and other security risks
 Android relies greatly on Linux kernel security
measures to protect resources on the mobile devices

7
Linux Kernel Security
 Each Android package has a unique Linux user ID
assigned to it during installation
 This has the effect of sandboxing the process and the
resources it creates
 This protects the resources from being modified or
used by other applications
 Due to this kernel-level security, communication of
applications requires additional steps (e.g. via Content
Providers, Broadcast Intents, and Android Interface
Definition Language (AIDL) interfaces)
8
Permissions
 Permissions are a type of application-level security
mechanism that allows you dictate what your app can
or cannot do
 Permissions must be set to allow information to flow
between applications
 They act as border guards on both ends to control
traffic flow

9
Permissions
 Permissions are required for many Android’s native
components
 Native permissions for Android Activities and Services
can be found in android.Manifest.permission class
 To request a permission, we need to add <uses-
permission> tags into the Android manifest,
specifying the required permission in it
 Permissions will be requested when certain actions
requiring them are triggered

10
Permissions

11
Dangerous Permissions
 From Android 6.0 (API level 23) onwards the user is asked to
grant dangerous permissions requested by an app when that
app is run, not when it is installed.
 If your app’s target SDK is 23 or higher, and the device is
running Android 6.0 or higher, then in addition to requesting
permissions in your app’s AndroidManifest.xml file your app
must also call requestPermissions() to request them at
runtime.
 Moreover, the user can revoke an app’s permissions at
anytime, so your app should call checkSelfPermission() to
determine if it has the permissions it needs whenever it
performs an operation that needs a dangerous permission. See
the Android documentation for further details. 12
Dangerous Permissions List
 Dangerous permissions cover areas where the app wants data
or resources that involve the user's private information, or
could potentially affect the user's stored data or the operation
of other apps

13
iPhone Security
 How about iPhone?
 iPhone uses a closed system operating system
 iPhone forces all developers to submit their
applications for a review process before publishing to
the AppStore (may take weeks!)
 To ensure your apps are published, they need to strictly
follow a set of rules in UI design, that they will be free
from malicious codes, as well as obscene contents
 iPhone also disallow Bluetooth communication with
other platforms and complete freedom in USB file
transfer 14
Android Security
 Security on Android phones
catching up on iPhone
 With more stringent review process
 But Android is an open-source operating system
 Users can tinker with their OS
 Users can install apps from unofficial sources
 With many manufacturers, some better than others in
securing your device
 Android devices more attractive target with bigger user
base
15
16
Designing Secure Mobile Apps
 To design secure mobile applications, the developer
can focus on:
 Handling of Private Data on the Handset
 Transmission of Private Data over the Network

17
Private Data on Handset
 Limit the amount of private and sensitive data that the
applications want to store
 Do not store sensitive information in plain text and
never transmit it in plain text format
 Do not try to work around any security mechanism
imposed by the handset operating system or Android
framework
 Use encryption for sensitive data

18
Private Data over Network
 Data should be handled with similar vigilant
 Ensure the servers to be connected are reputable to
avoid identity theft and encroachment of privacy
 Check servers that you are trying to connect to are who
they say they are
 Sensitive data to be transmitted should be secured
using typical security mechanisms - Transport Layer
Security (TLS)/Secure Socket Layer (SSL) e.g. using
HTTPS instead of HTTP
 If using Wi-Fi, it is best to only connect to trusted and
secured Access Point (AP), e.g. on WPA2 encryption 19
Putting into Action
 Identify sensitive data in your application
 Passwords, credentials, address, etc
 Security audit every process involving the data
 Encryption during storage, delivery
 Uses POST method when transmitting over network
 Prevent unauthorised access
 Request password or biometrics authentication when
accessing data in app
 Automatic expiring self-protection mechanism
 Verify credentials if involves potentially “damaging”
actions 20
Word of Advice
 Be careful yourself and be vigilant of others
 Do not make assumptions that all your users are
without malicious intent!
 Always imagine that you are going to have at least ONE
user that will make use of loopholes and poor security
design in your app or system to launch an attack
 There is no one single perfect security solution, but
you can add layers upon layers of security to make your
app more secure
 Security and convenience is a tough balance!
21
Word of Advice
 The implications of poor security to users could be as
trivial as data lost, to financial lost, to potentially lives
lost
 Hence do take security seriously when developing your
mobile application

22
What’s Next?
 What’s More About Mobile?

23