What every developer should know about building trustworthy apps

2. What every developer should know about building trustworthy apps Crispin Cowan, Akriti Dokania Microsoft Windows Security 2-111

3. Agenda • Trustworthy apps lead to user confidence • Threats to confidence • Eight most common pitfalls • … and what to do about them • Further reading

4. Confidence

5. Windows app platform makes it easy to create rich app experiences • Confidence • User confidence comes from trustworthy apps • Nothing bad happens to the typical user • No matter how many Windows Store Apps they try, buy, and uninstall

6. Contribution to confidence • Windows Store onboarding • Windows platform provides app isolation • App developers should use secure development practices to defend app from attack

7. Threats to apps • Threats to apps occur when your app interacts with the world • Apps can be attacked from: • Network • Neighboring apps via Clipboard or contracts like Share • Apps hosting powerful resources (passwords) are attractive targets • Apps can leak valuable secrets to the network • Apps hosting valuable data on a PC that can be physically stolen

8. Security pitfalls in Windows app development • Excess Capabilities • Unnecessary File Capabilities • Storing app state in a user Library • Shipping Debugging Functionality • Unnecessary Special Use Capabilities • Insecure sharing • Not using HTTPS • Trusting untrusted sources • Enforcing service security policies on the client • Storing unencrypted passwords & sensitive data

9. Excess capability pitfalls

10. Pitfall 1: Using unnecessary file capabilities • Pictures, Music, Videos, and Documents • Scenario: your app needs to open and save files … • Pitfall: … so you declare some File Capabilities • Threat: app gets access to many user files • Guidance: only need file capabilities for programmatic access to Libraries • Documents is especially sensitive

11. What capabilities are there?When should they be used?

12. What capabilities are there?When should they be used? Special use Capabilities

13. Pitfall 2: Use capability to store app state • Storing app state in a user library • Scenario: persist app state across uninstalling and re-installing the app • Pitfall: use Library Capability to store app state in a user library • Threat: undermine user confidence in uninstall • Guidance: persist app state in the cloud, associated with your user

14. Pitfall 3: Shipping debugging functionality • Scenario: declare PRIVATE_NETWORK to build client/server app in your private network • Pitfall: shipping with PRIVATE_NETWORK on • Threat: customers may distrust apps that access PRIVATE_NETWORK • Guidance: always disable PRIVATE_NETWORK when you ship

15. Pitfall 4: Declaring any of the special use capabilities • Documents, SharedUserCerts, EnterpriseAuth • Scenario: declare any of enterprise capabilities in a consumer app • Pitfall:not needed for consumer apps • Threat: reduced adoption because of concern for these Capabilities • Guidance: don’t declare any of these unless you have a very specific need

16. Capabilities summary • Capabilities expand resources that your app has access to • The more capabilities you declare: • More customers are wary of buying your app • More attackers are interested in attacking your app • So use Capabilities carefully • Only the minimum necessary for your app

17. Insecure sharing pitfalls

18. Pitfall 5: Not using HTTPS • Scenario: unlike web browsers, users can’t see whether you use HTTP or HTTPS • Pitfall: use plain old HTTP to exchange important data • Threat: HTTP in an open WiFi spot  everything you can be both intercepted and corrupted • Guidance: Use HTTPS wherever possible

19. Easy HTTPS for your service • Perhaps you haven’t bought a server certificate • Windows app platform enables secure use self-signed certs • In app manifest, package a self-signed certificate with “exclusive trust” option enabled • App  Service connectionresists man-in-the-middlethreats • Certificate revocation is easy • Ship an app update that embeds a new certificate

20. Pitfall 6: Trusting untrustedsources • Scenario: FabrikamMessenger client implements “fabmsg:” protocol activation • Pitfall: acting on protocol input without validation • Threat: malicious neighbor app uses your offered protocol to send spam messages • Guidance: get the user to send the message

21. Pitfall 6: Trusting untrusted sources • Scenario: Fabrikam music app, declares itself as file activation extension for .mp3 and .wmv files • Pitfall: file activation  any app can force your app to open any content by claiming it is of that type • Threat: attacker app can force a malformed media file into your app • Guidance: be careful when implementing file activations

22. Pitfall 6: Trusting untrusted sources • “Untrusted source”: input to your app that is not your user or your server • App interaction: allows neighbor app to present anything to your app • So if your app enables app interaction features, you should • Not trust it; validate e.g. ask the user • Parse carefully, preferably with system libraries

23. Pitfall 7: Enforcing service policies on client • Scenario: Contoso cloud storage app & server • Policy: only 20MB/day of transfer bandwidth • Pitfall: enforcing the 20MB per account transfer limit on the client • Threat: user wants to cheat the policy • User modifies your client to remove the 20MB per account transfer limit • Guidance: Always authenticate the user, and enforce the policies on the server against the user

24. Pitfall 8: Unencrypted passwords • Scenario: Stolen PC, lose more than the hardware • Pitfall: leaving passwords on drive unencrypted • Threat: passwords can be read by thief • Guidance: encrypt passwords with Credential Vault

25. Pitfall 8: Unencrypted sensitive data • Scenario: Stolen PC also threatens sensitive app data • Pitfall: leaving sensitive data on the drive unencrypted • Threat: unencrypted sensitive data on drive can be read by thief • Guidance: need the sensitive data to be encrypted, use DPAPI • Windows.Security.Cryptography.DataProtection • Note: stolen PC is the only thing that encryption of data on disk defends against

26. Sharing summary • Encrypt everything youcan that you send on wire/wireless • Use HTTPS • Don’t trust untrusted sources • Protocol activations • File activations • Don’t even trust your own app clients • Authenticate users, enforce policies on your server • Encrypt data at risk if the PC is stolen • Passwords, sensitive data

27. Conclusion Windows runtime provides a foundation for building trustworthy apps and hence user confidence App developers complete the security loop, keep your app’s functionality and user data safe Customers prefer apps that give them confidence their data is safe Avoid these eight pitfalls to deliver confidence to your users

28. Eight security pitfalls • Excess Capabilities • Unnecessary File Capabilities • Use only what you need • Storing app state in a user Library • Store it in the cloud • Shipping debugging Functionality • Test in your production environment before you ship • Unnecessary Special Use Capabilities • Not needed for consumer apps • Insecure sharing • Not using HTTPS • Use HTTPS whenever possible • Leverage self-signed certificates • Trusting untrusted sources • Validate commands • Use system libraries to parse complex data • Enforcing service security policies on the client • Enforce on the server • Storing unencrypted passwords & sensitive data • Encrypt with Credential Vault, DPAPI

29. Required Slide *delete this box when your slide is finalized Your MS Tag will be inserted here during the final scrub. Evaluate this session • Scan this QR codeto evaluate this session and be automatically entered in a drawing to win a prize!