Turn on the news, and you’ll see that everyone’s talking about Web apps right now – using the best ones or building the most popular ones. It seems every developer wants to build the hottest app in town. And why shouldn’t they? There’s no denying that creating the right app for the right market can be an extremely lucrative venture – which might be one reason why their creators often exhibit a sense of urgency in their development cycles. Even in the fast-paced world of tech, these innovators seem to move rapidly when getting their product to market.
That can be a problem, as when the development cycle moves so quickly it will most likely bypass security. Don’t misunderstand – fast-moving technology is fantastic. But when fast equates to shoehorning security controls in after the fact, if at all, we’re left with an approach that has potentially disastrous consequences. Security must be integrated into the application from inception; treating it as an afterthought compromises the application, the user, and potentially an entire company. In a world where a significant percentage of Internet traffic is malicious, applications must be architected and configured with the right security controls from the start.
So why do so many small businesses and startups skip this step? Two reasons: small teams often lack the in-house expertise to build in the security, and they are generally driven by seemingly unrealistic deadlines to produce a product that will make money. It’s an assumption that can come back to haunt them when hackers find an unforeseen security flaw and maliciously exploit it.
The Internet is always evolving, but here’s one thing you can count on: hackers will go after applications both big and small. The most obscure app can attract a cybercriminal’s attention and a major brand’s applications can fall prey to an attack all the same.
In other words, organizations of every size must take precautions. While hackers are undoubtedly getting more sophisticated, even unskilled criminals can manipulate simple requests to gain unauthorized access to data in ways that were not accounted for. Often the attacks are stealthy and subtle, going undetected for months and sometimes years.
Consider Boxee.tv, a Web-based television service acquired by Samsung. While its passwords were cryptographically hashed, hackers were able to obtain the plain-text characters required to access the account with readily available password-cracking tools. The data of more than 158,000 forum users were leaked, including IP addresses, birthdates and password changes. EA Games made news when hackers installed a phishing site on one of its servers to target Apple ID account holders. Using a known vulnerability, the phishing site was set up to obtain information like credit card numbers, birthdates, maternal maiden names and other details before sending the victim to a legitimate Apple site.
Possibly you think that enterprise apps are sufficiently secure against such attacks. Not always; consider Bryan Seely, who was able to intercept FBI and Secret Service phone calls by exploiting a vulnerability in Google Maps. Callers who looked up the agencies’ telephone numbers on Google Maps sometimes found fake listings created by Seely. The calls connected to his own phone account, which then forwarded them onto the real offices while recording the entire call. This wasn’t an isolated case; while Seely’s intention was to push Google to fix the loophole, other spammers have put up fake business listings and forwarded the calls to centers that either overcharge the customer, or sell the leads to other businesses.
Some general security practices differ between mobile and Web apps, creating further risk. Many mobile apps will skip implementing strong access controls and interfaces that limit accessible data; even those that rely on user authentication will often make the classic mistake of allowing mobile sessions to stay live forever. Where most Web application logins will expire after a defined amount of time, mobile app sessions will live forever to spare the user from having to re-authenticate. That provides an easy opportunity for an attacker to intercept that traffic and impersonate that user.
App Developer’s Toolbox
We need to remember that cybercriminals are relentless, smart and creative. While an individual developer or small development team may focus on cranking out a flashy app as fast as possible, improving the security ideology is just as key. Vulnerability intelligence, application scanning and patch management should be part of every app developer’s toolbox. Another smart option: asking a white hat hacker to do their best at cracking the app before it hits the market. Think like a hacker.
There will never come a day when all attacks cease. But integrating security from the very first phase of application development can help even if a breach does occur. Digital comics store ComiXology is proof of that; while they discovered a wide-reaching breach, the hackers weren’t able to get their hands on any payment information as it wasn’t stored on ComiXology servers. Although the attackers did access a database containing usernames, email addresses, and passwords, the passwords were stored in an encrypted form. The company asked customers to change their passwords to be safe, but they avoided the embarrassment and brand damage of a deeper, more catastrophic breach.
Designing a successful application is probably going to remain at the top of many developers’ wishlists for some time. If they want to unleash a truly groundbreaking product, they’ll take note of the ever-growing threats targeting apps and build security in from the start.
Chris Hinkley is a Senior Security Engineer at FireHost where he maintains and configures network security devices, and develops policies and procedures to secure customer servers and websites. Hinkley has been with FireHost since the company’s inception. In his various roles within the organization, he’s serviced hundreds of customer servers, including Windows and Linux, and overseen the security of hosting environments to meet PCI, HIPAA and other compliance guidelines. Previous Columns by Chris Hinkley:App Quest: The Need for Web Application SecurityWhen Technology Isnt Enough: Elevating the Human Element in Preventing Data BreachesGetting a Grip on The Internet of ThingsDisclosure: A Case for Bug BountiesPCI DSS 3.0: The Impact on Your Security Operations
Tags: INDUSTRY INSIGHTS