For the purposes of the below, let’s set the context that mobile apps include both Windows 8 and Windows Phone apps. Windows 8 introduced several security features, which are being rolled out gradually. Secure Boot, Early Launch Antimalware, as well as the new AppContainer technology added the security controls and features needed to enable developers to build secure and robust apps. I won’t cover Windows Phone 8 in this post, as Mark Arteaga wrote a two-part series, Building Secure Windows Phone Apps, about that. In the first article, he discussed the new security features added to Window Phone apps, and in the second article he discussed a few techniques on how to build secure Windows Phone apps.
While the foundation and the APIs are there to build secure apps, the lack of security awareness as well as implementation flaws can add new attack vectors to your app.
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
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.
Week 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
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.
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 weakness it has where an attacker can steak a victim’s session in a site protected by TLS.
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.
- 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
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 usernames\passwords in the code.
- Never perform authorization checks in the app and always validate permissions on the server-side.
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.