Mobile apps are increasingly handling sensitive user data, but threats to mobile security are also rising. The document discusses several common mobile app vulnerabilities related to improper platform usage, insecure data storage, and insecure authentication. It provides guidelines for developing secure iOS and Android apps, such as using data protection and restrictions for files, keychain items, and cached network responses. Following security best practices for mobile platforms can help protect user privacy and sensitive data.

1. ARE YOUR
MOBILE
APPS
SECURE?

2. Threats to mobile apps
• Mobile devices have become an essential part of our lifestyle.
• People are now using mobile applications for their crucial tasks 24X7, and they entrust these apps
with a lot of sensitive information.
• Statista forecasts that by 2020, mobile apps will generate around 189bn US dollars in revenue via
app-stores and in-app advertising.
• As the demand for apps has risen, so have the malicious attempts threatening security.
Kasperskystatistics
for2017
5,730,916 malicious installation packages
94,368 mobile banking Trojans
544,107 mobile ransomware Trojans

3. Android
Common Vulnerabilities and Exposures

4. iOS
Common Vulnerabilities and Exposures

5. What is sensitive data?
• A definition of "sensitive data" must be decided before app development because detecting sensitive data leakage without a
definition may be impossible.
• Following is a list of entities generally considered sensitive:
• User authentication information (credentials, PINs, etc.)
• Personally Identifiable Information (PII) that can be abused for identity theft: social security numbers, credit card numbers,
bank account numbers, health information
• Device identifiers that may identify a person
• Highly sensitive data whose compromise would lead to reputational harm and/or financial costs
• Any data whose protection is a legal obligation
• Any technical data generated by the application (or its related systems) and used to protect other data or the system itself
(e.g. encryption keys)

6. The primary objective of security of any system is to ensure
Confidentiality, Integrity, and Availability of the data
categorized as sensitive
The vulnerabilities to be discussed in this session have
shown to obstruct some/all of above three factors, and the
remedies suggested would help is restoring the security
Objective of
security

7. Mobile Top 10 Vulnerabilities 2016
OWASP
Mobile
Top 10
M1
Improper Platform Usage
M2
Insecure Data Storage
M3
Insecure Communication
M4
Insecure Authentication
M5
Insufficient Cryptography
M6
Insecure Authorization
M7
Client Code Quality
M8
Code Tampering
M9
Reverse Engineering
M10
Extraneous Functionality

8. M1 - Improper
Platform Usage
This category highlights the misuse of platform features and failure to
use platform security controls.
• Mobile platforms, for example iOS, Android, etc. have development
guidelines for security. If an app contradicts the best practices
recommended by the manufacturer, it will be exposed to this risk.
• As an example, there are guidelines on how to use the iOS Keychain
or how to secure exported services on Android.

9. iOS Platform Usage
Guidelines

10. File Data Protection
Apple provides Data Protection to protect data stored in flash
memory on the device.
Data Protection enables a high level of encryption for user data.
Key system apps, such as Messages, Mail, Calendar, Contacts,
Photos, and Health data values use Data Protection by default.
Drawback - Data protection is available only when the user has set
an active passcode for the device.

11. NSFileProtectionComplete
• The file is only accessible while the device
is unlocked. When the device is locked, the
app will lose access to protected files 10
seconds later.
• This mode isn’t suitable if app needs to
access the file while running in the
background.
NSFileProtectionCompleteUnlessO
pen
• While the device is locked, files can still be
created and already open files can be
accessed.
• Suitable for completing a task in the
background that requires the app to save
new data or update a database.
NSFileProtectionCompleteUntilFirst
UserAuthentication
• The file can be accessed any time after the
user enters their passcode once after the
device has booted, even when the device is
locked.
• Protects data from attacks that involve a
reboot.
• Default class for all third-party app data,
which are otherwise not assigned to
another data protection class.
NSFileProtectionNone
• The file can always be accessed. There are
no restrictions.
Every file within an app’s
sandbox is associated with
one of the four data
protection types:

12. • The Xcode entitlement-based mechanism
sets file protection
to NSFileProtectionComplete
• This option is available in the project
under Target Capabilities > Data
Protection
• By enabling data protection, the app’s
entitlements file is updated (creating if
required). It will also enable data
protection on App ID in the Certificates,
Identifiers & Profiles section of the Apple
developer website.
• At present, the other file protection
modes are not configurable directly from
Xcode
• This entitlement needs to be set before
the app is installed
Setting a
protection
through Xcode

13. • Directories and files within the app
sandbox can be set a protection
type programmatically (other then
default
NSFileProtectionCompleteUntilFirst
UserAuthentication)
• This process would work without
the need to set the entitlements
from Xcode
Encrypting a file on first write
do
{
try data.write(to: fileURL, options: .completeFileProtection)
}
catch
{
// Handle errors.
}
Encrypting an existing file on disk
do
{
try (fileURL as NSURL).setResourceValue( URLFileProtection.complete,
forKey: .fileProtectionKey)
}
catch
{
// Handle errors.
}
Encrypting a directory on first write
• Any new file created in the
directory would inherit
NSFileProtectionComplete
• The protection level of existing
files do not change with the
protection level of their
containing directory
do
{
try FileManager.default.createDirectory(at: directoryURL,
withIntermediateDirectories: true, attributes: [.protectionKey:
FileProtectionType.complete])
}
catch
{
// Handle errors.
}
Setting a
protection
programmatically

14. Keychain Data Protection
• An app may need to handle passwords and other short but sensitive bits of
data, such as keys and login tokens. The iOS Keychain provides a secure way to
store these items.
• An app can keep the keychain data for its own use, or it can share the data
with apps from the same developer.
• Keychain services have the provision to override default behaviour of security
and accessibility of the stored data.

15. Keychain data is protected using a
class structure similar to the one
used in file Data Protection.
kSecAttrAccessibleWhenPasscodeSetTh
isDeviceOnly (most restrictive)
If the user hasn’t set a passcode, you can’t store
an item with this setting
kSecAttrAccessibleWhenUnlockedThisD
eviceOnly
Items with this setting are only accessible when
the device is unlocked*
kSecAttrAccessibleWhenUnlocked
(Default)
Items with this setting are only accessible when
the device is unlocked*
kSecAttrAccessibleAfterFirstUnlockThis
DeviceOnly
The data in the keychain item cannot be
accessed after a restart until the device has
been unlocked once by the user
kSecAttrAccessibleAfterFirstUnlock The data in the keychain item cannot be
accessed after a restart until the device has
been unlocked once by the user
kSecAttrAccessibleAlwaysThisDeviceOnl
y
The data in the keychain item can always be
accessed regardless of whether the device is
locked
kSecAttrAccessibleAlways (least
restrictive)
The data in the keychain item can always be
accessed regardless of whether the device is
locked

16. Adding an accessibility restriction on a keychain item
A query dictionary
to create an item,
with default
accessibility
settings
var query: [String: Any] =
[kSecClass as String: kSecClassInternetPassword,
kSecAttrAccount as String: account,
kSecAttrServer as String: server,
kSecValueData as String: password]
A query dictionary
to create an item,
with restricted
accessibility
var query: [String: Any] =
[kSecClass as String: kSecClassInternetPassword,
kSecAttrAccount as String: account,
kSecAttrServer as String: server,
kSecAttrAccessible as String: kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
kSecValueData as String: password]

17. Keychain Data Protection –
Confirming user’s presence
• Adding access restrictions to keychain items may not be secure enough in
all cases.
• For such cases, confirming the presence of the authorized user at the
very last minute before retrieving data from the keychain provides an
additional layer of security.
• This can be accomplished by the use of Keychain Services Access Control
feature.

18. Adding an additional authentication restriction on a keychain item
Step 1:
Create the access control instance of
SecAccessControl type, using access control flag
kSecAccessControlUserPresence
Other access control flag options are
• kSecAccessControlDevicePasscode
• kSecAccessControlBiometryAny
• kSecAccessControlBiometryCurrentSet
var error: NSError?
let access = SecAccessControlCreateWithFlags(NULL, // Use the default allocator.
kSecAttrAccessibleWhenUnlocked,
kSecAccessControlUserPresence,
&error);
Step 2:
Add access to query dictionary (same a earlier)
var query: [String: Any] =
[kSecClass as String: kSecClassInternetPassword,
kSecAttrAccount as String: account,
kSecAttrServer as String: server,
kSecAttrAccessControl as String: access,
kSecValueData as String: password]

19. Keychain Data Protection – Set
application specific password
In the absence of a device passcode, it is possible to configure accessibility with an
application-specific password to guard a keychain item.
Step 1:
Create the access
control instance of
SecAccessControl ty
pe, using
the applicationPass
word option
let access =
SecAccessControlCreateWithFlags(NULL, kSecAttrAccessibleWhenPassco
deSetThisDeviceOnly,
kSecAccessControlBiometryAny | kSecAccessControlApplicationPassword,
&error);
Step 2:
Add access to query
dictionary
var query: [String: Any] =
[kSecClass as String: kSecClassInternetPassword,
kSecAttrAccount as String: account,
kSecAttrServer as String: server,
kSecAttrAccessControl as String: access,
kSecValueData as String: password]

20. M2 – Insecure
Data Storage
• File systems of the mobile devices should not be considered as
secure enough to store sensitive information.
• It is expected that a malicious user or malware would be able to
access file system and the app sandbox, and exploit the
vulnerabilities.

21. iOS Secure Data
Storage Guidelines

22. Cached Application Snapshots
• When an application goes in the background, the system takes and
caches a screenshot of user interface within the app sandbox.
• This screenshot might expose an otherwise sensitive data.

23. Registering to
notification
NotificationCenter.default.addObserver(self, selector:
#selector(didEnterBackground), name:
.UIApplicationDidEnterBackground, object: nil)
NotificationCenter.default.addObserver(self, selector:
#selector(willEnterForeground), name:
.UIApplicationWillEnterForeground, object: nil)
Handling
sensitive data
in screenshots
• To fix the problem, a notification will be
needed to be setup when the
application is going to the background
• On being invoked, the UI elements to be
excluded can be hidden, before iOS
captures the screen
• When app comes to the foreground, the
UI elements can be made visible again

24. Security concerns
with text inputs
• By default, all the text from text objects with
autocorrection enabled are cached at path
“/User/Library/Keyboard/dynamic-text.dat”
• To prevent storing of sensitive information like
username and password in keyboard database:
• Turn off the auto-correct option
• The UITextField should have isSecureTextEntry
trait set as true
• Setting this property to YES in any text input
view disables the user’s ability to copy the text in the
view.
• Setting this property to YES in a UITextField object
additionally enables a password-style experience, in
which the text being entered is obscured.
textField.isSecureTextEntry = true
textField.isSecureTextEntry = false
textField.autocorrectionType = UITextAutocorrectionType.no

25. Networking
Cache Policies
• Any HTTP and HTTPS request loaded
through URLSession will be handled
by URLCache, which provides a in-
memory and on-disk caching
mechanism. Cache database is stored at:
(App
Folder)/Library/Caches/com.bundle.i
d.of.your.app/Cache.db
• The NSURLCache database is encrypted
via iOS’s file protection system.

26. • Caching can be disabled completely by setting the URLCache property of
the NSURLSessionConfiguration to nil.
• Override URLSession:dataTask:willCacheResponse:completionHandler: to return a
cached response stripped of any sensitive data.
let config:URLSessionConfiguration = URLSessionConfiguration()
config.urlCache = nil //set to nil
let session:URLSession = URLSession(configuration: config)
func urlSession(
session: URLSession,
dataTask: URLSessionDataTask,
willCacheResponse proposedResponse: CachedURLResponse,
completionHandler: @escaping (CachedURLResponse?) -> Void)
{
completionHandler(nil)
}
Handling
URL Cache

27. Nagarro drives technology-led business breakthroughs for industry leaders and challengers. When our clients want to move
fast and make things, they turn to us. Some of our clients include Siemens, GE, Lufthansa, Viacom, Estēe Lauder, ASSA
ABLOY, Ericsson, DHL, Mitsubishi, BMW, the City of New York, T-Systems, SAP and Infor. Working with these clients, we
continually push the boundaries of what is possible to do through technology, and in what time frame.
Today, we are more than 5,000 experts across 20 countries. Together we form Nagarro, the global services division of
Munich-based Allgeier SE.
Sources
• https://www.apple.com/business/docs/iOS_Security_Guide.pdf
• https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy/encrypting_your_app_s_files
• https://developer.apple.com/documentation/security/keychain_services/keychain_items/restricting_keychain_item_accessibility
• https://pspdfkit.com/blog/2017/how-to-use-ios-data-protection/
• https://medium.com/@abjurato/owasp-for-ios-m1-improper-platform-usage-part-1-7aff742c50ee
• https://medium.com/@abjurato/m1-improper-platform-usage-part-2-5716ee1492e
• https://www.cvedetails.com/