Rethinking Mobile App Security: Importance of Client-Side Reviews

When organizations consider securing their mobile applications, the focus often remains server-side APIs. Ideally, this makes a lot of sense since APIs are a common attack surface, and in many cases, the same APIs are leveraged by both web and mobile applications. Security teams usually include these APIs thoroughly as part of web application assessments and penetration testing.

Another critical dimension when it comes to a mobile app architecture is the mobile client itself. A mobile application running on user devices introduce various risks, particularly around data storage & leakage - what data gets stored locally and how that data can be accessed. If we look at the three most common scenarios that make this critical: - 

1. Data Stored on the Client Side (On Mobile Device)
One of the most critical risks that organizations face unknowingly is what data is being stored on the device. If sensitive information such as authentication tokens, personal/PII data, or files with confidential information are cached insecurely, attackers with device access could exploit it.

2. Company-Owned Devices with Third-Party Apps
In some environments, companies use MDM (Mobile Device Management) solutions and disallow BYOD (Bring Your Own Device). Here, employees use only company issued devices, but organizations may still permit third-party applications. In such cases, every approved app release must be reviewed before deployment. Understanding what these apps store locally and whether they touch corporate data like emails/documents etc. becomes quite important.

3. Platforms and Marketplaces
Mobile applications often integrate deeply with an ecosystem when it comes to platform providers or marketplaces. These applications may access or even persist platform data on the device. Having zero visibility into how this data is handled, the risk of leakage grows significantly and can result in significant loss to marketplace providers.

The ever unsolved Local Storage Question
Across all these scenarios, one theme repeats: organizations need to know what is being stored locally and whether sensitive data is at risk.

In mobile applications, data isn’t always stored in plain text. Many applications use hashing, encoding, or even encryption which typically poses an identification challenge. While these methods may look like protection at first glance, they are not always implemented securely. In some cases: -

• Data might be encoded (e.g., Base64), but is easily reversible.
• Weak or custom encryption might give a false sense of security.
• Hashes might still leak valuable patterns or be vulnerable to brute force attacks.

When there is a large chunk of data in terms of device data or heavily loaded log files of the mobile application, manually identifying and validating sensitive data becomes extremely time consuming & inefficient. Due to his, it becomes crucial to introduce automated tools or scripts that can systematically find sensitive data in various storage formats.

A Quick Example
Consider a mobile application that saves the user's session token locally:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

This appears to be random text at first glance. It is actually a JSON Web Token (JWT) that is Base64-encoded. Due to this kind of encoding, anyone with access to the device can decode it and uncover: -  

{
  "user": "acme@acme.com",
  "role": "admin",
  "exp": "2025-08-31T23:59:59Z"
}

 
This shows that sensitive data, including roles, usernames, and token expiration dates, is being stored in local storage. If logs also capture this token (which happens more often than one can think), the exposure multiplies. Without automation, there is a high chance of missing out on spotting such patterns in logs.

Blueinfy’s Approach

At Blueinfy, we have taken a very focused approach to solving this problem. We developed a lightweight client-side mobile review framework that leverages internal technology and automation. Instead of duplicating heavy mobile product testing, our reviews target the most impactful risks:

• Sensitive Information stored in local storage
• Sensitive information left behind in logs (processed at scale using automation)
• Poor SharedPreferences usage and insecure storage practices
• Sensitive or private data sent to third parties

By combining automation scripts with targeted analysis, we can cut through massive logs, detect hidden storage of sensitive data, and flag cases where security controls (hash, encode, encrypt) don’t truly protect the data. The client-side mobile review framework is mainly developed keeping in mind the core problem of leakage of client/sensitive data.

Balancing Quality, Speed, and Cost
This approach allow us to achieve: -
•    High-quality insights: We focus on the areas that matter most.
•    Speed: In rapid agile cycles, automation enables quick reviews.
•    Cost-effectiveness: Real risks being addressed in a fraction of traditional mobile testing costs.

Final Thoughts
In today’s mobile first world, API security is only one part of the story. To truly protect organizational data, companies must also review the mobile client surface, with particular attention to how and where data is stored locally.

At Blueinfy, our approach shows that with the right focus and automation, organizations can uncover risks hidden in storage and logs without sacrificing quality, speed, or cost.

Article by Hemil Shah

Side Communication Channel integration, weaknesses and vulnerabilities for applications

Applications are no longer working in an isolated environment governed by synchronous behavior involving communication with the target (self) only. Instead, applications are well integrated with various different sources and channels in the era of Web 2.0, Mobile and HTML5. Also, SOA (Service Oriented Architecture) with third party API integration has added new communication channels to the application layer. As shown in the figure below, there are few side channels for communication for applications. They serve several different purposes like two factor authentication, password reset, information validations, third party data integration, sync option for mobile apps etc.

This new set of channels opens up integration challenges both at architecture and implementation stages. Hence, it ends up adding weaknesses and vulnerabilities at the application layer and possible opportunities to exploit.

Also, it is important to note that simple automated scanners or tools do not detect these vulnerabilities. It needs meticulously crafted observation, behavior analysis, access to side channels etc. to discover this set of vulnerabilities. Doing manual observation and assessment only can expose and reveal some of these vulnerabilities.

 

Figure 1 – Side Channels for Web Applications

Let’s see some of these issues, which we have discovered during our recent manual assessments across application verticals with examples.

Email Channel

Consider an application using email as a channel to communicate with users in asynchronous off-line mode. Hence, certain features and functionalities would send emails to the user with some information. This information goes over a side channel and it is not a typical synchronous scenario. Hence, if the scanner is not accessing the content of mail and acting on it, then a vulnerability may get missed in that part.

An example of this is an application having “forgot password” functionality. When a user clicks on it, at that point the application sends a link for the user over email and that particular link is vulnerable and can be used to access or reset other user’s passwords with tampering a parameter (say “id” – sequential).

There are several other use cases across verticals like financial, health care etc. using the email channel to communicate with the application user and they can be vulnerable to this set of attacks. One needs to access the content of email and evaluate its impact from a security standpoint.

SMS/Text-Message Channel

Text-messaging is another interesting side channel for application communication and access. Applications are using various tokens for second factor authentication and validating over web applications. For example, banks are using One Time Password (OTP) for transactions or portals are using tokens for authenticating users on the portal and so on.

These tokens are integrated into the web application workflow and in certain cases open up vulnerabilities. For example, consider an application running on 3 step authentication processing for clearing a transaction and validating tokens. One can analyze the work flow and when a token is passed in the second step and sends a response back to the browser, one can trap the response and modify “FAIL” to “SUCCESS”. Now this will go to step three and at this step there is no other validation in place. Hence, a user can actually get access and force a transaction even not having the right token. This is clearly an asynchronous and manual leveraged attack. Automated testing where testing is synchronous by nature can’t perform these attacks.

Mobile/APIs Apps

Mobile applications are using different API based interfaces to access web applications. It is possible that there is a single application which gets accessed by different interfaces like web, android, and iOS based mobile applications. For example, a “todo” application often allows the application to be accessed by a browser through mobile, plug-ins created for Chrome/Firefox as well as an iOs/Android mobile application. This particular application keeps doing “sync” between all these different application components. Mobile applications are using APIs to do constant syncing of tasks. Now this channel becomes side channel communication for the application layer and there could be interesting vulnerabilities in using push or pull for sync function. The token used can be tampered and can allow access to other user’s todo tasks.

Conclusion:

Side channel communication attacks are going to be a reality and it is imperative to have these communication channels along with their integration to the main web applications analyzed thoroughly. This area, in many ways, is untouched and under-assessed during pen-testing. Automated scanners and tools cannot co-ordinate with asynchronous and side channels. The vulnerabilities involved can be of traditional types like SQL injection or abuse of business logic.

Article by Amish Shah & Shreeraj Shah

Tampering HTTP responses – exposing inner secrets of apps

Ajax, HTML5 and mobile-based applications are bringing in some significant changes to next generation application architecture. Hence, it is important to understand HTML5 to get a better security perspective. HTML5 allows applications to run in a thick client environment, have its own file system, SQL database, local variable storage and socket within the browser framework. Whether this instance of the browser is a part of desktop or mobile is immaterial.

Traditional applications have clear layers like presentation, business and data access. Typically, only the presentation layer would run on the client side and the other components would exist on the server side. Hence, the business logic and data access are server side.

In an HTML5 application things can be coded differently. It can have its own powerful business and data access layers. Hence, the developer can migrate some of the server side components to the client side by leveraging these features. As shown in figure 1, the shaded corner rectangle is an overlap, this is the component, which runs on the client side in the browser or mobile (app) and executes within the client framework. This is a significant change; it allows applications to run in offline mode as well. At the same time, some of the server side implementations are now exposed to the client and some threats and security issues can emerge by tampering HTTP responses. HTML5 has a powerful presentation layer with newly added tags and markups. At the same time, mobile’s native applications written on iOS or Android are having great capabilities to host thick features on client side. It also encompasses an effective business layer by having strong APIs accessible by JavaScript or native (mobile) along with the data access layer.

Traditionally, penetration testing of the application is relying on the HTTP request fuzzing and tampering. Not much focus is given to changing and tampering HTTP response streams but things are now changed with modern and mobile architectures driven in API frameworks. With modern browser baked with HTML5 and powerful JavaScripts libraries, it is possible to do a lot more at client side as part of the browser as well as on mobile apps. Some key decision making parameters are coming from server as part of HTTP response and these can be tampered to discover vulnerabilities and get into different flow of application at the browser/mobile end.

 

Figure 1 - Hybrid layers of modern architecture both for web and mobile apps

In current context, JavaScript libraries are allowing to write business logic on client side. During our pen-testing and JavaScript reviews, there have been instances where the response modification and tampering opens up the new functionality on presentation side in complex JavaScripts running on browser or mobile ends. It is new keys to the kingdom and surprising in many cases. It allows attacker to do range of things form abusing functionalities to privilege escalations both on mobile and browser front. Following are some of the examples observed across browser as well as mobile applications, we are sure there are many other outcomes of this technique where focus is kept on HTTP response streams like JSON, XML, Flags etc.

a.) Privilege escalation and role change
Typically, the application would have multiple roles to deal with privileges and authentications. Based on the user role, the application design would serve different user interfaces to the browser and mobile layers. In this case, the application was setting a numeric value once user logs in to “3” for a normal user in the JSON call. User interface will take decision based on this value and build dynamic look over HTML5/mobile interfaces. If the value of the parameter is changed is set to “1”, the application ends up escalating role and now having access to a few more menu items both on web and mobile interfaces. These menus and access are designed for admin only. Hence, major breach is now possible since any user can escalate its role to the admin user as shown below.

 

Figure 2 - Privilege escalation and role abuse

b.) Abusing password functionality
There are certain applications which would have multiple steps on single page to offer change password functionality. In first step user gets a prompt to enter the old password. If the old password matches on the server side, the application redirects user to enter new password and if old password does not match, the application redirect user to enter old password again. This opens up a way to abuse HTTP responses, if attacker modifies the server response from FAIL to SUCCESS in first step, the application redirects user to enter the new password even though old password is incorrect. There is possibility to abuse this scenario as well.

c.) Unauthorized access to mobile screens on device
Many mobile applications are coming up with login screen at the start point and after authentication it sends large JSON stream back as response. Based on various parameters defined on the stream, application loads various pages from mobile device to the end users. This JSON stream coming from response can be polluted and poisoned by tampering values. Hence, application ends up providing set of support and escalated state of the user. Using these cards/pages, user can access various set of paid functionalities, which are not open for free users. This technique is very effective for mobile based applications.

d.) Enabling buttons using java script modification
For example, the application is having a view user profile functionality, which displays the user details including email address as userID with "Save" and "Cancel" buttons. As user has only view permission the "Save" button is disabled. By analyzing JavaScript, one can identify the disabled button. But by modifying the JavaScript in response or in-browser, it is possible to enable "Save" button and submit the record to the server. This allow us to see actual HTTP traffic build and generated by Ajax call as well. Now, it opens up new doors for HTTP request tampering as well.

Conclusion
In this blog write up we have covered four scenarios but there are many more we can identify in Single Page Applications and mobile apps, which are responsive in nature for web based applications. Both mobile and web based applications are leveraging HTML5 and JavaScript heavily along with customized response streams like JSON, XML, JS-Objects etc. Hence, in the era of modern and mobile applications it is not enough to fuzz request streams only, it is imperative to fuzz and tamper response streams as well. It is important to understand role and value of manual penetration testing over automated since automated tools are not using response tampering in usual cases.

Article by Hemil Shah & Shreeraj Shah