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.
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.
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.
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 weakness it has where an attacker can steak a victim’s session in a site protected by TLS.
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:
See Poor Authorization and Authentication
There are several ways to implement authentication in a Windows Store Apps:
Whatever, the authentication method you end up choosing, there are several issues that we usually see while reviewing Windows Store Apps:
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.