Creating a mobile app has never been easier with the wide-range of frameworks and languages available at your fingertips. But is it easy to secure a mobile app? Join our mobile security experts as they walkthrough the Salesforce Mobile SDK and learn everything you need to know about hardening your mobile apps. We will discuss common vulnerabilities and mistakes, followed by a dive deep into how the Salesforce Mobile SDK makes following our security best practices easy and painless!

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