Risk
11/21/2011
05:50 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Develop Secure Mobile Applications

We share best practices to create safe mobile apps for users and customers.

InformationWeek Green - Nov. 28, 2011 InformationWeek Green
Download the November, 2011 InformationWeek secure mobile apps supplement, distributed in an all-digital format as part of our Green Initiative
(Registration required.)
We will plant a tree for each of the first 5,000 downloads.

Secure Mobile Apps The runaway success of mobile devices and apps like Angry Birds has touched off a frenzy of development, as companies rush to roll out apps for consumer and enterprise markets alike. These days, if your business isn't on a mobile platform, it's nowhere. But when developers are under pressure to release new applications, security is often an afterthought. That's bad news for consumer data, applications, and a company's infrastructure.

We've been here before, of course. It happened with client-server applications, then Web applications, and now mobile platforms. The more code that's written and the more platforms on which it runs, the more vulnerabilities will be present. It's safe to assume that all applications have security flaws, and those written to run on mobile devices are no exception.

What follows is a look at several challenges to securing mobile applications and guidance on what you can do about them.

Work Security In Early

Developers are pushing out code as fast as they can, and security concerns can easily get lost. In hypercompetitive markets, the business very likely isn't going to tolerate slowing the release rate to accommodate secure coding practices. To avoid being blamed for late releases, security pros must find ways to implement security without affecting timelines.

First, you must find low-impact ways to meet security requirements. Use automated code-analysis software during the build and test process, perform security testing during quality assurance, and work with developers to use standard preapproved libraries that have been reviewed for security. These steps go a long way toward reducing the effort required in the final security review, which typically occurs at the end of the development cycle and leaves little time for security testing and remediation.

Pay Attention To Web Links

Mobile applications typically connect to Web apps to send, retrieve, and process data, so the Web application layer presents significant risks. If you're performing code reviews, using standardized libraries, and applying other application development processes to protect Web applications, you're already doing a lot of what's needed to secure mobile applications.

Keeping Data Safe on the Move

Our full report on security and mobile applications is free with registration.

This report includes 14 pages of action-oriented analysis to help you secure mobile apps. What you'll find:
  • Best practices on secure app development
  • Advice for security teams on working with developers
Get This And All Our Reports


Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6335
Published: 2014-08-26
The Backup-Archive client in IBM Tivoli Storage Manager (TSM) for Space Management 5.x and 6.x before 6.2.5.3, 6.3.x before 6.3.2, 6.4.x before 6.4.2, and 7.1.x before 7.1.0.3 on Linux and AIX, and 5.x and 6.x before 6.1.5.6 on Solaris and HP-UX, does not preserve file permissions across backup and ...

CVE-2014-0480
Published: 2014-08-26
The core.urlresolvers.reverse function in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not properly validate URLs, which allows remote attackers to conduct phishing attacks via a // (slash slash) in a URL, which triggers a scheme-relative URL ...

CVE-2014-0481
Published: 2014-08-26
The default configuration for the file upload handling system in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 uses a sequential file name generation process when a file with a conflicting name is uploaded, which allows remote attackers to cause a d...

CVE-2014-0482
Published: 2014-08-26
The contrib.auth.middleware.RemoteUserMiddleware middleware in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3, when using the contrib.auth.backends.RemoteUserBackend backend, allows remote authenticated users to hijack web sessions via vectors relate...

CVE-2014-0483
Published: 2014-08-26
The administrative interface (contrib.admin) in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not check if a field represents a relationship between models, which allows remote authenticated users to obtain sensitive information via a to_field ...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.