Mobile Payment Application Security Security steps to take while developing Mobile Application s
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 Offering Synergistic Security Framework
Speakers Dharshan Shanthamurthy Renju Varghese Jolly CEO Principal Consultant
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.
Anatomy of a Mobile Attack
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
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
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.
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
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
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
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.
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
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
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
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
Thank You! marketing@sisainfosec.com