1.
Creating Secure Apps Using The
Salesforce Mobile SDK
mvigo@salesforce.com, @martin_vigo
​Martin Vigo, Senior Product Security Engineer
jkinser@salesforce.com
​Jesse Kinser, Senior Product Security Engineer

2.
​Senior Product Security Eng.
​mvigo@salesforce.com
​Senior Product Security Eng.
​jkinser@salesforce.com
Martin Vigo Jesse Kinser
Speakers

3.
Native vs Hybrid
​Overview

4.
Native vs Hybrid
• File system / Insecure storage
• Network communication
• Crypto
• Clipboard
• Backups
• RPC, URL scheme handlers
​Threats
• XSS
• CSRF
• SQLi
• Input validation
• Output encoding
• Application logic flaws

5.
OWASP Mobile Top 10
​2016 version

6.
M1 - Improper Platform Usage

7.
M1 - Improper Platform Usage
• Violation of published guidelines
• iOS Keychain
• Android Intents
• Violation of convention or common
practice
• Unintentional Misuse
• Misunderstanding documentation
• Wrong implementations
​Insecure implementation of native security features

8.
Mobile SDK
• Open source
• Specific security training program for
developers
• Code reviews part of the SDLC
• Security reviews
• In house
• Independent 3rd parties
• Scanners
• Bug bounty program
​Taking advantage of all security layers

9.
M2 – Insecure Data Storage

10.
M2 – Insecure Data Storage
• Explicit storage
• Credentials / OAuth
tokens
• Personal data
• Preferences
• Logs
• Automatic storage
• Temp files
• Cache data
• Leaks
• Logs
• Debugging information
• Crashes
• Analytics
• Caches
• Unique urls
• Requests/Responses
containing sensitive data
• Images
​Leaving traces behind
App Sandbox
External storage
Backups
Hardcoded data

11.
Mobile SDK
• Uses OS provided secure storage for
secrets
• Encrypts sensitive files in the sandbox
• Does not log any sensitive information
• Server-side and client-side cache control
• Cleanup routines for logged out users
​No trace
App Sandbox
External storage
Backups
Hardcoded data

12.
M3 – Insecure Communication

13.
M3 – Insecure Communication
• HTTP
• No confidentiality
• HTTPS
• Version?
• Cipher suites?
• Enforced?
• Mixed content
• Certificates
• Self-signed
• Mismatched hostnames
• Other protocols
• Bluetooth, NFC, etc.
​Eavesdropping

14.
Mobile SDK
• Uses HTTPS only
• Deprecates retired/vulnerable cipher
suites and versions (server side)
• Accepts only trusted certificates
​Properly encrypted communications

15.
M4 – Insecure Authentication

16.
M4 – Insecure Authentication
• Vulnerable APIs
• No authentication
• Poor entropy in tokens
• Weaker authentication than Web version
• Password/Token stored insecurely
• No revocation
​Who am I?

17.
Mobile SDK
• Uses standard protocols
• Oauth 2.0
• No passwords are stored
• Session token stored securely
• Token revocation
• Inactivity logout
​You are who you claim to be

18.
M5 – Insufficient Cryptography

19.
M5 – Insufficient Cryptography
• ROT-13 isn’t the only insecure means of encrypting
• “secret” => “frperg”
• AES - advanced encryption standard
• Secure, but that security depends on
• Key length
• Cipher mode
• Others
• Lots of ways to mess up
• So what can you do?
​Weak protection for your secrets

20.
Mobile SDK encryption support
• AES - CBC
• Secure keys
• Created using native PRNG
• 256 bits
• Unique per installation
• Stored in native secure storage
• Or derived from PIN using PBKDF2
• SmartStore
• Based on SQLCipher
• Secure storage without crypto knowledge
​Crypto following standards and best practices

21.
M6 – Insecure Authorization

22.
M6 – Insecure Authorization
• Insecure Direct Object Reference (IDOR)
vulnerabilities
• User role / Permission transmission
• Hidden endpoints
• Client side checks
​What can I do?

23.
Mobile SDK
• Clear User roles and permission model
• Permission checks on every request
• Based on session ID
• Checks only server side
• Use of public and documented APIs
• Security reviews
• In house
• Independent 3rd parties
• Scanners
• Bug bounty program
​You can only do what you are supposed to

24.
M7 – Poor Code Quality

25.
M7 – Poor Code Quality
• Good developers but limited security
knowledge
• Buffer overflows
• Format string vulnerabilities
• XSS in Webviews
• Ignoring best practices
• No code reviews
​Insecure coding practices

26.
Mobile SDK
• Open source
• Specific security training program for
developers
• Code reviews part of the SDLC
• Security reviews
• In house
• Independent 3rd parties
• Scanners
• Bug bounty program
​Following best practices

27.
M8 – Code Tampering

28.
M8 – Code Tampering
• Attacker modifies binary file
• Applies specially to games
• Cheats
• Free resources
• Etc.
​Binary manipulation

29.
Mobile SDK
• Mobile SDK is open source
• No gain from real-time manipulation
• Compatible with MDM
• Add additional restrictions
​Not applicable

30.
M9 – Reverse Engineering

31.
M9 – Reverse Engineering
• Binary extraction from the device
• Or download binary directly from online
store
• Decrypt/Decompress
• String analysis, binary protections
• Decompile
• Source code analysis
• Disassembly
• Reverse engineering
• Debugging / Real time manipulation
​Protecting binaries

32.
Mobile SDK
• Security though obscurity
• Highly discouraged by the industry
• Mobile SDK is open source
• The more eyes looking at it, the better!
• Mobile SDK uses public/documented
APIs
• No secrets in
• How it is built
• How it works
• How it provides security
• Bug bounty
• Ethical hackers are welcome!
​No need to reverse anything!

33.
M10 – Extraneous Functionality

34.
M10 – Extraneous Functionality
• Hidden menus
• “Legit” back doors
• Debug flags
• Test code
• Comments including sensitive information
in webviews
​Finding edge cases

35.
Mobile SDK
• Open source
• Rigorous deployment cycle
• 3rd party reviews
​Transparent

36.
Conclusions

37.
Conclusions
• Open source platform
• Active project
• Provides secure storage through
encryption
• Enforces secure communication
• Provides easy authentication and
authorization
​What is the Mobile SDK in terms of security?
• Uses platform-specific security mechanisms
• Follows best practices and secure coding
guidelines
• It is constantly reviewed by security
engineers
• Goes through independent security audits
• In scope in our Bug Bounty program

38.
Security @ Dreamforce
​Find the “Salesforce Security” booth in Developer Forest
​Salesforce Security Booth & Developer Sessions Information