Appknox Webinar: Secure Coding Practices to Prevent Vulnerabilities in SDLC

Continuing on the successful webinar journey, last week Appknox hosted a webinar on "Secure Coding Practices to Prevent Vulnerabilities in SDLC." Focusing on secure coding best practices, our experts busted several myths and misconceptions regarding mobile app security in the webinar and highlighted several client-side misconfigurations which generally go unnoticed by the app developers.

The webinar was hosted by Mr Nishaanth Guna (Lead Security Researcher, Appknox), and Mr Subho Halder (CISO, Appknox) who are known across the cybersecurity industry for their unmatchable mobile application security expertise.

So let's explore some of the key takeaways from the webinar and see what secure coding best practices were recommended by our experts.

You can access the speaker’s deck of the webinar here.

Key Takeaways from the "Secure Coding Practices to Prevent Vulnerabilities in SDLC" Webinar

Our webinar on secure coding practices was all about highlighting some of the most common app security misconceptions and covering some key application security concepts like secure data storage, effective cryptography and SSL pinning hacks, understanding fingerprint authentication and tackling client-side misconfigurations. 

Let's take a look at some of the main takeaways from the webinar in detail:

1. Misconceptions Regarding App Security

During the webinar, our experts raised the curtains on a very prevalent misconception in the mobile application security domain.

Myth: If Root/Jailbreak Detection + Tamper Detection + SSL Pinning is implemented can we consider the application to be completely secure?

Reality: Even a combination of all the three above mentioned security controls can be bypassed trivially as the code which verifies and validates these security controls is present on the client-side.

It’s just a matter of time when attackers could breach through these defence walls depending on the level of security controls applied in the app. For example, a very complex implementation like Proguard!= Secure would take more time and resources to break than an easily penetrable security control. 

These 3 controls are critical for applications that contain sensitive business and customer data like banks/fintech/healthcare apps. But these alone would not protect your apps from skilled hackers. Applications should identify/secure both client-side and server-side controls to prevent malicious access or data leakage. Apps should have stringent API and server-side security controls as well.

2. Secure Data Storage Myths and Hacks

Depending on the requirement of the situation, Android provides a number of ways to store user and business data. Apart from the server-side storage, data can also be stored in several ways on the client-side. But the picture regarding secure data storage might be a little different than what you would have thought.

Let's take a look at some of the data storage mediums and how effective they are against common security threats:

• Shared Preference: The data stored on Shared Preferences by default is not encrypted. It should not be used to store PII, credentials, access tokens and so on. In the webinar, our experts explained how users can use sophisticated security libraries to encrypt the data stored over Shared Preferences and prevent data leakage.
• SQLite or Firebase or Realm DB: Similar to Shared Preferences, SQL based storage mediums are also not ideal for sensitive data storage. The plain-text code offers a lucrative opportunity for hackers to break into your application code and find ways to steal your data.
  However, there are a few ways in which data stored through SQL mediums can be protected. In the webinar, our experts recommended the use of the SQLCipher library to encrypt your data.
• Keystore: Keystore is generally recommended by everyone to store sensitive data. People even trust it to store sensitive access tokens as well. Our experts showcased how you can efficiently store your data in encrypted format in Keystore.

Apart from these storage mediums, the data stored in Android Backup, Internal Storage and External Storage, keyboard cache or as screenshots is also highly vulnerable and must be encrypted or stored in preferred channels for more security.

As far as iOS is concerned, application developers can leverage its Data Protection API (commonly called DPAPI) and implement effective access control mechanisms for user data. These APIs use Secure Enclave Processor (also called SEP) for enhanced data protection and key management using advanced cryptographic techniques.

Our experts recommended using KeyChain for storing sensitive user or business information when it comes to storing data on the client-side of iOS apps. KeyChain has permissions enabled which can be set for each entry.

Related Topic: Secrets to Mend Your Mobile Security Early in the Development Life Cycle (SDLC)

3. Implementing Cryptography and Encryption

In the webinar, our experts covered some of the major highlights regarding cryptography and encryption and how these techniques can be implemented to boost your data security efforts.

Our experts answered some really interesting questions revolving around these techniques like what is the difference between encryption and hashing and which one of these is the best to implement and under what scenarios. The major takeaway was that one should never store sensitive information like passwords in an encrypted format.

They also gave recommendations regarding the types of data that should be stored on the client and server-side of the applications. They suggested storing non-sensitive data on the client-side and storing sensitive information like passwords, access tokens etc. on the server-side.

Subho and Nishaanth also explained what an ideal key management strategy should look like and also gave advice regarding secure hashing algorithms like MDS and SHA-1 and also talked about static and dynamic keys. Specific API calls provided by iOS and Android like CryptoCC and javax.crypto can also be used to create secure keys and encryption algorithms.

Related Topic: 5 Things to Do Immediately After Your Startup Is the Victim of a Cyber Attack

4. Client-Side Misconfigurations for Androids and iOS

Another major highlight of the Appknox webinar was a detailed discussion on some of the most critical client-side misconfigurations in both Android and iOS.

For Android

1. Android Backup Enabled

In this misconfiguration, the backup containing sensitive information gets stored in an insecure location and can also be accessed by using ADB (Android Debug Bridge). 

2. Android Debug Enabled

Debug should not be enabled for applications in production. Using this feature, threat actors can debug the application code and understand the logic and even access sensitive application data. 

3. Exporting Activities, Services, Receivers

Turning the export flag in the app to true can bring critical security vulnerabilities to the surface as the exported resources can be accessed by any other app on the device. 

4. Insufficient TLP (Transport Layer Protection)

Using outdated libraries for network communication and using HTTP instead of HTTPS on the client-side can cause serious network layer issues.

5. Misconfigured WebView

Relying on old versions of WebView and not using input sanitization can also make ways for critical security vulnerabilities.

For iOS

1. App Transport Security (ATS):

The ATS feature is present by default in iOS apps (iOS 9.0 and above). This feature improves privacy and data integrity for all the apps and disabling it can cause critical security issues.

2. NSLog Enabled:

This misconfiguration enables added debugging features in the app and is seemingly dangerous. This shows code in plain text and becomes even more vulnerable if connected to the XCode debugger.

3. iOS WebView Misconfigurations:

It should be made sure that data is being loaded over HTTPS while using UIWebView. Moreover, it is also essential to validate the contents of the URL by using dataWithContentsOfURL from NSData. Also, loadRequest should not be used to render local file resources as they might lead to a universal cross-site scripting vulnerability.

Some Important Questions Asked During the Webinar

Some really interesting questions were asked by our audience members during the webinar. We have showcased some of the important ones here:

Q1. Apps protected with commercial security solutions (like Dexguard, IXguard, or Dexprotector) are generally considered secure. But do you have experiences where you still found vulnerabilities in such apps?

Answer: These commercial solutions basically work as obfuscators. They might make reverse engineering difficult for attackers, but most probably they always have some security loopholes when it comes to data storage. We have found such vulnerabilities in many cases.

Q2. Which SSL pinning technique do you recommend? Should it be via Network Config or TruatManager? Also, how should we handle Leaf Certificates in Network Config?

Answer: We recommend implementing SSL pinning via Network Security Configuration. This is by far the easiest and the most effective way to do SSL pinning. You can find a detailed guide on Leaf Certificate implementation here:  https://gist.github.com/approovm/d275ba6940d9c252d85c86c25fce1902

Q3. Should we use the AES algorithm for encryption? If so, which AES block ciphers should we use (eg. AES-128, AES-256, or AES-512)?

Answer: AES can be used for encryption. The point to be noted here is that the higher block ciphers the better. In Android, the AES-128 can be used with an external library called the BountyCastle. As a general rule, AES-256 and above are considered better.

Q4. When we talk about Rooted Devices, how much secure it is to store data in EncryptedSharedPreferences? Also, how can we secure Master Key?

Answer: In order to secure the Master Key, it must be stored on the Keystore. Also, it is recommended that you derive the Master Key uniquely for each new device. When it comes to Rooted and Jailbroken devices, you can't be sure about security while storing data in EncryptedSharedPreferences.

Q5. Some of the solutions mentioned have Runtime Application Self-Protection like Hooking prevention, Jailbreak/Root prevention to prevent dynamic analysis. Are these features useful? Do they assist in secure data storage?

Answer: Yes, these features are useful as they prevent the mobile application from running on rooted or jailbroken devices and also prevent threat actors from performing hooking or debugging on the application. As per OWASP MASVS, these tools help in building resilience, but they don't help in securing data storage.

Q6. What is the best way to store API keys in an Android application?

Answer: When the concerned API Key is a client-side key (like Analytics API Keys/ Maps API Keys) then you can securely store them in the Manifest file. For session keys (like Authentication tokens, JWT tokens) or any other sensitive keys, it is recommended that you store them in Keystore in Android and in KeyChain in iOS.

Q7. Is Recursive hashing(hash(hash(password)…)) a good security approach? Does it make any real difference?

Answer: Recursive hashing can help you avoid a hash collision. But other than that it doesn't have any specific advantage unless and until you are using a very weak hash.

Q8. Are AES/CBC/PKCS5Padding algorithms considered weak? Should we avoid them?

Answer: The AES/CBC algorithm is better than the generally used AES/ECB. Moreover, adding a PKCS5Padding is even better. It is not considered a weak algorithm in terms of secure Mobile Coding practices. Also, for AES, the PKCS5Padding is considered equivalent to PKCS7Padding. You can read more about this in AES RFC.

Q9. Is it secure to keep firebase exported=true in a Manifest file? I struggled a lot while finding the answer to this question, it would be really helpful if you tell me what is the perfect solution for this.

Answer: Instead of using exported=True, it is safe and advisable to set exported=False. You can read more about this here: https://github.com/firebase/quickstart-android/blob/master/messaging/app/src/main/AndroidManifest.xml#L49-L56

Q10. Can DomStorageEnabled(true) in WebView be a security threat?

Answer: No this is not a security threat by itself. This setting acts as local storage for WebView based applications.

Q11. Is UseClearTextTraffic= True a bad setting in terms of security?

Answer: Yes, it is.

Final Thoughts

One thing that we know for sure about mobile application security is that it isn't a benefit or an add-on feature, but a bare necessity. You can't risk millions of dollars and the trust of customers built over a number of years over some silly vulnerability. That is why it becomes essential to implement secure coding practices right from the beginning in your SDLC.

In our webinar, our experts have tried to convey the same message. Do not let your security strategy sit in the comfort zone surrounded by myths. Instead, the developers should always be on their toes while implementing the best data storage, cryptography, SSL pinning and configuration practices and keep their application secure right from the start.