Basic app hygiene

- [Instructor] There are some basic hygiene rules for writing Android apps, ways of coding which don't introduce unnecessary weaknesses. Let's run through them. Many security hygiene rules are automatically applied by Android Studio. If we select file, settings, editor, inspections, we can see a whole set of Android Lint inspection settings. One of them is security. Let's open it.

This list contains many features which Android Studio considers to be insecure. Under the right the tick means a check will be applied during coding to provide either a warning, orange, or an arrow, red. If it flags an arrow, you'll need to correct your code or override the Lint inspection setting. There's an online explanation of these Lint checks available for you to peruse. For instance, let's go down to the check hard-coded debug mode. And we can see there's a full explanation as to why this is inspected.

I won't go through these in detail as you will be prompted by Android Studio to understand and address these issues as in when you encounter them. You'll likely want to debug your app during testing. This is allowed when creating a debug variant, or if you've hard-coded Android debuggable to true in the manifest file. When you do this, it's possible to use the ADB renounced command to debug in the context of the app and therefor see into its sandbox. You should always remove any hard-coded instructions to debug and deploy in release builds.

I note that some Android versions have a bug which disables their run-as command, and while this actually enhances security, you shouldn't depend on it. Only those activities and services which need to be exported should be flagged as such. The default is not to export, but if they've been exported for diagnostics during testing, then you may need to reset them. You should minimize the privileges you request to avoid any malicious activity that gets into your app misusing these privileges. Apps need to communicate with other apps and within other components within their own app.

There's a few ways of doing interprocess communications such as Linux Sockets. But the recommended way is to use intents. These are well controlled by Android, and as long as they're not exported don't add to the attack surface. When using intents, as much as possible use explicit rather than implicit intents so that you have confidence that the process which actions your intent isn't malicious. Permissions are another key Android feature for enabling security. When using exported services, you may wish to consider applying custom permissions which can be checked by the service when an external process makes a service request.

This helps restrict unauthorized use of the service. When using broadcast receivers, consider adding permissions to make sure only those process you want to receive the broadcast are able to to avoid inadvertent data leakage. Content providers can be used to share information between your own apps, or with third parties. If the data is shared only with your apps, then use a protection-level signature. You can also use the grantUriPermissions to gain more granular access control.

Print out the users content provided data may be subjected to an SQL injection attack. This can be avoided by parsing and validating user input. It can also be prevented more simply by using parametrized queries. This means that traditional SQL injection attacks such as including as a name, nobody, or one equals one, won't work, because this doesn't affect the query structure just the value of the name. Web view provides a very useful capability for developers, but because it reads HTML and Javascript, it may be subject to cross-sides scripting attacks.

Android has a number of approaches to help minimize the risk. If the application doesn't use Javascript within a web view, then avoid calling setJavaScriptEnabled. Only use the addJavaScriptInterface for Javascript within your own application, or for websites that are known to be trustworthy. This call enables operations that can be used maliciously. Obviously credentials are a key security risk when hard-coded within an application or stored in a file on a device. It's preferable to use either an account manager with centralized credentials, or use a keystore for local protective storing.

Code that's loaded from outside your app may introduce a risk of malicious code being loaded through compromising or spoofing your library code source. Avoid dynamically loading code from outside your app wherever possible. You may want to make an object serializable for ease of use, but this as a result exposes details about the class which are normally private. Avoid making objects serializable where possible. Declare constants, methods, and classes as final where possible. A constant declared as final will never have its value changed, and final methods and classes cannot be overwritten.

That's some of the key developer tips for security. We'll look in more detail at some of the additional capabilities that we can use when we code up our app.