Security for Windows Phone 8
[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]
Windows Phone is designed to deliver a compelling experience that users can customize with a wide variety of apps from trusted, safe sources. It's important to keep security in mind when developing your app so that end users can feel comfortable and have the best phone experience.
This topic contains the following sections.
The Windows Phone app platform incorporates a number of technologies that are designed to help maintain a quality experience for the end user when downloading and using third-party apps on a Windows Phone. The concerns addressed by these technologies can be divided into three broad categories:
Quality of phone experience. End users want to feel comfortable that the apps they acquire will not adversely affect their phone experience, such as making the phone less responsive or making changes that will affect other apps or the phone itself. Further, it is important that apps are easy to uninstall and that they uninstall completely, should the end user decide for any reason that they no longer want a particular app on their phone.
Access to the user's information. End users want to feel comfortable that the apps they acquire will not access certain information without their knowledge. This includes information such as their personal data, their contacts, their geographic location, and their photos.
Billable events. End users want to feel comfortable that apps will not perform actions that incur additional costs without their permission. An example is an app that makes a phone call to a 1-900 phone number.
The Windows Phone app platform includes several measures designed to address these concerns and foster a healthy system in which end users are empowered to try apps.
One of the goals of the Windows Phone app platform is to foster the creation of apps that are secure by design and secure by default. An important aspect of achieving this goal is to integrate several security safeguards into the development environment and lifecycle. A good example is the mandatory and automated digital signing of all apps that are approved for sale in the Windows Phone Store.
To facilitate the security measures that are in place for the benefit of end users, app developers are required to follow these steps:
Sign up as a Windows Phone developer, provide information about themselves as an ISV (which is subject to verification), and pay the associated fee.
Acquire the recommended development environment (free versions are available).
Develop a Windows Phone app in accordance with the standard practices specified for Windows Phone app development. To facilitate easier testing, developers will be able to register one or more Windows Phones as development devices, thereby allowing them to run an app during development and prior to it being digitally signed during the app submission and certification process.
Submit a Windows Phone app for inclusion in the Windows Phone Store. This process will subject the app to a variety of publicly documented certification tests, as described at App certification requirements for Windows Phone. If the app passes all of these tests, it will be digitally signed on behalf of the developer and made available for sale in the Windows Phone Store.
By conforming to this structured development environment and process, developers will be doing their part to create an app ecosystem for Windows Phones that inspires confidence in end users.
This structured development platform and execution environment also contains safeguards designed to help protect the intellectual property of developers. For apps to run on a Windows Phone, a valid license that is issued by the Windows Phone Store must be present on the phone. This means that even if a technically savvy end user figures out how to circumvent the Windows Phone Store and load an app onto their phone in some other way, Windows Phone will not allow it to run if the license is not available, thereby helping to protect the fruits of the developer’s labor.
The Windows Phone app platform employs a variety of technologies designed to help protect Windows Phone end users from apps that exhibit certain unwanted behaviors:
The structured app submission and certification process includes a suite of certification tests to identify certain behaviors that may be associated with problems and prevent those apps from being offered in the Windows Phone Store.
The Windows Phone Store is the only legitimate source of app acquisition, mandatory code signing, and app licenses. This approach will help to maintain a consistent set of standards for Windows Phone apps.
Windows Phone apps run in a sandboxed process. This means that they are isolated from each other, and will interact with phone features in a strictly structured way. If an app needs to save data or configuration information, it will do so using isolated storage, which is designed to be protected from access by other apps. Apps can only communicate with each other through controlled mechanisms. For more information about isolated storage, see Data for Windows Phone 8.
Windows Phone apps are run under the supervision of an execution manager. The execution manager will measure whether apps behave as required by certain defined conventions. For example, the execution manager monitors the use of resources by apps that are not in the foreground, and terminates non-foreground apps as needed to make the foreground app more responsive to the user.
The sandboxed process within which a particular app runs has a customized set of security capabilities. The Windows Phone app platform is designed to minimize the attack surface area of each app by only granting it the capabilities that it needs in order to run. For example, if an app does not require the use of the Media Library, the Windows Phone app platform will seek to execute it in a sandboxed process that does not have access to the Media Library.
Certain capabilities that an app might need have a direct impact on information access or cost. In such cases, the Windows Phone Store will disclose this information to the end user before the app is purchased. Preinstalled apps are also required to disclose this information to the end user upon first use of the app.
The SDL is a security assurance process that is focused on software development. It is a collection of mandatory security activities, grouped by the phases of the traditional software development life cycle. Many of these security activities would provide some degree of security benefit if implemented on a standalone basis. However, practical experience at Microsoft has shown that security activities executed in chronological order and as part of a repeatable process can result in greater security gains than those resulting from ad-hoc implementation. Combining a holistic and practical approach, the SDL introduces security and privacy throughout all phases of the development process with the goal of protecting end-users. For more information about the SDL, see SDL Process Guidance.
Microsoft offers many SDL tools for developers to use with their apps. As a Windows Phone developer, there are several tools that can be helpful:
The SDL Threat Modeling Tool enables non-security subject matter experts to create and analyze threat models by communicating about the security design of their systems, analyzing those designs for potential security issues using a proven methodology, and suggesting and managing mitigations for security issues.
FxCop is a static analyzer. It analyzes managed code assemblies and reports information about the assemblies such as possible design, localization, performance, and security improvements.
The BinScope Binary Analyzer is a verification tool that analyzes binaries to ensure that they have been built in compliance with the SDL requirements and recommendations. BinScope checks that SDL-required compiler/linker flags are being set, strong-named assemblies are in use, up-to-date build tools are in place, and the latest good ATL headers are being used. BinScope also reports on dangerous constructs that are prohibited by SDL.
The MiniFuzz File Fuzzer is a basic testing tool designed to help detect issues that may expose security vulnerabilities in file-handling code. This tool could be helpful for Windows Phone developers that parse files in their applications.
The banned.h header file is a sanitizing resource which supports the SDL requirement to remove banned functions from code. It lists all banned APIs and allows any developer to locate them in code. This tool could be helpful for developers that are building a Web service.
You can connect to a web service using an SSL connection as long as the server’s SSL certificate is valid for the target web site and issued by a trusted authority. Before testing the SSL connection from your app, you can try to navigate to the web site using Windows Phone Internet Explorer. If the certificate causes a warning or error while using the browser, it is likely that the connection will fail in your app as well.
To see a list of SSL root certificates that ship with Windows Phone, see SSL root certificates for Windows Phone OS 7.1.
You can add a certificate authority to the trusted authorities list, but adding Client SSL certificates is unsupported.
For more information about how to handle security with web services, see Web service security for Windows Phone 8.
See App capabilities and hardware requirements for Windows Phone 8 for more information about capabilities in Windows Phone.