In the 1990s, client-server was king. The processing power of PCs and the increasing speed of networks led to more and more desktop applications, often plugging into backend middleware and corporate data sources. But those applications, and the PCs they ran on, were vulnerable to viruses and other attacks. When applications were poorly designed, they could leave sensitive data exposed.
Today, the mobile app is king. The processing power of smartphones and mobile devices based on Android, iOS, and other mobile operating systems combined with the speed of broadband cellular networks have led to more mobile applications with an old-school plan: plug into backend middleware and corporate data sources.
But these apps and the devices they run on are vulnerable… well, you get the picture. It’s déjà vu with one major difference: while most client-server applications ran within the confines of a LAN or corporate WAN, mobile apps are running outside of the confines of corporate networks and are accessing services across the public Internet. That makes mobile applications potentially huge security vulnerabilities—especially if they aren’t architected properly and configured with proper security and access controls.
Speed (to market) kills
Today we have tools like PhoneGap and Appcellerator’s Titanium platform as well as a host of other development tools for mobile platforms that resemble in many ways the integrated development tools of the client-server era (such as Visual Basic and PowerBuilder). So individual developers and small development teams can easily crank out new mobile apps that tie to Web services, hooking them to backend systems launched on Amazon at high speed.
But unfortunately, they all too often do so without considering security up front, creating the potential for exploitation. While a lot of attention has been paid to security on the device itself, the backend connection is just as, if not more, vulnerable.
If companies are lucky, like Montreal-based SkyTech Communications, those holes merely produce public embarrassment. When a computer science student at a vocational college used a freely downloaded security scanner on SkyTech’s mobile app (which allows students to access their records and register for classes), he found major security flaws in the application. These flaws allowed anyone to gain access to students’ personal information.
Small developers aren’t the only ones who can get caught by their mobile app backends. Take, for example, General Motors’ sudden leap forward with its OnStar Web API. The company was forced to accelerate a public API effort when it discovered an enterprising Chevy Volt owner had reverse-engineered its mobile application API for retrieving vehicle statistics from OnStar’s data centers for personal use. Fortunately, he wasn’t malicious. But he did build a website for other drivers to do the same—which potentially exposed personal data in the process by using those drivers’ OnStar account logins, in violation of GM’s privacy rules. The site now runs on a new, more secure API.
Keeping the client (mostly) dumb
"This sort of thing has been a problem since computers started talking to each other," said Kevin Nickels, the president and CEO of "backend as a service" provider FatFractal. To prevent these sorts of problems—or worse—developers need to address issues like security and access control early on. "Too often, developers try to address these after the fact, and not from the very beginning," Nickels explained.
One of the key elements of security design in mobile applications is making sure that the client—the phone app itself, or the browser app—does very little processing. "The general best practice is to let the code on the device do as little as possible," said Danny Boice, the co-founder and CTO of Speek, a cloud-based conference call service that works through native mobile clients and Web browsers. (Boice is also a former executive in charge of Web and mobile development for the SAT testing company, The College Board.) "There are things on a person’s phone that you can’t control. We put most of the heavy lifting off of the client, because you can control what the application sends and receives."
It’s especially important to handle all data integration with other services on the backend and not on the mobile device, says Nickels. "Ads exposed in an app, for example, could have malicious code. We recommend people do that sort of integration via the backend. That way, things coming from outside the app won’t have any access to any system resources at all."
Dan Kuykendall, Co-CEO and chief technology officer of security testing firm NT Objectives, said the less mobile apps store and process data on the client device, the better. "A lot of developers think, ‘The only traffic that’s going to come in is from my mobile app’," Kuykendall explained. "And they build logic into the mobile client"—building queries to be sent to the backend systems and processing raw data sent back. But requests from the app can easily be "sniffed" by someone who has the application on a device of their own, by malicious software on the device that might monitor outbound traffic, or by someone maliciously monitoring what comes off mobile devices. "You don’t want the app passing SQL statements back to the backend," Kuykendall said. "That’s crazy." But as he says, that’s also all too common.
The most basic bit of hardening required for mobile applications is to encrypt traffic to the backend—at a minimum, by using Secure Socket Layer (SSL) encryption. But SSL by itself isn’t enough because of the nature of how mobile devices connect. Many smartphones will automatically connect to available open Wi-Fi networks they remember, making it relatively easy to get them to connect to a rogue device that can act as an SSL proxy, decrypting and re-encrypting traffic while recording everything that passes through. While SSL is usually a defense against attacks on browser-based sessions on PCs, some mobile apps are vulnerable because they rely on WebKit to handle SSL. WebKit doesn’t fail by default with bad certificates like those used in "man in middle" (MIM) attacks—it sends an error message to the app that a cert is bad, and lets the code decide what to do about it. In some cases, to get around errors, apps get set to accept any cert, so they’re vulnerable to MIM attacks.
"I can sit in a public place, like the mall, with a Wi-Fi Pineapple and my laptop," Kuykendall said, "and deliver real Internet access with me as a ‘man in middle’, and see the traffic coming from people’s smartphones without them knowing their smartphone is connected to me. And when apps fetch updates, I see that." Since many mobile apps fetch updates without user interaction, "the users aren’t instigating the connection—it just happens." If data pulled from a man-in-the-middle attack doesn’t have additional sorts of controls and protection, it could then be used to attack the backend systems.
Another vulnerability caused by putting too much reliance on the client is that it requires more data to be stored on the client—data that could be exploited. Even ephemeral data (information stored locally to be processed for display or to be sent to the backend and then be disposed of) is vulnerable. "It’s not so easy to get into a running app and steal stuff," Nickels said. "It’s more of an issue with a data cache or on-phone storage, using databases like SQLite. You need to obfuscate that data as best as you can, encrypt it at rest, and store things that are not easy to associate with each other."
Source: http://arstechnica.com/security/2013/02/mobile-app-security-always-keep-the-back-door-locked/
