This article originally appeared on Microsoft Developer Connection.

OWASP’s Mobile Top 10 is a project launched by OWASP to identify the top 10 risks and threats to mobile apps at large. The project highlights the risk, the impact it could have, and finally some OS-based recommendations. None of which is Windows-based though, so this article discusses the most critical risks to Windows Store apps.

Insecure Data Storage

See: Insecure Data Storage

Sometimes, mobile apps collect, save and transmit sensitive data such as usernames, passwords, personal information, credit card information, etc. Developers might be tempted to store this information on the phone: e.g. SQLite databases, log files, SD Cards, etc. Insecure data storage happens when sensitive data is stored on the device in plaintext. This leaves the data vulnerable to theft if the device was lost or stolen. Malware and other exploits can also be used to steal this data.

The best way to mitigate the risk of insecure data storage is to avoid storing sensitive information on the device in the first place. If you must, then make sure to use ProtectedData.Protect() to encrypt the data before it is stored locally on the device. ProtectedData.Protect() uses Data Protection API (DPAPI) which in turn uses the strong Triple-DES encryption algorithm to encrypt data.

The signature of ProtectedData.Protect() is as follows:

Per the documentation: “The optionalEntropy parameter is an optional parameter used to increase the complexity of the encryption, or null for no additional complexity.”

This led people to think that the optionalEntropy parameter is an initialization vector meant to add extra “randomization” to the encrypted data. However, the optionalEntropy parameter is actually designed to allow applications relying on DPAPI to protect their encrypted data from being decrypted by other malicious applications. That’s why it is highly recommended to use the optionalEntropy parameter.

Weak Server Side Controls

See: Weak Server Side Controls

Mobile apps are basically thick clients, which, more often than not, communicate with a back-end server. Whatever the back-end server is, it needs to have strong security controls. The risk is when the developer relies on the app’s security controls and does not include similar server side security controls. For example, performing input validation on the device only. Most attackers will use HTTP Proxies and other tools to directly manipulate the traffic going to the server, this will bypass the app’s security controls altogether, having strong server-side security controls is the only way to ensure that the validations and security checks are actually exercised.

Insufficient Transport Layer Protection

See: Insufficient Transport Layer Protection

Insufficient transport layer protection issues happen when the data is sent from the mobile app to the server over unsecure channels. Whether the data is transmitted through the carrier network or through WiFi, it will end up through the Internet either way before it could reach the remote server. There are several ways where unprotected data transmitted over the network could be sniffed; things like routers, proxies, cell towers, are some of the few ways data could be sniffed while in transit. OWASP Top 10 points out several great general best practices.

For Windows Store Apps: If you are using StreamSocket, make sure that you use one of the two ConnectAsync()overloads that specify a SocketProtectionLevel.

Make sure to use a SocketProtectionlevel enumeration that does not allow for weak ciphers such as SocketProtectionLevelTls12 or Tls11. Make sure to avoid using PlainSocket, Ssl, SslAllowNullEncryption or Ssl3AllowWeakEncryption for obvious reasons.

Additionally, make sure to avoid using or support the use of RC4 cipher. The main problem with RC4 is a weaknessit has where an attacker can steak a victim’s session in a site protected by TLS.

Client Side Injection

See  Client Side Injection

Client-side injection attacks happen when the application uses untrusted data in a code context, this is very similar to regular web application injection attacks, except for mobile applications, this could happen on the phone as well:

• SQL Injection: Ensure that you are using parameterized queries. Check my  post on how to find SQL Injection weaknesses.
• JavaScript Injection (XSS, etc): This is one of the tougher ones since the attack surfaces (and has also increased tremendously in Windows Store Apps. Things like HTML5, integration of different JavaScript libraries, WinJS Library are some of things that makes JavaScript Injection and Cross-site Scripting attacks much more common in Windows Store Apps). Avoiding this weakness requires rigorous checking to make sure that untrusted data is not rendered back to the user, output encoding is performed every time untrusted data is used. Additionally, make sure to avoid the use of eval() and execUnsafeLocalFunction()at all costs. For more information, check my post on how to find Cross-site Scripting issues.
• Code Injection: Windows Store Apps relies on DirectX as the main graphic library. Since, C++ might be considered to be the first choice by most when writing for DirectX, this opens up the door for buffer overflow attacks and other code injection flaws.
• XML Injection: There are several types of XML Injection attacks, which is a whole different topic on its own, but for the sake of this article, XML injection attacks can be simplified into two main categories: attacks that target the XML document, and attacks that target the parser.XML Parser Attacks: Bryan Sullivan wrote a great article on MSDN on the different types of XML parser attacks and what to do about them. Windows Store Apps prohibits the use of external DTD by default. So ensure that they are not turned back on accidentally using DtdProcessing.Parse enumeration.
• Input Validation: This is not particular to XML injection only, but rather to all the injection attacks in general. All untrusted data should be validated using white-lists.

Poor Authorization and Authentication

See Poor Authorization and Authentication

There are several ways to implement authentication in a Windows Store Apps:

• Basic Authentication
• Authentication via Web Services
• Forms Authentication
• Windows Azure Authentication

Whatever, the authentication method you end up choosing, there are several issues that we usually see while reviewing Windows Store Apps:

• Avoid using the phone’s IMEI or UUID numbers for authentication. These could potentially be compromised, in addition, hardware identifiers are persisted across wipes and factory resets, so the user can’t change them when compromised.
• Always use SSL/TLS for all communication between the app and the server, especially for authentication related requests.
• Never hardcode any usernamespasswords in the code.
• Never perform authorization checks in the app and always validate permissions on the server-side.

Conclusion

Windows 8 introduce great security features to Windows Store Apps. While these features provide excellent foundation to build secure apps and ensure that your clients’ data is safe; implementation flaws, and the lack of awareness of hackers techniques among Windows Store apps developers can lead to unnecessary attacks. These attacks could be easily avoided by following simple recommendations like the one outlined in this article.

References

• How to Encrypt Data in a Windows Phone App
• ProtectedData.Protect Method
• Building Secure Windows Phone 8 Apps – APIs and Techniques