Building trustworthy Windows Store apps – from d esign to servicing

2. Building trustworthy Windows Store apps – from design to servicing Tiller Beauchamp Senior SDET

3. Why build trustworthy apps? • Trust and reputation are integral. • Your reputation is at the fingertips of the user. • Bad reputation may lead to low app acquisition. • Protect your customers data, privacy, and credentials. • Trust, like reputation, must be built and maintained.

4. Delivering confidence to customers • Trust is part of developing customer confidence. • Three pillars to delivering confidence: • Platform • App isolation, capability model, compiler features. • Windows Store • Onboarding, ratings and reviews, telemetry. • App developers • Follow best practices to design, implement, test, and service apps. • Users can try and buy apps with confidence.

5. Building trustworthy apps • Trustworthy apps are built by following best practices throughout the development lifecycle. • Design • Implementation • Verification • Servicing • Trustworthiness cannot be obtained with an implementation requirement or a test case.

6. Key Design Decisions

7. Choosing a language • Many aspects can influence your choice of language. • Language choice also determines the classes of issues you must protect against.

8. Leveraging 3rd party frameworks • Existing frameworks can be leveraged in your app. • Beware that frameworks may be built with different security assumptions. • Favor frameworks that advertise compatibility with Windows Store apps.Ex: JQuery 2.0 • Good resources to review before including a framework • Microsoft Interoperability blog. • MSDN Windows Store App samples. • Visual Studio Gallery templates and samples.

9. Managing user credentials • Many policy choices for managing authentication. Eg. • Session timeout lengths. • Handling login after app suspension and termination. • Windows.Security.Authentication.Web • Broker for Oauth, OpenID • Windows.Security.Credentials.PasswordVault • Provides app-specific secure storage for passwords and tokens. • Roamed across the users trusted devices. • If you must directly handle user credentials remember to only transmit them over secure channels.

10. Minimize exploit value • Apps with more privileges are more valuable to attackers. • Declare only the capabilities your app needs. • Use file picker instead of declaring library capabilities. • At design time, identify the capabilities that will be needed. • If capabilities must be added during implementation, re-evaluate if new threats will be introduced. • Don’t expose WinRT functionality to the web. • The more capabilities you declare, the more valuable your app is to an attacker.

11. Vulnerability example: exposing WinRT to the web • WinJS.xhr({url:”http://contoso.com/fetchcmd”}).done( • function fulfilled(result) { • varcmd = JSON.parse(result.responseText); • eval(cmd.evalMe); • } • }

12. Vulnerability example: exposing WinRT to the web • WinJS.xhr({url:”http://contoso.com/fetchcmd”}).done( • function fulfilled(result) { • varcmd = JSON.parse(result.responseText); • switch(cmd.apiNum) { • case 0: • localFolder.createFileAsync(cmd.filename).then(function (f){ • windows.Storage.FilIO.writeTextAsync(f,cmd.content); • } • case 1: • …

13. Analyzing the Design

14. App attack surface • Attack surface can be understood by the data flows in and out of the app. • Windows Store app inputs and outputs are more structured and consistent than classic apps. • Attack surface of a Windows Store app can be inferred by capability usage, app contracts, and app extensions. • Attack surface is simply the portions of your app that are exposed to abuse or attack.

15. Plan to mitigate common threats • Most security issues in apps arise from: • Assuming input is trusted when it isn’t. • Failing to protect data in flight or in storage. • Turning off built-in protections. • These issues can be easily avoided by evaluating the attack surface of your app and planning mitigations. • A threat is a potential attack against your app.

16. A simple app has • no attack surface.

17. Attack surface is introduced • when a capability or app • contract is added.

18. Threat modeling process • Enumerate threats that apply to the attack surface. • Identify existing mitigations to those threats. • Design mitigations for unaddressed threats. • Validate mitigations. • Threat taxonomies like S.T.R.I.D.E exist to help organize threat enumeration.

19. Common attack surface of apps • Opening files – files from documents library should be considered untrusted. • The web – consuming remote content. • Contracts – share, actions, search • Extensions Protocol activation – ex: myApp://action/. File activation – ex: somefile.myapp

21. Local context vs. web context • Local context has much higher privilege than web context.

22. Attack surface, threat, mitigation example • Attack Surface: App implements custom URI scheme contosoapp://savecontent?URI={foo}. • Threat: Malicious webpage invokes contosoapp:// URI to cause untrusted content to be saved to the app. • Mitigation: content is only saved if URI parameter has domain = contoso.com or proseware.com.

23. Threat modeling is a brainstorming exercise • Consider each element and dataflow on the attack surface. • What could possibly go wrong? • Assume unencrypted traffic can be read/modify by an attacker. • Assume remote data sources are malicious. • Goal is to ensure that the design is resilient to attack.

24. Implementing a trustworthy app

25. Build testable code • Follow a pattern that produces well factored code. • Model view ViewModel (MVVM). • Test driven development. • Visual Studio Test Explorer for unit testing. • Built-in unit test sample projects. • Visual Studio gallery has additional unit test extensions and frameworks. • Avoid minifying JavaScript code. • Following established patterns can produce code that’s easier to test and debug.

26. Leverage built-in mitigations • Compile with latest version Visual Studio. • /GS, ASLR, DEP, SeHOP on by default. • Automatic script injection protections in WWAs. • Do not disable this protections with execUnsafeLocalFunction.

27. Treat remote data as untrusted • Files in documents library can be malformed. • Brokers pass data directly from other sources. • Data can be tampered with when transferred unencrypted. • Improper handling can lead to: • Script injection in WWAs. • Classic memory corruption flaws in native apps. • When handling data from remote sources, assume that the format might have been tampered with or malformed.

28. Sources of untrusted data • Files (libraries, file picker, file activation) • Protocol activation • Sharing sources • Actions sources • Web content • Messages from iframes and webviews • Only trust data packaged with your app.

29. Handling untrusted data • Leverage platform APIs for handling files, parsing XML and Json. • Validate or restrict source of data where possible. • Sanitize or verify format. • Use a convention to indicate untrusted data • Variable naming or comments • Only trust data packaged with your app.

30. Validate source of postMessage event • // Secure message handler, validates message domain origin • window.addEventListener('message', function (e) { • if(e.origin === 'http://data.contoso.com') { • div.innerHTML= window.toStaticHTML(e.data); • } • }, false);

31. Sanitizing HTML from share source • if(shareOperation.data.contains(StandardDataFormats.html)) { • shareOperation.data.getHtmlFormatAsync().then(function(ut_html) { • if (ut_html!== null) { • vars_htmlFragment= HtmlFormatHelper.getStaticFragment(ut_html); • varmyDiv = document.getElementById("htmlContent"); • myDiv.innerHTML= s_htmlFragment; • } • });

32. Navigating to saved HTML content • You can now navigate a WebView directly to saved content in your AppData directory. • The domain for saved content is based on the directory. • Preserve same-origin policy. • Save HTML content from different domains to different directories.

33. Vulnerability: SOP violation (pseudo code) • page1 = xhr(“http://contoso.com/page1.html”); • page2 = xhr(“http://adnetwork.net/1-78235-872.html”); • Windows.Storage.ApplicationData.current.localFolder.createFolderAsync(“MySaved”); • // save page1 and page2 content to files in MySaved folder • // navigate to page2.html • myWebView.navigate(“ms-appdata:///local/MySaved/page2.html”) • // page2 can access contents of page 1.

34. Using self-signed certs in apps • Create your self signed certificate • Install private key and cert on server • Package your certificate with your app • Declare certificate extension in app manifest • You cert will be installed in a certificate store specific to your app.

35. Adding custom cert in Visual Studio

36. Custom certificate in the app manifest • <Extensions> • <ExtensionCategory="windows.certificates"> • <Certificates> • <CertificateStoreName="Root" Content="myroot.cer" /> • <CertificateStoreName="CA" Content="mystandca.cer"/> • <TrustFlagsExclusiveTrust="true" /> • <SelectionCriteriaAutoSelect="true"/> • </Certificates> • </Extension> • </Extensions>

37. Other Tips • Encrypt sensitive data using WinRT API • Windows.Security.Cryptography.DataProtection • Use XDomainRequest instead of XHR when cookies are not needed • See MSDN documentation and links in resources for more details.

38. Verification

39. Principles of effective testing • Complete coverage • Coverage of all attack surfaces and functional scenarios • Include testing of mitigations. • Repeatable • Automate test cases as much as possible. • Easy to extend • Added app functionality means new tests.

40. Validate mitigations • Identify mitigations that were planned up front • Execute on test cases to validate • Ensure that mitigations: • function properly • cannot be bypassed

41. Validate mitigation example • Contosoapp://savecontent?URI=http://contoso.com/inappcontent/en-us/1234 • Implement a test app to invoke the URI scheme. • Create list of cases that attempt to bypass the check. • http://evil.com/contoso.com/inappcontent... • http://evil.com/&http://contoso.com/inappcontent... • evil.com/http://contoso.com/inappcontent… • … • Mitigation was to validate domain of URI against a white list.

42. Review attack surface • Attack surface is wholly defined in appxmanifest.xml • Capabilities: Network, Libraries and removable storage • Contracts: File save picker, Search, Share, Actions • Extensions:Autoplay, File activation, Protocol activation • Review the manifest file and confirm the attack surface matches the initial design. • Planned attack surface may not be the final attack surface.

43. Hack your app • Follow a black box approach and pretend you are the attacker. • Put on your adversarial hat. • Forget what you know of the design. • Tips: • Use a web proxy to tamper with traffic to your app. • Inspect captured traffic for any sensitive customer data sent unencrypted. • Can a customer configure insecure settings in your app? • Use malformed inputs in search and share contracts.

44. Perform code review • Search the source code and review usage of dangerous APIs. • eval should never be called on untrusted data • execUnsafeLocalFunction should not wrap DOM manipulation functions that operate on untrusted data • scriptNotify/postMessage handlers should not expose WinRT functionality • SDL Banned API list. Ex: strcpy, memcpy, sprintf, etc. • Review usage of sanitizing functions like toStaticHTML, to ensure their code path cannot be skipped.

45. Fuzz test native code parsers • Custom parsing could be: • Media file formats, video streams • Network protocols • Well isolated parsing code can be fuzzed using API fuzzing approach. File fuzzing is another approach. • Favor API fuzzing approach when possible. • Fuzz testing is an effective approach to finding bugs in native code parsers.

46. Document results • Document what was tested, test cases, and results. • You cannot improve without understanding what you’ve done in the past.

47. Checklist before onboarding • Run Windows App Certification Kit • Remove private networking capability if you had added it for local testing. • Strip EXIF data from images (ex: geo coordinates). • Remove debug code. • Do not ship minified scripts or obfuscated code.

48. Servicing

49. Updating your app • Many reasons to update your app • Add new features. • Address customer feedback. • Improve reliability and security. • Include updated versions of third-party frameworks.

50. Windows Store developer dashboard provides telemetry data on JavaScript exceptions, crash rate, and hangs.