Mobile Payment Application Security – Security steps to take while developing Mobile Application’s www.sisainfosec.com

SISA W

ebina

r

www.sisainfosec.com

About SISA Payment Security Specialists PCI Certification Body (PCI Qualified Security Assessor) Payment Application Security Assessor (PA QSA) Point to Point Encryption Qualified Security Assessor (P2PE QSA) VISA Approved Security Assessor (PCI PIN) PCI Approved Scanning Vendor (PCI ASV)

Certified the First IT/ITES, First Bank and First Merchant on PCI Compliance.

Securing payments for over 1,000 organizations in over 30 Countries

Delivery locations across Asia Pacific, Middle East and Americas.

SISA CPISI Certification has over 5,000 professionals and is the one of the most coveted certifications for payment security professionals in the marketplace.

SISA W

ebina

r

www.sisainfosec.com

SISA Offering

Synergistic Security Framework

SISA W

ebina

r

www.sisainfosec.com

Speakers

Renju Varghese Jolly Principal Consultant

Dharshan Shanthamurthy CEO

SISA W

ebina

r

www.sisainfosec.com

Introduction • As per a Garner study, “If an organization doesn’t have a mobile strategy, then they don’t have a strategy

at all”.

• Expected mobile and tablet sale by end of 2015 is 3 billion devices

• Gartner is predicting that by end of 2017, focus of end-point breach will shift from PC to mobile devices

• Consider that with 1.6 million Android application and 1.5 million apps in App Store

• Hence, the webinar on Mobile Application Security

• As Doctor’s say – “Prevention is better than cure”. SIS

A Web

inar

www.sisainfosec.com

Anatomy of a Mobile Attack

SISA W

ebina

r

www.sisainfosec.com

Different Types of Mobile App • Web – Referred as WAP or Mobile Sites

• Native – Compiled for the specific mobile platforms (like Android, iOS) and leveraging the mobile platform

API’s

• Wrapper / Hybrid – Operated by leveraging web pages inside a Native application

SISA W

ebina

r

www.sisainfosec.com

Steps to consider while developing the mobile application

Coding Practices – • Increase code complexity and Use Obfuscation • Avoid Simple Logic • Test Third party libraries • Implement anti-tamer techniques • Securely store sensitive data in RAM • Secure deletion of data • Avoid query string for sensitive data

Handling Sensitive data – • Implement secure data storage • Limit use of UUID • Protect Application Settings • Hide account number and use tokens • Implement Secure Network transmission of sensitive data • Validate input from client

Caching and Logging – • Avoid caching app data • Avoid crash logs • Carefully manage debug logs

SISA W

ebina

r

www.sisainfosec.com

Coding Practices - Increase Code Complexity and Use Obfuscation –

◦ Reverse engineering apps can provide valuable insight into how the application works ◦ Making the application complex internally, will make it difficult for the attacker ◦ Obfuscate all sensitive application code where feasible by running an automated code obfuscation program using

either 3rd party commercial software or open source solutions ◦ Implement anti-debugging techniques (e.g. prevent a debugger from attaching to the process) ◦ Disable logging ◦ Restricting debuggers and Trace Checking

Avoid Simple Logic – ◦ Simple logic tests in code are more susceptible to attack. Example: if sessionISTrusted == 1 ◦ If the attacker can change the one value, they can circumvent the security controls ◦ Consider a better programming paradigm, where privileges are enforced by the server when the session is not

trusted, or by preventing certain data from being decrypted ◦ Integrating techniques such as encryption, timed callbacks and flow-based programming can add complexity for an

attacker.

SISA W

ebina

r

www.sisainfosec.com

Coding Practices - Test Third-Party Libraries –

• Third party libraries can contain vulnerabilities and weaknesses • Developers assume libraries are well-developed and tested, but issues can and do exist in the code • Conduct security audit for all third party libraries and functions

Implement Anti-tamper techniques – • Apps can be tampered with or backdoored and then re-signed by an attacker • Insert malicious functions and publish the malicious versions via third-party markets • Employ anti-tamper as well as tamper detection techniques designed to prevent illegitimate application

from running • Checksum or digital signatures – for detecting whether data files have been tampered with • Use PackageManager class, use public key from the app’s certificate to validate whether it is signed by

developers private key SIS

A Web

inar

www.sisainfosec.com

Coding Practice - Securely Store Sensitive Data in RAM

• Application specific data in RAM are not cleaned properly upon user logout or session time out • Encryption keys can linger in the background • Sensitive data should not be retained in RAM no longer than required • Nullify the variables handling sensitive data • Consider using character array instead of immutable objects

Understand Secure Deletion of Data • Calling file.delete () will not securely erase the file, as long as it is not overwritten • Assume that data written to device can be recovered • Encryption might add an additional layer • Ideally avoid storing sensitive information on the device

SIS

A Web

inar

www.sisainfosec.com

Coding Practice - Avoid Query String for Sensitive Data

• Query string parameters are more visible and be unexpectedly cached (web history, webserver or proxy logs, etc.)

• Use secure POST to send user data, with XSRF token protection. • POST data is not logged by default in areas where query string data can be found • For all POST or GET query, temporary session cookies should be used • Encrypt data using temporary session key can prevent a replay attack

SISA W

ebina

r

www.sisainfosec.com

Handling Sensitive Data Implement Secure Data Storage –

• Do not store / cache data • Transmit and display but do not persist to memory • Store only in RAM (and clear at application close) • Additional layer of Encryption – use third party encryption solution than platform based API’s • Encryption keys should not remain in RAM during the instance lifecycle of the app. Instead, keys should be generated

real time for encryption/decryption as needed and discarded each time. • Do not store sensitive data in the keychain of iOS devices due to vulnerabilities in their cryptographic mechanisms. • Store sensitive data on the server instead in the App • Do not store temp/cached data in a world readable directory. Assume shared storage is untrusted. • Ensure that sensitive data (e.g. passwords, keys etc.) are not visible in cache or logs. • Use a time based (expiry) type of control which will wipe sensitive data from the mobile device once the application

has not communicated with its servers for a given period of time.

SISA W

ebina

r

www.sisainfosec.com

Handling Sensitive Data Protect Application Settings –

• Developers store the application setting in plist file in iOS and XML file or SQLite database in Android • Settings are not encrypted by default and can be read or modified • Compile the application settings into code • Don’t store any critical settings in dictionaries or other files unless encrypted first • Encrypt all configuration file using a master key encrypted with a passphrase that is supplied by the user

Hide Account Numbers and use Tokens – • Many app store complete account number in various screens • Display only partial numbers (e.g. ****4251) • Don’t store the full account number, instead store only the partial number or truncated value • Instead of account number, tokens can be generated and assigned to each account • Token number should not be deductible by user and should have server side mapping

SISA W

ebina

r

www.sisainfosec.com

Handling Sensitive Data Implement Secure Network Transmission of Sensitive Data – • Unlike web browsers, mobile devices do not show when

an app is (or is not) using TLS • And just trusting TLS / SSL certificate is not enough • Consider using asymmetric or symmetric encryption for

encrypting data

Validate input from client – • Even if data is generated by mobile, it is possible that it

might have been intercepted and manipulated • Can lead to buffer overflows, SQL injection and other

attacks • As with web application security, properly sanitize all

inputs from mobile application at server side • User OWASP ESAPI for the same

Limit use of UUID – • Mobile devices have a unique ID (UUID) • Developers have adopted UUID as way of device

authentication, thus making it a foundation of security for many systems.

• UUID tracking will lead to privacy concern and impersonating a user

• Don’t use any device provided identifier for identifying the device (UUID nor MC address)

• Create an app-unique “device factor” at registration • Use the app-unique “device factor” along with user

authentication for creating a session

SISA W

ebina

r

www.sisainfosec.com

Caching and Logging Avoid Caching App Data –

• Data can be stored in variety of artifacts – log/debug files, cookies, web history, web cache, files and SQLite database • Simply do not store / cache data • Prevent HTTP caching • Avoid caching URL history and page data

Avoid crash logs – • If app crashes, the resulting log can provide valuable information to an attacker • Ensure apps are built without warnings and are thoroughly tested to avoid crashes • Also, avoid sending crash logs over the network in plaintext

Carefully manage debug logs – • Debug logs are designed to be used to detect and correct flaw in the application • But these logs can leak sensitive information • Recommend to disable debug logs in the production environment

SISA W

ebina

r

www.sisainfosec.com

For Mobile POS application Additional points to consider while developing mobile POS application – • Card reader should be PCI PTS certified device

• Track2 data and PIN block needs to encrypted using DUKPT encryption algorithm

• Different keys should be used for encrypting track2 data and PIN block • PCI PTS certified SCR device provide API’s, which will return the cardholder

name and last four digits of the card number. Use the API for displaying the card holder details.

• Both track2 and PIN block needs to be encrypted by the SCR and should be decrypted

• If possible, have a HSM (Host Security Module) for decrypting the data at the back-end

• Do not store any sensitive information, even if encrypted in debug logs or database

• Mobile POS application needs to undergo PA-DSS validation service as well SIS

A Web

inar

Thank You! marketing@sisainfosec.com

SISA W

ebina

r