The document discusses secure development techniques for mobile apps using the Salesforce Mobile SDK. It covers topics like secure storage, authentication and authorization, session management, and protecting against untrusted inputs. The presenters demonstrate how the Mobile SDK addresses these security issues and makes it easier for developers to build secure apps that integrate with Salesforce. Additional resources on mobile and web security are provided at the end.

1. Secure Salesforce:
Hardened Apps with the Mobile SDK
​Martin Vigo
​Product Security Engineer
​mvigo@salesforce.com
​@martin_vigo
​
​Max Feldman
​Product Security Engineer
​m.feldman@salesforce.com
​

2. ​Safe harbor statement under the Private Securities Litigation Reform Act of 1995:
​This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties
materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results
expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed
forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items
and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning
new, planned, or upgraded services or technology developments and customer contracts or use of our services.
​The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new
functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our
operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any
litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our
relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our
service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger
enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in
our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter.
These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section
of our Web site.
​Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available
and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features
that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
Safe Harbor

3. Slides will be made available after the talk
No photos required

4. Martin Vigo
Product Security Engineer
@martin_vigo

5. Max Feldman
Product Security Engineer

6. https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_10_Mobile_Ris
ks
OWASP Top 10

7. Native VS Hybrid

8. Native VS Hybrid
​Overview

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

10. Binary Protections/Server Side
Controls

11. • Binary protections
• Best practice
• Security through obscurity
• Server side controls
• Our servers take care of this
• The SDK will talk to our APIs
Not applicable
Binary Protections/Server Side Controls

12. Insecure Storage

13. • Explicit storage
• Credentials / OAuth tokens
• Personal data
• Preferences
• Logs
• Automatic storage
• Temp files
• Cache data
Storing secrets the wrong way
Insecure Storage
App Sandbox
External storage
Backups
Hardcoded data

14. • Logs
• Debugging information
• Crashes
• Analytics
• Caches
• Unique urls
• Requests/Responses containing sensitive data
• Images
Leaving traces behind
Data Leakage

15. Broken Crypto

16. • 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?
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_.28ECB.29
Keeping your secrets safe
Encryption
Original Encrypted with ECB mode

17. SmartStore Demo
Secure storage with the SDK

18. How to store a secret
SmartStore

19. Bad TLS / Transport Security

20. • HTTP?
• No guarantee of confidentiality
• HTTPS
• Which protocol? Which version? Which cipher suites?
• How can this go wrong?
• Handled by our servers automatically
• Certificates
• What will we accept? Self-signed? Mismatched hostnames?
• How can this go wrong?
• The mobile SDK will take care of this
Securely transmitting data
TLS/Secure Transport

21. Secure Transport with the SDK
Demo
The SDK can easily handle secure callouts to Salesforce

22. How to query Salesforce securely
Secure Transport

23. Client Side Injection

24. • Tampering with network traffic
• Bypass validations
• Modify user flow
• Break restrictions
• Tampering with the application logic
• Activities / Intents
• RPC and URL scheme handlers
• Memory
Tampering with data locally
Client Side Injection

25. • Validation / Sanitization must be server side
• Everything can be tampered with client side
• Client side validation is only for usability, not security
• Don’t make security decisions based on client side data
Delegating to the server
Client Side Injection

26. Authentication and Authorization
Proper access controls

27. • Authentication – verify that someone claiming to be
“Bob” is indeed “Bob”
• Authorization – verifying that Bob can access only
what he should
• No guarantee of confidentiality
• We want a user to be able to login and access their
Salesforce data
• But we don’t want every app developer to have the
credentials of a Salesforce user
• OAuth allows us to do this
• Only Salesforce sees their credentials
• The mobile SDK makes this easy and accessible
Who is who and what can they access
Authentication and Authorization

28. Session Management

29. • Sessions must be:
• Unguessable/unpredictable
• Short-lived enough to be secure, long-lived enough to be useful
• Other requirements
• The OAuth flow, sessions, tokens are all managed by our servers
• then stored and managed securely by the SDK
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
Session Management

30. Mobile SDK OAuth Demo
The SDK makes OAuth easy

31. Security Decisions via Untrusted
Inputs

32. • Malicious apps can try to interact with our app
• We have to verify who is talking to us
• Use whitelists of trusted applications
• Handlers can trigger sensitive actions
• Make the user aware of them
• Don’t perform actions automatically
• Spoofing / Eavesdropping
• Don’t pass any sensitive information
• Malicious payloads
• Always validate IPC input
Trusting malicious sources
Untrusted Inputs

33. Conclusion

34. • Open source platform
• Active project
• Provides secure storage through encryption
• Enforces secure communication
• Provides easy authentication/authorization
• Uses platform-specific security mechanisms
• Follows best practices and secure coding guidelines
Security-wise
What is the Mobile SDK?

35. • Secure storage and data management
• Use SmartStore
• Secure transport and data transmission
• Use built in SFDC APIs
• Easy and manageable authentication and authorization
• Use SDK’s OAuth handling
• Untrusted inputs
• Salesforce enforces server side validation
Recap

36. • Mobile SDK - https://developer.salesforce.com/page/Mobile_SDK
• Secure Coding Guidelines -
https://developer.salesforce.com/page/Testing_CRUD_and_FLS_Enforcement
• CRUD & FLS Enforcement Guide -
https://developer.salesforce.com/page/Enforcing_CRUD_and_FLS
• Salesforce StackExchange - http://salesforce.stackexchange.com/questions/tagged/security
• Developer.Salesforce.com Security Forum -
https://developer.salesforce.com/forums/#!/feedtype=RECENT&criteria=ALLQUESTIONS
• Security Office Hours (Partners) - http://security.force.com/security/contact/ohours
• Security Implementation Guide - https://developer.salesforce.com/docs/atlas.en-
us.securityImplGuide.meta/securityImplGuide/
Additional Resources

37. Secure Salesforce at Dreamforce 2015
​ 10 DevZone Talks and 2 Lighting Zone Talks covering all aspects
of Security on the Salesforce Platform
​ Visit our booth in the DevZone with any security questions
​ Check out the schedule and details at http://bit.ly/DF15Sec
​ Admin-related security questions?
​ Join us for coffee in the Admin Zone Security Cafe

38. Q&A

39. Secure Salesforce
​ Code Scanning with Checkmarx
​ Robert Sussland and Gideon Kreiner
​ 3:30 pm in Moscone West 2011
​ Lightning Components Best Practices
​ Robert Sussland and Sergey Gorbaty
​ 4:45 pm in Moscone West 2007
​ Common Secure Coding Mistakes
​ Rachel Black and Alejandro Raigon Munoz
​ 5:00 pm in Moscone West 2006
​ Chimera: External Integration Security
​ Tim Bach and Travis Safford
​ Friday, 9/18 10:00 am in Moscone West 2009

40. Share Your Feedback, and Win a GoPro!
3
Earn a GoPro prize entry for each completed
survey
Tap the bell to take a survey2Enroll in a session1