Not all mobile application are as good as they might seem. Why make security tests?

Hi, this is the ASAP Lab security team. No need to say that in eCommerce business the application security is essential for protecting revenue streams and sensitive customer data. Together with the hosting team we constantly monitor the security of CS-Cart projects and on a regular basis audit the core of CS-Cart and Multi-Vendor. Several internal studies based on the results of our monitoring system operation, including the examinations upon the requests of our clients became the reason for writing this article.

To start with, we divided the mobile applications for CS-Cart into three large groups (sorted in descending order of popularity):

Mobile layouts wrapped as an app
Self-written and hand-scribbled applications
Application using the correct CS-Cart API

The official CS-cart API undergoes obligatory and thorough testing, including security testing. “Layout” solutions are nothing but a well-assembled mobile version of the site that opens the resource as a separate browser.

So let’s consider in detail self-written applications. When designing applications, many developers use the API (Application Programming Interface) provided by the CMS, not always fully studying what this or that API is provided for. In this article we’re going to talk about the incorrect choice of API and what can be a result of a design error.

CS-Cart has two APIs. One is provided to administrators to perform works with the store with the highest access level (administrator). And the second API is a public storefront API* that is just right for mobile application implementations. It is used in the official mobile application from the CS-Cart team and the PWAJet solution from the Simtech Development team.

*This API has not been publicly announced yet, but developers can use it by looking at the storefront_rest_api module that comes with CS-Cart builds.

Some developers, seeing the “administrative” API, use it to implement applications, and this is extremely dangerous since the access keys for this implementation are placed in the application itself, which is published in the Google Play Market (Android) and App Store (iOS). And this is equivalent to publicly publishing your login and password, as well as a link to the admin panel on the main page of your store or marketplace.

After downloading the app from the app store and spending some time decompiling and deobfuscating it, we can get the store access keys with maximum privileges. Here you can see two approaches how application developers do it, but they have the same essence and both are extremely dangerous. We also want to note that hackers can as well intercept and analyze application traffic (proxying), but the result will be the same - complete compromise of the project.

In this example we could get almost all source Java code of the application where you can see the “secrets” hardcoded directly into the code.

And in this example we could dig into the Smali code (Assembler for Android Virtual Machine).

What’s next if you have administrator-level API keys and why is it dangerous? You don't need to look hard for examples, just log in to the admin panel and do everything you want https://docs.cs-cart.com/latest/developer_guide/api/entities/auth.html, from creating a database backup and downloading and injecting malicious PHP code into the project code to the complete destruction of the business. It all started with an incorrect choice of API by application developers.

In ASAP Lab when studying the information security problems of projects, we always identify vulnerabilities according to the OWASP framework, using the STRIDE approaches for classification, and DREAD for determining the risk of impact on the system with CVSS v3.1 calculation and preparing POC (proof of concept) for a more accurate understanding of the risk.

For example, communicating with a site without TLS/SSL can lead to the possibility of a MITM (Man-in-the-middle) attack and interference with traffic, but this is usually very rarely seen in the wild. On our managed hosting, we provide all clients with SSL certificates for free and we also help implement the HTTP Strict Transport Security (HSTS) tool, which reduces attacks of this kind by almost 100%.

Check the security of your project

Not all mobile applications are as good as they might seem