As part of creating the app platform for Windows Store apps, one of our primary goals was to ensure that customers have confidence in their apps. We want customers to be confident that their apps will work as they expect, co-exist with other apps, and uninstall cleanly. This confidence comes from a variety of sources – from Windows Store onboarding, to frictionless install and uninstall, to consent for using your location and webcam, to the Windows App Certification Kit for testing that your app meets the Windows Store submission criteria. Customer confidence doesn’t come from any single feature, process, or quality; it’s developed from the sum of different parts, so that customers are confident in the end-to-end process. We’ve described our approach in greater details in a post on Delivering reliable and trustworthy apps.
Now, we’d like to talk specifically about safe and secure apps, and how you can help enable customer confidence with your app. Today’s apps often hold important customer data, from financial records to irreplaceable personal photos. For many customers, this data is their livelihood, and they expect that apps to keep this data safe. Even for apps with minimal data, customers still expect their apps to work as designed and not interfere with other apps.
Implementing security best practices into your app is essential for building customer confidence and delighting customers over time. Fortunately, common security best practices are straight-forward, and it’s not difficult to add security protections to your app. Apps also run in the context of a unique app container that helps insulate it and its data from other apps. App containers provide a dedicated environment for your app, including your own store for data and settings.
Windows 8 and Visual Studio 2012 provide a set of APIs, controls, and tools to minimize possible app vulnerabilities and mitigate common security problems. While no platform is perfect, we are confident that the combination of elements will enable you to build awesome apps, and that the platform will continue to improve over time. In this post, we cover a variety of tips and best practices to enhance your apps so you can offer customers a safer and more secure experience.
Let’s get started!
Tip #1 – Compile with Visual Studio
Starting with Windows 8, we’ve enabled a number of existing security best practices by default, where you don’t need to do anything but compile your app with Visual Studio 2012. When you compile with Visual Studio 2012, security technologies that protect apps from common attacks: (/GS, ASLR, DEP, and SeHOP) are now enabled by default for native code within your app.
Tip #2 – Minimize app capabilities
Apps can each declare capabilities that define how the app can interact with different resources and devices. It’s important to define the minimal set of capabilities that your app needs, so your app runs with the least privilege necessary. By using a minimal set of capabilities, you make your app less vulnerable to exploitation.
As one example, the capability for Home and work networks allowsan app to access computers on a local network, such as for peer-to-peer games. This capability can also be useful for pre-release testing with a local service, but is often unnecessary and can potentially allow the app to be exploited from a local untrusted network, such as a wireless access point in a coffee shop or airport. Consider removing the capability in favor of testing with a remote server, which has the added benefit of replicating real world conditions for your app. If you do use the Home and work networks capability, be sure to remove it before submitting your app for Store certification.
An app with a minimal set of capabilities – just Internet Access!
Note that the capabilities for Enterprise Authentication, Shared User Certificates, and the Documents Library are intended for enterprise access and embedded documents (e.g. opening one document requires opening another document within it), and require a company account in order to submit an app with these capabilities to the Windows Store. These capabilities are typically not needed for most apps, but can be necessary for enterprise apps that need to access corporate resources. These capabilities are highly restricted and using them requires additional Windows Store review.
Tip #3 – Use the file picker instead of library capabilities
Building on tip #2 to minimize your capabilities, you can often remove the file based capabilities altogether. If your app only needs access to a few files, allow the user to select their files with a file picker. The file picker simplifies your apps’ code and allows a user to easily access exactly what they need without additional app capabilities. Because the file picker is consistent across all apps, users will be instantly familiar with the dialog when they use your app for the first time, and can quickly get right back to your app after selecting what they want.
A file picker showing the Pictures Library
In JavaScript
var picker = new Windows.Storage.Pickers.FileOpenPicker();
openPicker.viewMode = Windows.Storage.Pickers.PickerViewMode.thumbnail;
picker.fileTypeFilter.replaceAll([".png", ".jpg", ".jpeg"]);
picker.suggestedStartLocation =
Windows.Storage.Pickers.PickerLocationId.picturesLibrary;
In C#
using Windows.Storage;
using Windows.Storage.Pickers;
FileOpenPicker openPicker = new FileOpenPicker();
openPicker.ViewMode = PickerViewMode.Thumbnail;
openPicker.SuggestedStartLocation = PickerLocationId.PicturesLibrary;
openPicker.FileTypeFilter.Add(".png");
openPicker.FileTypeFilter.Add(".jpg");
openPicker.FileTypeFilter.Add(".jpeg");
As an example of appropriate capabilities, if your app allows a user to select a picture, it should use the file picker instead of the Pictures Library capability. If your app does need full programmatic access to a library, such as for a music player that plays the contents of the Music Library, then it’s reasonable to access the Music Library with a capability. If your app needs to access documents you should always use the picker.
Tip #4 – Don’t trust remote data
For apps written in JavaScript, it’s critical to verify and carefully handle untrusted web content. HTML pages included with the app generally run in the app’s local context, which enables access to the Windows Runtime. Remote pages displayed within an iframe run in the app’s web context, and don’t have access to the Windows Runtime. Know who’s calling the Windows Runtime from within your app - after all, you don’t want an unknown internet site to control your app, do you? (A: No, this is not a good idea.) Your app should avoid calling APIs that execute script such as eval(), setTimeout(), and setInterval() unless you know the API input originates in your package. If you need to use these APIs, remember that they can evaluate script, and you should therefore know exactly how the script is constructed if you’re passing data to these APIs.
If you’re working with JSON data, use JSON.parse instead of eval(), which is far safer and doesn’t expose your app to the risk of script injection.
In JavaScript
var jsontext = '{"firstname":"Aaren","surname":"Ekelund"}';
var contact = JSON.parse(jsontext);
console.log(contact.surname + ", " + contact.firstname);
// Output: Ekelund, Aaren
And lastly, unknown web content used within the app should also be sanitized to remove executable content, using either innerText or toStaticHTML. This sanitization process removes or disables script for showing web content within your app.
In JavaScript
div.innerHTML = window.toStaticHTML(data);
div.innerText = data;
These functions help ensure that any untrusted script or dangerous content cannot run within your app. The first case will strip out script, the second one will turn it into non-executing text. Although most apps will access remote web content through input fields within the app and traditional APIs, such as an XMLHttpRequest object, don’t forget that web content can also enter through other avenues, like through the Share charm.
Tip #5 – Don’t let the web access WinRT
By default, Windows 8 only permits content in your app package to access the Windows Runtime (WinRT). If your app accepts input or data from the web, don’t let that data control your apps usage of any WinRT APIs. Your customers expect to have the confidence that their app behaves as expected, and they expect you to preserve that confidence. If you’re working with a web site, consider showing the site within a sandboxed iframes, which can prevent script, form submission, and other content from running in your app.
If your app executes content from the web, that content could then access the settings and data for your app, or files that your app can also access. This is particularly critical for apps written in JavaScript, where it’s much easier to run script on the fly. For example, if you have an app written in JavaScript that uses postMessage to pass data to a WinRT API or packaged code, make sure you validate the origin for the data to ensure it is from a source you trust.
In JavaScript
window.attachEvent('onmessage',function(e) {
if (e.origin == 'https://www.contoso.com/') {
…
}
});
For additional info on adding web content to an app written in JavaScript, check out the app sample for integrating content and controls from web services.
Tip #6 – Get proof: authenticate your app and customers
Cloud-based apps, where part of the app accesses services in the cloud, are extremely powerful, but need to be prudent in authenticating with the cloud services to prevent abuse. Cloud services that accept user input should always identify and authenticate both users and the app. By authenticating the app and user with a trusted cloud service, you know that someone is legitimately using your service with the exact app that you expect. An added benefit of knowing the user identity is that if abuse happens, you can easily identify and remove all content posted by that user.
You can authenticate the app with GetAppReceiptAsync to validate that the app was obtained from the Store and has a valid Store receipt. If you have a backend server, you can do further authentication with the receipt to confirm the public certificate for the receipt’s signature by connecting to the following URL, where CertificateId included with the receipt.
https://go.microsoft.com/fwlink/p/?LinkId=246509&cid=
WinRT provides a variety of convenient methods for client apps to authenticate the user to a cloud service, including the Web Authentication Broker (for doing OAuth-style authentication), Credential Locker (for storing passwords and small encrypted values), and Shared Certificate Stores (for client certificate authentication). All these are great options for building customer confidence in how you handle authentication and their credentials.
Tip #7 – Validate files, protocols, and imported data
Many apps create and load files, allow activation through a protocol, or provide a means to import data. Like the remote web content described above, this data may be malformed or from less trustworthy sources and should not be trusted. Apps that open files, import data, or accept shared content need to be careful to validate the content before they act on it.
Validation will depend on the type of input and how your app acts on that content, and may range from simple to complex. For example, input used by a database query should be validated to prevent a SQL injection attack because databases will typically execute all valid queries they receive, and can disclose, manipulate, or even delete data with malicious input.
Files, protocols, imported data, and shared content can include untrusted content that may not be what your app expects. Files and protocols are the most common form of untrusted input, but also be careful with the clipboard and accepting content from the Share charm, as customers may be pulling untrusted content from their web browser that could be just about anything. Apps with particularly sensitive data, such as personal financial apps, should be extremely careful with untrusted content as they have access to information that is especially valuable for customers.
Tip #8 – Use HTTPS connections
When in doubt, encrypt! HTTPS connections provide authentication to a remote server and are highly recommended to mitigate man-in-the-middle attacks. While these attacks may not be an issue on your home network, there are still many unencrypted wireless networks across the world where a standard HTTP connection is not secure.
For a standard HTTPS connection, the remote website needs to have a CA-provided certificate, and be configured to allow an HTTP connection. Starting with Windows 8, an app can take advantage of SSL connections using a self-signed certificate to securely authenticate to your backend server. This means that you can have a secure HTTPS connection, even without a CA -provided certificate. If you were avoiding HTTPS due to the cost, there’s no excuse for shipping an app that transmits data over insecure HTTP connections.
To use a self-signed certificate , you can just add a certificate declaration to your app through the Manifest Designer in Visual Studio 2012, or directly to your app manifest XML. You need to also configure your backend server to use the same certificate; for IIS, there’s a simple process to create and configure your web site. Your app then automatically uses the packaged certificate to authenticate the connection to your web server.
And lastly, if you have an app written in JavaScript, you can also require HTTPS connections by using the following tag in your app –
"ms-https-connections-only" content="true"/>
Cultivating confidence
We hope that you’re excited about Windows 8, and building some great apps that we’ll see shortly on the Window Store. The tips and best practices that we have discussed above are an important element for delivering a safer and more secure experience to your customers, so customers are confident that their apps behave exactly as they expect. Security is an expectation for all apps, from protecting hard-fought high scores to sensitive financial data.
Windows 8 and Windows Store apps were designed to make it easy for customers to try and buy apps with confidence, through the collective investments that we’ve made to the app platform. We’re confident that the app platform enables you to build trustworthy apps that people love.
If you’re interested in more info about app security, check out the Developing Secure Apps white paper, the Starter Kit for the Security Development Lifecycle and the Security Development Center for the latest information.
Thanks!
--Scott Graham, Senior Program Manager, Windows
--Crispin Cowan, Senior Program Manager, Windows
--David Ross, Principal Software Security Engineer, Trustworthy Computing Security