OWASP Top 10 Mobile Risks and Threats

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 the capabilities that apps provided.

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…

OWASP Top 10 Mobile Risks

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 the other is your mobile application. Both are on different ends of the city. So even if you have security in one shop, another 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 of 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.

“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 part of the OWASP top 10 mobile lists, 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 the app is tested,” explained Ralph.

Business Risks: Consider all the combined risks of OWASP Top 10 vulnerabilities explained earlier. These vulnerabilities are exploited through 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 gravest 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.

Business Risks: Attackers can get physical or virtual access to the device and exploit the 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 anyone of Frank’s team members 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 devices 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 a chance that it’ll also save sensitive data at any point.”

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

Business Risks: Risks depend 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 is 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 these issues can arise again. That’s why it is important to scan mobile applications 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.

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 top 10 mobile lists.

“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 a mobile device. Interestingly, a 2-minute easy decryption process revealed the password on Ralph’s phone.

“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. On a 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 the 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.

Business Risks: Client-side injection attack allows attackers to steal from the database, change passwords, 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 finds 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 businesses 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?”

“Correct,”

“Now imagine that a malware app on the same phone or some hacker gets this session cookie. Wouldn’t he be able to authenticate fake identity and cause trouble?” 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 an 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 a 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 also account for 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 the US alone. And we haven’t included the sales generated through e-commerce 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 the inherent OWASP top 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?

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.