(The concluding part of the OWASP series on web and mobile application weaknesses. Read Part 1 on mobile applications.)

“Hackers act like water. They take the least resistant way into the system without your knowledge,” Ralph had spent couple of days with Frank and his team trying to figure out what was wrong with their business mobile application.

Although he was proud of what they had achieved so far, there was still a lot of ground to be covered with ‘iFish’, their app for Fishery of Randomland.

M6- Broken Cryptography

“Taking that thought forward, let’s talk about encryption and cryptography, which is apparently the most common security issue with mobile applications,” Ralph continued.

“Wait. So we have already discussed SSL encryption and insecure data storage, is there still a need to encrypt other data?” Frank was genuinely lost with similarities between different vulnerabilities on the OWASP list.

“I know it’s confusing but certain files and pieces of information have to be on the mobile device,” Ralph looked at Frank’s app developers to support his statement.

He then downloaded a couple of decryption software and used them to reverse engineer iFish app’s APK  or Android Application Package, which stores all the critical data on mobile device. Interestingly, a 2-minute easy decryption process revealed the password on Ralph’s phone.

Mobile Application Risks

“See that’s what I’m talking about. If you have to store data on mobile phones, do not use default encryption or weak keys that hackers have access to. Make it tougher,” he concluded on the vulnerability.

Business Risks: Malware or hackers with physical access of the device can hijack user account to place orders, send requests or steal information. At larger scale, it raises questions on business’ security accountability and market reputation.

M7- Client Side Injection

“This is a kind of flashback where you get to use the information we learned with SQL Injection risks. The logic is same; you only have to apply it to the mobile applications,” Ralph looked at Frank hoping that he has the rest of the piece of this vulnerability.

“Okay so bad people…”

“Or malware,” Ralph added.

“Or malware can send a command through forms, login forms or any other input field that we will not be able to filter. Right?” Frank completed hesitantly.

“Brilliant. That’s it. It can be an SQL Injection JavaScript Injection, even XSS injection that will allow attackers to create fake login sessions, install malware, or even steal from the database,” he completed.

Mobile Application Risks

Business Risks: Client side injection attack allows attackers to steal from the database, change password, and access personally identifiable information (PII). Companies can lose credibility, customers and app ratings.

M8- Security Decisions via Untrusted Inputs

The mobile application vulnerabilities were definitely trickier for the entire Fishery of Randomland team, but they had to sit through the discussion with Ralph to finally get over with security woes.

“Suppose you keep a hidden field or functionality within the application, which only top level company users know about. An attacker or malware find it within the application framework and manipulates it to his advantage, it’s a Security Decisions via Untrusted Inputs,” Ralph explained it in detail.

“But we haven’t kept any such functionality or access,” one of Frank’s developers was puzzled.

“Yes, but given the pace at which you are growing, sooner or later you need to have such options. That’s when you need to avoid such issues. Make inter-process communication validated by real users so malware and bots cannot bypass this,” Ralph added.

Business Risks: Attackers grant admin for higher privilege account rights to cause disruption. They bypass security to harm both business and users.

M9- Improper Session Handling

“We, as developers and business managers, try everything to make mobile applications simple and effective for users. Cookie data and session token are two of such options that improve user identification and improve app performance, unfortunately, it also can be manipulated,” Ralph talked about one of the last weaknesses.

“And how does that happen?” Frank quizzed.

“Once a user successfully logs in the application, after authentication you provide a session cookie to the user. It helps him browse seamlessly and perform usual functions, right?”


“Now imagine that a malware app in the same phone or some hacker gets this session cookie. Wouldn’t he be able to authenticate fake identity and cause troubles?” Ralph was talking about the ways that the mobile applications handle sessions.

Business Risks: The risks depend on the kind of session tokens or cookies attackers use. For normal users, an impersonate attack could lead to fake transactions and information loss. On the other hand, if an admin level account is compromised, it would lead to application crash or database breach.

M10- Lack of Binary Protections

“And let’s conclude it with devil’s most preferred and sophisticated tool,” Ralph was excited about this one.

“Let’s hear it,” Frank finally saw it coming to an end.

“What’s the best way to look for weaknesses in a structure? You break it to the basic level, in this case binary code, then find out loopholes to be exploited,” Ralph revealed.

“You don’t mean that. How are they supposed to break an application,” one of the app developers shrugged the idea.

Ralph was quick to show one of such reverse engineering tool in his laptop. ‘iFish’ was void of any binary level protection, which allowed him to break it down in minutes. From there, it was a vulnerability cakewalk.

“Sooner or later, they will find something to use this way,” Ralph concluded.

Business Risks: All kinds of mobile applications are prone to lack of binary protection. Depending on the inherent weakness in code, attackers can get unauthorized access, damage brand and customers. Intellectual property theft and user experience problems are also account to this vulnerability.

OWASP Mobile Security

You will find this Frank-type-mobile-application-story quite often around. With more than 300 million active app users and thousands of apps available for various platforms, it’s kind of obvious that apps are the next big thing.

In fact, app store revenue has been projected at around $77 billion by 2017, in US alone. And we haven’t included the sales generated through ecommerce apps. These are the figures that you easily correlate to websites and online sales a few years back.

At times when business was all about the physical location and presence, website growth seemed improbable. It happened, and happened quickly but companies couldn’t have estimated the grave cost of frauds and data breaches.  Fortunately, we have the data, architecture, and knowledge not to repeat that with mobile apps.

The first step to securing apps is getting them tested with mobile application scanning. Such scanning ensures that your business app doesn’t suffer from inherent OWASP 10 vulnerability. It is also elemental to get application testers on board, who can penetrate or hack app infra in a way hackers do. They can also highlight business logic risks that automated tools would miss.

While testing it once will ensure that an app is secure at that instance, getting it done with every version update will ensure progressive security against data breaches, fraudulent transactions, and downtime.

Do you want to find out how Mobile Application Scanning works? Click here

Founder & Chief Marketing Officer, Indusface

Venky has played multiple roles within Indusface for the past 6 years. Prior to this, as the CTO @indusface, Venky built the product/service offering and technology team from scratch, and grew it from ideation to getting initial customers with a proven/validated business model poised for scale. Before joining Indusface, Venky had 10+ years of experience in security industry and had held various mgmt/leadership roles in Product Development, Professional Services and Sales @Entrust.