Security on the Brain
Security is something we all know is important, but is it something that we always do? Most likely, not always. That’s partially because security is complex and takes time to implement. Many of you, these days, don’t have that time (it’s all about shortest time-to-market, right?) to think about security. You make sure that minimal security checks and balances are there, but that’s about it. Totally understand.
But security doesn’t have to be complex to implement once you know what you have already available to you in the frameworks and products that you use every day. Over the course of the next few weeks, check back often as we’ll be demystifying different aspects of application security, simple things you can do to protect your applications, how to use the tools and frameworks you’re already using as your lines of defense against hacking, and more.
Feel free to start or join discussions in the Canadian Developer Connection LinkedIn group to give and receive thoughts and feedback on these or any other topics from fellow Canadian developers and experts.
If you’ve been following my App Building Made Easier series (Parts 1 and 2 here), hopefully you’ve just started building your apps. Before you get too far, one thing that you’ll want to look at sooner rather than later is how you can secure the app. In this guest post, Andrei Marukovich explores several new features that have been added to Windows 8 and Visual Studio 2012 to help you do just that.
Guest post by Andrei Marukovich, Microsoft MVP
Building Secure Windows Store Apps
Application security is a topic of continuous interest and attention. Modern applications are expected to be robust, predictable and respectful of users’ privacy. To help developers build safer Windows Store apps, several new security features have been added to Windows 8 and Visual Studio 2012.
- App sandbox – Windows 8 runtime engine executes Store apps in a special protected container. This sandboxed environment prevents direct communications between Store apps and the system and ensures that other apps will not affect your application’s data or behaviour.
- App capabilities – Every app must declare which data or device capabilities it will use, for example Documents Library or webcam. Explicitly declared capabilities inform the user about your app’s behaviour and let Windows block all requests to undeclared resources.
- Digital signature – All Windows Store apps are signed. They can be signed automatically, using a certificate associated with your developer account, or manually, using your own certificate. Only applications with validated signatures can be installed from the Windows Store.
- Protection against common code exploits – Security techniques such as buffer overflow check, address space layout randomization, and prevention of code execution from data pages are enabled by default for applications compiled using Visual Studio 2012.
When thinking about the security, you should be thinking about securing your app (i.e. your code from hacks or other abuse) and securing your users (i.e. protecting their information). These are a few things that you can do to lock down as much as possible:
Minimize number of used capabilities – By disabling unused capabilities in your app’s manifest, you make the app safer for the customers. It mitigates risks associated with incorrect user’s actions and application errors, makes your app less vulnerable to attacks. For example, Internet capability is switched on by default, but if your app does not require Internet access and does not use AdControl this capability can be safely disabled. Similarly, use of file and folder pickers does not require declaration of library capabilities and when it is possible, you should prefer using pickers instead of direct access to the libraries.
Select and appropriate data storage strategy – The Windows execution environment isolates data and settings storages for Store apps; however, it does not prevent desktop applications from accessing and modifying application data – every stored file is vulnerable. In order to protect user’s data you may consider data encryption, storing data on a remote server (in the Cloud?), or perhaps decide not to store data at all. To help with data encryption, WinRT provides several cryptography-related classes grouped under Windows.Security.Cryptography.Core namespace.
Use credential locker for storing user credentials – As user’s credentials is one of the most sensitive pieces of information, WinRT includes a dedicated mechanism for storing user name and passwords – Credential Locker. It is accessible through the PasswordVault class and allows storing and retrieving user’s credentials. Moreover, the system can roam these credentials between user’s devices, ultimately improving your app’s usability.
Protect your code – As with any other application, Windows Store apps can be disassembled by reverse engineering your algorithms or business logic. Additionally, disassembled code may reveal your encryption algorithms and open a route for accessing user’s data or your assets. Code obfuscation is a simplest approach that can be easily applied to protect your app against reverse engineering. You can also develop critical components using C++ or even move them to a remote server/service where you can fully control the execution environment.
For more on developing secure apps
If you are interested to get more information about security practices for your Windows Store apps, you can have a look at the Developing Secure Apps whitepaper on MSDN.
As always, if you have any specific questions or concerns about Windows Store app security or how to implement security protocols, or if you read something that you want to find more about, feel free to start a new discussion in the Canadian Developer Connection LinkedIn group. Andrei, community experts, and your fellow Canadian developers are there to answer and share.