Security First: 5 tips for building a secure mobile app from the ground up


Security
Posted 10/5/2016 7:45:13 AM by KAREN SITTIG, Software Engineer at Facebook and MELITA MIHALJEVIC, Production Engineer at Facebook


Security First: 5 tips for building a secure mobile app from the ground up

With more than two billion smartphone users worldwide, the app market has exploded — along with risks. Mobile app developers are still struggling to make security a priority and by 2017, cyber-attacks via vulnerable apps are anticipated to account for 75% of all mobile security breaches.

Given what's at stake, it's critical that developers build apps that are “secure by default” to avoid introducing time-consuming, costly, and dangerous security vulnerabilities.The thousands of developers at Facebook understand this risk, and they've institutionalized security by adhering to several best practices before pushing code an average of three to four times per day. Following these protocols makes our developers' job easier and helps deliver key security benefits.

 
At our first-ever security session for global developers, held this September in San Francisco as part of Facebook's FbStart program, we shared the tools we use to build and grow products with security at their core. This included key practices and tips all developers can adopt to protect their code from common security vulnerabilities. The top 5 practices (and some tools) below are important for any organization - but even more critical if you’re an independent developer or work for a small team without dedicated security support.
 
 

1. Know Your Threats

While you can’t always guess how an adversary will attack your system, understanding the threat landscape and the ways your code may be attacked is the first and most important step to protecting it. At the outset, think about who might want to access your production systems and data, and plan out strategies to mitigate those predicted threats.

The Open Web Application Security Project (OWASP) offers an excellent write-up of a traditional threat modeling process in 3 high-level steps:

- Decompose the application to understand how it is used and how it interacts with external entities.

- Determine and rank threats from the attack and defense perspective. You can classify the security risk for each threat using a value-based risk assessment model such as DREAD (Damage Potential, Reproducibility, Exploitability, Affected Users, and Discoverability) or general risk factors such as likelihood and impact.

- Determine countermeasures and mitigation to protect against threats. Using the risk ranking you assigned, sort threats from the highest to the lowest risk, and prioritize your mitigation efforts.

2. Protect APIs from Exposure and Manipulation

Exposed APIs are like unlocked doorways to your home, allowing intruders unauthorized access to your code — and remote access to manipulate your data.

Here are some ways to protect your APIs from exposure and manipulation:

- Remove old deprecated function calls from your APIs.

- Don’t embed API keys, passwords, etc., directly into code — always keep these separate. Store this information in a separate configuration file. If a configuration file is part of a project in an IDE, remove sensitive data before distributing or sharing.

- Store sensitive data in a secure system with strong encryption. The system should also utilize immutable audit logging (IAL).

If your app integrates with Facebook, we also provide an App Security Checkup tool, which helps detect potential security vulnerabilities in your apps and helps you address them. If your app integrates with APIs from other providers, be sure to take advantage of any security tools, notifications, and other security-related initiatives they may offer to help developers secure their apps.

3. Use Updated Libraries

Libraries are usually the largest attack surface for your app, and the risks increase exponentially as you add more code. Whether you’re using open source, proprietary code, or a combination of both, make sure you’re only using the latest version with all available changes and improvements.

If you want to use open source libraries, here are a few that Facebook manages:

- React - a declarative, efficient, and flexible JavaScript library for building user interfaces.

- Pop - an extensible iOS and OS X animation library, useful for physics-based interactions.

- Rebound - a Java library that models spring dynamics and adds real world physics to your app.

4. Sanitize User Input

Be careful when using high-level language features (like ’exec’ in PHP). Misuse of these features can cause shell injections and enable an attacker to compromise your system. Failure to properly sanitize user input is one of the leading causes of Web vulnerabilities on the internet.

To protect against these vulnerabilities:

- Avoid using input directly from users as much as possible - always sanitize it first.

- Don’t use primitive string operations to produce structured output, whether it’s a shell command, database query, some HTML, or JavaScript. Instead, choose a framework that enables you to express the higher-level thing you’re trying to build.

At Facebook, we built and open sourced XHP, a PHP extension which augments the syntax of the language to both make your front-end code easier to understand and help you avoid cross site scripting attacks. For React.js and React Native, we developed JSX, an inline XML syntax for JavaScript code.

5. Protect Your Code from SQL Injection

SQL injection is not just one of the most commonly exploited web vulnerabilities - it can also destroy your database.

You can help protect your code from SQL injection with the following methods:

- Adopt an input validation technique to authenticate user input against a set of defined rules for length, type, and syntax, in addition to validating against business rules.

- Individuals with permission to access the database should also have the fewest privileges. Do not use system administrator accounts like “sa” for Web applications. Access to a database should be limited to a specific application and should not allow access to other applications.

- Use strongly typed parameterized query APIs with placeholder substitution markers, even when calling stored procedures.

- Be careful when using stored procedures as they can be injectable through the use of exec() or concatenating arguments within the stored procedure.

 


READ MORE: https://developers.facebook.com/tools/app-security...




Subscribe to App Developer Daily

Latest headlines delivered to you daily.