What every developer should know about building trustworthy appsCrispin Cowan, Akriti DokaniaMicrosoft Windows Security2-111

Trustworthy apps lead to user confidenceThreats to confidenceEight most common pitfalls• … and what to do about

themFurther reading

Agenda

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

Confidence

Windows app platform makes it easy to create rich app experiences

Windows Store onboarding

Windows platform provides app isolation

App developers should use secure development practices to defend app from attack

Contribution to confidence

Apps can be attacked from:NetworkNeighboring 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

Threats to apps occur when your app interacts with the world

Threats to apps

Security pitfalls in Windows app development

Excess Capabilities1. Unnecessary File

Capabilities2. Storing app state in a

user Library3. Shipping Debugging

Functionality4. Unnecessary Special Use

Capabilities

Insecure sharing5. Not using HTTPS6. Trusting untrusted

sources7. Enforcing service security

policies on the client8. Storing unencrypted

passwords & sensitive data

Excess capability pitfalls

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

Pictures, Music, Videos, and Documents

Pitfall 1: Using unnecessary file capabilities

What capabilities are there?When should they be used?Group Capabilities UseFile/Library Pictures, Music, Videos,

Documents• When you need programmatic

access, e.g. play all music vs. play a single sound

Devices Microphone, WebCam, Location

• When you need access to the corresponding device

Network InternetClient, InternetClientServer, PrivateNetwork

• Mostly just use InternetClient• Use InternetClientServer for peer-

to-peer• Use PrivateNetwork for LAN access

Enterprise EnterpriseAuthentication, SharedUserCertificates

• Heavy-duty authentication to enterprise resources

What capabilities are there?When should they be used?Group Capabilities UseFile/Library Pictures, Music, Videos,

Documents• When you need programmatic

access, e.g. play all music vs. play a single sound

Devices Microphone, WebCam, Location

• When you need access to the corresponding device

Network InternetClient, InternetClientServer, PrivateNetwork

• Mostly just use InternetClient• Use InternetClientServer for peer-

to-peer• Use PrivateNetwork for LAN access

Enterprise EnterpriseAuthentication, SharedUserCertificates

• Heavy-duty authentication to enterprise resources

Special use Capabilities

Scenario: persist app state across uninstalling and re-installing the appPitfall: use Library Capability to store app state in a user libraryThreat: undermine user confidence in uninstallGuidance: persist app state in the cloud, associated with your user

Storing app state in a user library

Pitfall 2: Use capability to store app state

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

Pitfall 3: Shipping debugging functionality

Scenario: declare any of enterprise capabilities in a consumer appPitfall: not needed for consumer appsThreat: reduced adoption because of concern for these CapabilitiesGuidance: don’t declare any of these unless you have a very specific need

Documents, SharedUserCerts, EnterpriseAuth

Pitfall 4: Declaring any of the special use capabilities

Capabilities summaryCapabilities expand resources that your app has access to

The more capabilities you declare:More customers are wary of buying your appMore attackers are interested in attacking your app

So use Capabilities carefullyOnly the minimum necessary for your app

Insecure sharing pitfalls

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

Pitfall 5: Not using HTTPS

Easy HTTPS for your servicePerhaps you haven’t bought a server certificateWindows app platform enables secure use self-signed certsIn app manifest, package a self-signed certificate with “exclusive trust” option enabledApp Service connectionresists man-in-the-middlethreatsCertificate revocation is easyShip an app update that embeds a new certificate

Pitfall 6: Trusting untrustedsources

Scenario: Fabrikam Messenger client implements “fabmsg:” protocol activationPitfall: acting on protocol input without validationThreat: malicious neighbor app uses your offered protocol to send spam messagesGuidance: get the user to send the message

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

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

Pitfall 6: Trusting untrusted sources

Scenario: Contoso cloud storage app & serverPolicy: only 20MB/day of transfer bandwidth

Pitfall: enforcing the 20MB per account transfer limit on the client

Threat: user wants to cheat the policyUser 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

Pitfall 7: Enforcing service policies on client

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

Pitfall 8: Unencrypted passwords

Scenario: Stolen PC also threatens sensitive app dataPitfall: leaving sensitive data on the drive unencryptedThreat: unencrypted sensitive data on drive can be read by thiefGuidance: need the sensitive data to be encrypted, use DPAPIWindows.Security.Cryptography.DataProtection

Note: stolen PC is the only thing that encryption of data on disk defends against

Pitfall 8: Unencrypted sensitive data

Sharing summary

Encrypt everything youcan that you send on wire/wirelessUse HTTPS

Don’t trust untrusted sourcesProtocol activationsFile activations

Don’t even trust your own app clientsAuthenticate users, enforce policies on your server

Encrypt data at risk if the PC is stolenPasswords, sensitive data

ConclusionWindows 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

Eight security pitfallsExcess Capabilities

1. Unnecessary File CapabilitiesUse only what you need

2. Storing app state in a user LibraryStore it in the cloud

3. Shipping debugging FunctionalityTest in your production environment

before you ship4. Unnecessary Special Use

CapabilitiesNot needed for consumer apps

Insecure sharing5. Not using HTTPS

Use HTTPS whenever possibleLeverage self-signed certificates

6. Trusting untrusted sourcesValidate commandsUse system libraries to parse complex data

7. Enforcing service security policies on the clientEnforce on the server

8. Storing unencrypted passwords & sensitive dataEncrypt with Credential Vault, DPAPI

Evaluate this session

Scan this QR code to evaluate this session and be automatically entered in a drawing to win a prize!

© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.