what every developer should know about building trustworthy apps
DESCRIPTION
What every developer should know about building trustworthy apps. Crispin Cowan, Akriti Dokania Microsoft Windows Security 2-111. Agenda. Trustworthy apps lead to user confidence Threats to confidence Eight most common pitfalls … and what to do about them Further reading. Confidence. - PowerPoint PPT PresentationTRANSCRIPT
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.