September 11, 2015 By Kevin Beaver 2 min read

With mobile apps so pervasive in the enterprise, it’s surprising to see the minimal effort put into finding and resolving common mobile app vulnerabilities. It’s yet another cog in the wheel of information systems complexity that so many struggle with, despite the fact that mobile apps used for business can introduce an enormous amount of security risks.

Common Security Flaws

Be it an internally developed corporate app, a third-party app used by your employees for specific business workflows or something in between, it probably has vulnerabilities. The following are common mobile app security flaws I often come across that you need to be on the lookout for:

  • Login-related weaknesses, such as being able to bypass the login prompt to perform functions like interacting with external Web applications and services;
  • Allowing users to create weak passwords — or use no passwords at all — that can subsequently be cracked and used against the system;
  • Mishandling of sensitive information, such as storing it locally and transmitting it over the network unencrypted;
  • Malicious code injection, such as requests or queries that can trip up the app and cause it to divulge otherwise protected information;
  • Cryptographic keys hard-coded into the app that can be accessed using mobile forensics tools.

These are just a few examples, but the possibilities are endless given the growing complexity of mobile computing and mobile security.

Testing for Mobile App Vulnerabilities

Ideally, you’ll want to test for these vulnerabilities as part of your software development life cycle. As for application security testing options, there are mobile app source code analyzers, tools that sandbox the apps to check for flaws and, my favorite, good old-fashioned manual analysis. All three types of tests need to be performed if you wish to uncover everything that matters.

If such testing is not an option (i.e., the source code is controlled by a third-party developer or vendor), then ask the outside party for a copy of its latest app security vulnerability assessment and penetration test report. Another consideration to help protect you is to write security requirements — or at least security testing — into your RFPs and contracts related to mobile app development.

Even with such potential business risks, I see many organizations that don’t include mobile apps in their information security program. Are they seemingly too simple to cause harm? Perhaps it’s because they’re often out of sight, out of mind?

Whatever the reason, you have to test the security of your mobile apps before a vulnerability is exploited. Someone, somewhere along the supply chain, needs to be responsible. However, it’s ultimately up to you to ensure the testing happens and your mobile app security stays in check. Get started on it now of your own volition before someone else forces you to.

Watch the on-demand webinar: Shielding Mobile Apps From Fraud and Malware

More from Software Vulnerabilities

FYSA – Critical RCE Flaw in GNU-Linux Systems

2 min read - Summary The first of a series of blog posts has been published detailing a vulnerability in the Common Unix Printing System (CUPS), which purportedly allows attackers to gain remote access to UNIX-based systems. The vulnerability, which affects various UNIX-based operating systems, can be exploited by sending a specially crafted HTTP request to the CUPS service. Threat Topography Threat Type: Remote code execution vulnerability in CUPS service Industries Impacted: UNIX-based systems across various industries, including but not limited to, finance, healthcare,…

X-Force discovers new vulnerabilities in smart treadmill

7 min read - This research was made possible thanks to contributions from Joshua Merrill. Smart gym equipment is seeing rapid growth in the fitness industry, enabling users to follow customized workouts, stream entertainment on the built-in display, and conveniently track their progress. With the multitude of features available on these internet-connected machines, a group of researchers at IBM X-Force Red considered whether user data was secure and, more importantly, whether there was any risk to the physical safety of users. One of the most…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today