(Third part of the Indusface OWASP vulnerability educative series. Read Part 1 and Read Part 2)

Now that you already know about Frank and his website security woes, it is time to find out about what he learned about mobile applications. When he launched the mobile app for Fishery of Randomland, it was named ‘iFish’, a project that he thought would take his business forward.   Just like with any other city, people at Randomland were obsessed with smartphones. They loved the technology, its ease, and capabilities that apps provided.

OWASP Mobile Application Risks

Frank later learned that the app was full of website-like weaknesses. A few weeks back he had hired Ralph, Randomland’s security expert, to understand what was causing data breaches and fraudulent transactions. Ralph helped him get rid of website issues, and now it was all about their mobile app..

M1- Weak Server Side Controls

“Why is mobile application my concern now? My customers like it. We built it. Shouldn’t they just install some antivirus app in phone to take care of these issues,” Frank had the usual notion on working of these apps.

“I know it’s difficult, but think of it as two physical shops. One is your website and other is your mobile application. Both are on different ends of the city. So even if you have security on one shop, other one still needs to be protected. Right? It’s the same logic” Ralph made it a bit clearer.

“So, how do we do it,” asked Frank who was already getting over the issues on the website.

“Let’s get over with the first vulnerability for mobile applications. Interestingly, it is actually a chunk everything that can be wrong on the server. So, the first OWASP Mobile Vulnerability is actually the sum of every OWASP 10 Web Application Vulnerability,” Ralph showed everyone the list of OWASP 10 that they had gone through a couple of days back.

OWASP Mobile Application Risks

“Is it even a real vulnerability then? We have already taken care of those 10, right?” Frank wasn’t sure if it was something to be discussed.

“Yes, we have covered those 10. Still it is the part of OWASP Mobile list, given that not all mobile apps have websites too. You can just think of it as a way to ensure server-side security twice when app is tested,” explained Ralph.

Business Risks: Consider all the combined risks of OWASP Top 10 vulnerabilities explained in Part 1 and Part 2. These vulnerabilities are exploited through the mobile applications. Loss of brand reputation, data breach, and financial losses are the top repercussions.

M2- Insecure Data Storage

Knowing that the Fishery of Randomland had already taken care of web application vulnerabilities, Ralph quickly jumped to one of the most grave security issues with mobile apps.

He used an old iPhone to demonstrate the issue. A file system browsing app allowed him to access iPhone files, some of which stored credentials and other critical data in plain text. Anyone with physical access to the device can get this data on Android, Windows, iOS, and BlackBerry OS.

“Look at this username and password along with other personal details. You, actually your application, is allowing unencrypted data on the device, which can be hacked by an individual or malware.  It actually doesn’t take more than a couple of minutes to access such data storage,” explained Ralph.

OWASP Mobile Application Risks

Business Risks: Attackers can get physical or virtual access to the device and exploit customer’s account without his/her knowledge. Such incidences lead to brand distrust and eventually loss of business. Depending on the type of data app is storing, attackers can also cause large identity thefts and fraud transactions.

M3- Insufficient Transport Layer Protection

“Moving on, let’s talk about how data is transmitted through your mobile application. Is it encrypted? Is sensitive data being sent over other channels? Is the Wi-Fi connection or carrier network compromised?” said Ralph.

“That’s why we have SSL protection. It should cover those issues,” Frank argued looking at his team for support.

Before any one of Frank’s team member could speak, Ralph interrupted “While SSL/TLS encryption is one of the better ways to prevent data leakage, your SSL certificate is old, and has low encryption strength. In fact, it doesn’t even cover all on functionalities of the app either. There are chances that hackers will snoop around the communication channels to intercept sessions IDs and other data,” he explained the problems in detail while focusing on getting organization-validated SSL certificates with 2048-bit encryption.

Business Risks: Attackers can violate privacy for individual users. In major attacks, they can perform fraud transactions with identity theft that can later cause business reputation damage.

M4- Unintended Data Leakage

“There are times when mobile device store some application data at a place that is easily accessible by a user or other malicious app on the phone,” Ralph explained.

“Isn’t it exactly what you said about Insecure Data Storage?” Frank asked looking at his app development team members, who nodded in agreement.

“Yes, they are often confused. The Insecure Data Storage is all about exposing critical information consciously, on the other hand, Unintended Data Leakage is more about how OS handles data while application developers have no idea about it,” Ralph went into the details, “Imagine that if Android or iOS by default takes screenshots regularly to analyze app performance, there is chance that it’ll also save sensitive data at any point.”

OWASP Mobile Application Risks

Ralph was right about pointing towards data leakage problems with iFish application. Smartphone OSs regularly keep keystroke auto login, copied messages, temporary directory files and a lot more.

Business Risks: Risks depends on the kind of data being stored on the phones. Personally identifiable information (PII) leads to identity theft. Credit card and credential details cause fraudulent transactions. Loss of customer trust and business reputation damage are always on the cards.

M5- Poor Authorization and Authentication

“Often mobile app developers, either for ease of functionality or simply out of negligence, set poor rules to validate genuine users. Take your iFish application for instance. When you get a request from a certain device id, you authorize it as a genuine customer. I simply have to spoof my device id to access the application and initiate fraud transactions. Then there are autofill password issues that malware and malicious apps in the background can use,” Ralph talked about a widespread problem.

“What problems could that pose? It’s it easy for users that way” Frank acted puzzled.

“It might be but at what cost? Is it okay if someone brute-forced their password? While the risks are high for banking and money transfer apps, you could lose customers through fraudulent transactions too,” Ralph replied with similar intensity.

“And how do we stop it,” Frank was in no mood to debate now. He just wanted it all to be fixed.

“Well, you can implement strong password policies, lookout accounts, keep credentials encrypted or even disable ‘remember me’ feature. However, with every application patch or update, any of this issues can arise again. That’s why it is important to scan mobile application for these weaknesses periodically.

Business Risks: Attackers can take over several attacks at a time. From there, they have the potential to place fraud orders, transfer money, or steal information.

Read Part 2

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.