Securely developing on mobile

More than ever, people are using their mobile device as their primary means of accessing the Internet. this provides not only unparalleled access to information, but also millions upon millions of applications built by third party developers. this Platform
Approach enables users to experience great apps built by developers both large and small. however, this decentralized platform approach only works if there are strong, industry-wide best practices around und important app basics such as security. for this reason,
We applaud the Federal Trade Commission for hosting its public forum on threats to mobile devices and thank them for including Facebook in this important meeting.

For everyone who couldn't make the forum yesterday, we have used ented some of the best practices for developing on Android and iOS, and we're excited to share them with other developers.

From the outset, it is important to note that making apps that are secure on Android and iOS is hard. when your application behaves in manner that is unintended, it creates security and privacy implications for the end user, and this might not be restricted
To the confines of your app, but potentially keep ss the device.

Top risks include malware installed on the phone alongside your app, tools that allow malicous actors to snoop on device activity, and even malicious websites that can trigger actions in your app using custom URL schemes.

The only way to ensure that your application is secure is to engineer your application for security from the ground up.

Here are some recommendations to reduce vulnerabilities in your application:

1. Use https in a secure way

HTTPS can help you protect the privacy of user data against a man-in-the-middle attack, which cocould manifest as snooping on data and stealing user sessions on the network.

However, to obtain this protection your app needs to perform several steps to verify the server to which it is ing, and this process is very error-prone. even a small mistake in verification can result in no protection at all. read more here-http://crypto.stanford.edu /~ Dabo/pubs/ABSTRACTS/ssl-client-bugs.html

Android

Instead of using the sslsocketfactory classes, you shocould use APIs like httpsurlconnection, which are simpler to use and perform the correct verification steps on your behalf. httpsurlconnection also adds features (including TLS tickets and SNI headers,
Which only work correctly after jellybean) to the HTTPS connection that gives you better performance than using raw SSL sockets. It shoshould always be better to use this API.

IOS

Similarly, on iOS it is preferable to always use the high level API nsurlconnection for network requests. Lower Level APIs such as cfstream need explicit and often error-prone configuration of SSL.

Android and IOS

To debug network requests with a proxy, such as Charles, you may prefer manually installing a SSL Certificate in your testing device rather than using Preprocessor variables and debug-only code to deactivate SSL validation. see more-http://www.charlesproxy.com/documentation/faqs/ssl-connections-from-within-iphone-applications/

2. There are no client secrets

Often, developers will spend time trying to obfuscate secrets in the application, which will be used to either authenticate their app to their server or to perform a client-side oauth flow.

Trying to obfuscate a secret in Android and iOS clients is a futile effort as the secrets can always be recovered using the abundance of reverse-engineering and debugging tools available for apks (https://code.google.com/p/android-apktool ),
Java (http://en.wikipedia.org/wiki/JAD_ (java_decompiler )),
And Objective C (http://www.fscript.org /).

A. authenticating an app to your server

Often the goal of authenticating the app to the server is to prevent users from getting phished. A good solution to phishing is to support a two-factor authentication for your application. facebook login approvals (https://www.facebook.com/note.php? Note_id = 10150172618258920)
Is an example of a large scale two-factor authentication solution that millions of people use daily.

B. oauth

Do not expose your oauth secrets to the world via your client application. store the oauth secrets on your server so that they are indeed secret. to obtain an oauth token, the client wocould then request an end-point on your server that cocould proxy the token
Request to the oauth provider with the secret, And then, return the token to the client. Once the client obtains the oauth token, it can directly make requests to the oauth provider.

3. webviews

Android

Some applications use Android webviews and store cookies in the webviews to access the remote servers.

You shoshould restrict the web-pages that can load inside your webview with a whitelist. If you are only going to open pages from your domain in the webview you shoshould restrict those.

This will prevent others from triggering the loading of local resources such as javascript: // URLs and file: // URLs, which can be used to XSS users on Android. (read more here-(http://www.80vul.com/android/android-0days.txt)

IOS

In the simple case, a uiwebview is just a web browser tab sharing its cookie storage with the app. however, more complex interactions are often needed between the embedded Javascript and the app. this is usually done by having the app catch and interpret
URLs of a special scheme in the outgoing requests of the webview.

These interactions must be carefully reviewed. In particle,

A. If the webview is meant to browse the Web, it shocould not be given large privileges over the native app;

B. if they include user-controlled strings (this typically includes des the initial URL and any string injected in the Javascript environment using stringbyevaluatingjavascriptfromstring) Make sure to sanitize the native inputs of webviews

4. Tap-jacking

Android

Other applications can overlay content over your application, and fool users into Clicking buttons on your app underneath.

To prevent this consider setting the setfiltertoucheswhenobscured (http://developer.android.com/reference/android/view/View.html#setFilterTouchesWhenObscured)
Property to true in your views. This will prevent your application from getting touches when another application is obscuring it.

IOS

Proofs of concept exist on IOS as well (http://www-personal.umich.edu /~ Yangqi/pivot/mobile_phishing_defense)
Although this issue shoshould concern only jailbroken devices.

5. race conditions oninstalling apps

Permission stealing [Android]

Other apps that are installed before your app, cocould steal Android permissions (including signature level permissions) that you have declared in your manifest by declaring them before you.

Your app will function normally, but as a result of this, malware that steals permissions cocould snoop into all of your app's content providers and other components.

To prevent this, reduce both the exposure of components and also explicitly authenticate the callers of your components.

Stealing of URL schemes [IOS]

Failed t for a core subset managed by IOs, URL schemes are registered on first-come, first-served basis.

6. Controlling exposed features

Activities, services and broadcast receivers [Android]

You shoshould aim to expose as little of your application as possible to other applications that are potentially malicious. not setting intent-filters on components, or explicitly setting "exported = false," will cause components to be local to your application.
This is the most alternative tive way of protecting components.

Make sure that before any action that changes the state of your app is taken, the user performs a UI action Like clicking a button (this is analogous to csrf protection in Web applications ). it is dangerous to perform a write action based on an intent extra
Passed into a component.

Exposed URL schemes [IOS]

Similarly, IOS apps shocould not perform State-changing actions on processing URLs without asking for confirmation from the user.

7. Watch out for internal URL schemes.

In addition to exposed URL schemes, it is common to define custom URL schemes internally to an iOS or Android app so as to let trusted sources trigger specific actions.

Android

When using custom URL schemes in intent filters, be cognizant of the fact that they can be triggered by not only apps installed on the device, but also malicous websites that the user opens in the browser by simply clicking on a link. this triggers an action_view
Intent for the URL that was clicked, so that the user does not need to install malware for the malware to exploit a particle component if it has another vulnerability.

IOS

Make sure to distinguish internal URLs created by trusted sources from public URLs callable by external apps or made clickable in user contents. The library class does not restrict the schemes of URLs detected in user contents.

8. authenticating callers of components

 

Android

A. Activities

Consider calling activities that need to know their caller using startactivityforresult (). the calleeactivity can then enforce the identity of the caller using getcallingpackage () and ensures that is non-null and the package that it expects. A signature check
Using packagemanager is the most valid tive way of ensuring the caller is from the same app family as the callee.

B. Content Providers

The User ID of the caller can be obtained using binder. getcallinguid (), and can be used for permission enforcement via signature checks.

C. broadcast receivers

There is no current way to get the identity of the initiator of the broadcast. for System Broadcasts, ensure that you check the action string of the incoming intent to make sure an intent is coming from the system.

D. Services

Services can enforce the callerusing binder. getcallinguid () and using signature checks. however services using the messaging IPC mechanic cannot get the caller uid in the handlemessage () callback. consider using aidl-based service CILS for exposed services.

IOS

Rather than attributes: Application: handleopenurl:, you may want to implement uiapplicationdelegate: Application: Openurl: sourceapplication: annotation: and use the sourceapplication to authenticate a URL caller over time. To mitigate Spoofing
Callers 'url schemes, the Facebook SDK also lets callers to the main app choose an encryption key for their response.

9. Use explicit intents andintent hijacking [Android]

If private data is being transmitted in an intent, use explicit intents. Explicit intents ensure that the callee determines ing the intent will be the one that the caller intended to receive the intent.

Android provides ways to call components using implicit intents, however, keep in mind implicit intents cocould allow a malicious application to hijack the intent.

If using implicit intents, you shocould dynamically resolve the receivers of the intent and perform signature checks before sending the intent. "setpackage" is also an option, which restricts the package that can receive an intent. however, this works only
After ice cream sandwich.

10. Open redirects

You cocould protect all your components with permissions and checks, however if there exists even one component in your application that takes a component as an input and redirects to that component, this cocould be used to circumvent all checks. avoid this
Practice at all costs.

11. SQL Injection

Android

Sqllitequerybuilder is a standard way of building SQL queries for Android. however even though it seems to be safe against SQL injection attacks, underneath the hood Its Imply concatenates strings. this allows attackers to insert arbitrary clses into
SQL statement.

You must carefully sanitize user input strings to content providers that are exposed.

IOS

You shoshould refrain from constructing SQL query strings directly and instead use a more abstract framework such as egodatabase or fmdb.

12. language-based vulnerabilities [IOS]

Objective C is susceptible to a variety of programming errors that can be exploited:

* C fragments are vulnerable to the classical C vulnerabilities such as buffer overflows.

* Zombie objects may be exploited.

* User-dependent inputs occurring in format strings, selectors, or regular expressions may be exploited.

* It is important to keep in mind that static types appearing in the Code are not enforced at runtime.

* Returning nil values on failures and unimplemented selectors is often OK. yet, unexpected nil values can cause a crash with some library functions, and can yield unpredictable results in general (for instance [nil isequaltostring: Nil] = 0 ).