Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Creating secure apps using the salesforce mobile sdk

147 views

Published on

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!

Published in: Technology
  • Be the first to comment

Creating secure apps using the salesforce mobile sdk

  1. 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. 2. ​Senior Product Security Eng. ​mvigo@salesforce.com ​Senior Product Security Eng. ​jkinser@salesforce.com Martin Vigo Jesse Kinser Speakers
  3. 3. Native vs Hybrid ​Overview
  4. 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. 5. OWASP Mobile Top 10 ​2016 version
  6. 6. M1 - Improper Platform Usage
  7. 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. 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. 9. M2 – Insecure Data Storage
  10. 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. 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. 12. M3 – Insecure Communication
  13. 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. 14. Mobile SDK • Uses HTTPS only • Deprecates retired/vulnerable cipher suites and versions (server side) • Accepts only trusted certificates ​Properly encrypted communications
  15. 15. M4 – Insecure Authentication
  16. 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. 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. 18. M5 – Insufficient Cryptography
  19. 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. 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. 21. M6 – Insecure Authorization
  22. 22. M6 – Insecure Authorization • Insecure Direct Object Reference (IDOR) vulnerabilities • User role / Permission transmission • Hidden endpoints • Client side checks ​What can I do?
  23. 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. 24. M7 – Poor Code Quality
  25. 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. 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. 27. M8 – Code Tampering
  28. 28. M8 – Code Tampering • Attacker modifies binary file • Applies specially to games • Cheats • Free resources • Etc. ​Binary manipulation
  29. 29. Mobile SDK • Mobile SDK is open source • No gain from real-time manipulation • Compatible with MDM • Add additional restrictions ​Not applicable
  30. 30. M9 – Reverse Engineering
  31. 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. 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. 33. M10 – Extraneous Functionality
  34. 34. M10 – Extraneous Functionality • Hidden menus • “Legit” back doors • Debug flags • Test code • Comments including sensitive information in webviews ​Finding edge cases
  35. 35. Mobile SDK • Open source • Rigorous deployment cycle • 3rd party reviews ​Transparent
  36. 36. Conclusions
  37. 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. 38. Security @ Dreamforce ​Find the “Salesforce Security” booth in Developer Forest ​Salesforce Security Booth & Developer Sessions Information

×