In the past there was an assumption that only popular applications and services will be attacked. But these days even new services with few or no users is liable to find itself under the hacker’s microscope. In a recent //Build session, Josh Dunn discusses some of the common vulnerabilities found in Windows 8 applications.
Avoiding Optimistic Mistakes
A major vulnerability for Windows 8 applications arises from the incorrect use of MSApp.execUnsafeLocalFunction. This function disables the script injection validation rules inside the application, allowing for the same type of vulnerabilities that face websites which display user-generated content.
Script injections are particularly nasty when combined with excessive application permissions. For example, consider an application has the ability to access a user’s pictures library. If the hacker can inject a script, then that script can likewise gain access to the pictures library.
While it may seem obvious, the eval function is another risky function that can introduce a vulnerability into an application. So in general, Microsoft recommends that developers avoid eval and functions with the word “unsafe” in them.
When using JavaScript libraries one needs to take extra care. Libraries that are safe to use in the browser are not necessarily safe to use in a Windows 8 application. The use of WinJS is recommended because Microsoft specifically designed it to be “safe by default”. The assumption is that other libraries will adopt this practice over time.
Another way to reduce problems is to reduce the capabilities the application registers for. In many scenarios the application doesn’t actually need a capability to be useful. For example, applications don’t need the “Documents” capability to load and save documents, you only need it if your application is going to scan the library for a particular file type.
A related problem is unnecessarily registering file extensions. A common mistake is to register the application as a text file handler because it stores some data in a text file. This causes the application to be included in the list of applications that can be started when a text file is opened. The distinction here is the ability to “use” text files versus “handle” text files.
Other capabilities that developers mistakenly enable include Enterprise Authentication and Shared User Certificates. Enterprise Authentication should only be used by internal applications that need to access domain resources. This allows the application to impersonate the user. Shared User Certificates are meant for hardware certificates and smart cards.
Handle Customer Data Responsibility
When requesting data from the user it is important to establish trust from the beginning. Part of this is to tell the user exactly what data is being collected, why, and how the user can opt-out of data collection. Whenever possible, applications need to be able to work without personally identifiable information.
When transmitting personally identifiable information (PII), always use a secure connection. Allowing the information to appear unencrypted in a URL can lead to problems. Or better yet, avoid collecting PII such as serial numbers and IP addresses.
One way to avoid this is the use of the GetPackageSpecificToken function. This token is unique for each application/hardware pair, allowing your application to recognize a given device without using any personally identifiable information. The downside is that multiple applications that work together will need a way to link their respective tokens together.
When working with usernames and passwords, make sure you store them in the secure credentials store instead of local files or application settings.