[MUSIC] So to help improve the security of how we write apps lets talk a little bit about how Android protects our apps from other apps. And then once we understand how it protects our apps we can also understand what it doesn't do for us, and what it expects us as developers to do to ensure that our apps stay safe and secure. So the first thing that is Android does is whenever you go and launch an app, as we've seen before, that app has its own user account associated with it that determines what it can and can't do. But it also is launch in a tone process. So your app is launch in a tone process and what the process does is it's in operating system construct that protects the memory of you app while it's running from the memory of other applications. So your app will run in a process and if there's some malware that might be trying to attach your app, it'll be running in its own separate process. So we'll have another process and we'll have your original process. Now what this means is, if your apps memory is protected let's say that this is the iRemember app and we have a variable that for example maybe it's the server that we're going to save data to or try to log into. So maybe we have a server variable defined in one of our Java classes. Well, what the processed memory protections means is that the second process can't go and directly write to this variable. So this is not allowed. That would be a violation of the security that processes provide to separate the memory from each other. Now you can see why this is so important. If this malware can go directly change a variable in your code for instance if it can go and change some variable telling where the iRemember app should log in and tell it to go and log in into another server. For example, if you go and capture your username and password and do all kinds of other malicious things. So the memory protections that a process provides are very important. So we get memory protection on our apps from other apps running on Android at the same time. Another very important thing that Android provides is it provides a guarantee on the storage or the things that you're app will decides to persist to the storage on the device. So what we care about in this case, what we care about than can save state for our app, because our app may not always be running, and that when we go and relaunch that application we know that that state will still be intact in its original condition. So you can think about for example, if you were storing an important data about the state of your app to disk and another app could come in over write that state and change it, then you could do a lot of very malicious things from another app. So it's very important that Android protects whatever state or information we saved the underlined storage system. So what types of state can we safe that will get protected by Android? Well, the very first and important piece of state that we might save, for example is the APK for our app. So when we go and actually create an app, we're creating a package. It's going to be stored on the underlying file system on the device that has all of our code in it. So if another app could go in directly manipulate our APK, it could change the behavior of our app in whatever way it want it. So it's very important that we protect these APKs for apps when they're installed. And android does that for us. It provides protections over the APKs of each app. So your app can't go in and override or change another app's APK and those apps can't go and change your app's APK. What are other types of things that we might want to store and protect? Things like the database. So if your app wants to store data in the SQL like database on a device, you can store that database. And Android depending on how you store that data and we'll talk about this, will protect that data so that only your app, can read data in the database that you're writing. Other things that you might want to persist are settings for your app, and those could also be persisted. So how does Android go about and actually protecting these things under the hood? Well, the way that Android does it as we've seen before, is that each app has its own user account. And that essentially defines an area of the storage on the device that's assigned to that app. So if another app goes and tries to write to this area of storage, it can't, because that's owned by that other apps user account. So by default, Android gives us two really important things. It gives us the ability to protect our applications memory from other apps running so they can't change our variables or our run time state. And then also it gives us the ability to protect the data that we save to disc or to storage on our device. And that's protecting our state that's persisted between launches. So what Android is giving us is the ability to protect our app, both when it's running by protecting state that's in the process of that app. And then secondly, any state that we need to store because it is a mobile device and apps get shut down from time to time. The battery on the phone dies and we need to be able to save state it packs all of that state that we save on the underlying storage system in a special area that's assigned to our app. Now if all of our apps were wrapped up and protected with Android to where they could never interact and exchange data If they could never read each other's save to state ever, we have much less interest in applications on our devices. All most all of the really interesting Android applications involves some type of interaction between that app and another app or sort of services on a device or with the data that they're storing underneath their app. So for example the contacts app. The contacts apps that's on and drive by default stores it's data and persistent and Android protects saves state of your contacts. But at the same time we want to build to the get access to the contact list sometimes from other apps. So Android does provide mechanisms to allow apps to share data outside of the protected sandboxes that Android provides for them. So, apps can both share data outside of the processes that they're running in. So at runtime they can share data that they've loaded and is running outside to other apps. And Android apps can also, if they want to share data that they persisted on the file system to other apps. Now by default, Android tries to protect you, it tries to keep your app within its own little sandbox, with its own process protecting the memory of that app, protecting the data it's storing on the disk. But it gives you the option to build richer apps that do talk outside of their sandbox. But it's in these interactions where we begin talking to other apps and services on the device when we begin persisting data in ways that other apps can read and interact with, that we run the danger of writing an insecure app. So the two big areas that we have to be careful of are one, at run time when we begin interacting with and talking with other apps. And typically the way that you do this on Android is through, as you've seen, inter process communication or IPC. And IPC can take a number of forms, as we've seen. This can be the exchange of intents between applications and services. This can be binding and interacting with a service. And invoking a service that's running in another app or process. So something like getting access to the GPS, that's not going to be running in your app's process. So all of these interactions through IPC, whenever we decide to have those interactions we need to be cognizant that we're exposing our app to another app. We're opening up the sandbox that we live in by default and we're allowing our app to interact with the memory of other apps and to interact with the memory of our app. So whenever we begin doing interactions through intents, through services or through other mechanisms we're beginning to open up our app at run time and open up those memory protections. The other thing that we can do is we can save data to sort of communal areas on the disk, so we can do things like save data to the SD card. And in many cases, you want to save things to SD card. So for example, if you have a custom camera app that you're writing, you probably want to store those pictures on the SD card so that the user can remove the SD card, put a new one in to store more pictures. And also so that other applications like the photo gallery application can read those photos. So there are certain places like the SD card when we store data that we are opening our apps persisted state up to other apps. You can also store data with different permissions. So we can change the default permissions when we store data even though we're storing it in our apps own little private data storage area on the device. We can still open up that data and store it with things like read from any app and we change those permissions. So whenever we do those types of things where we store data in a way that other apps can get access to it. We have to be aware of the possibility of another app coming in either reading that information in order to corrupt it or to use that information to attack our app in some way, or to trick it in some way. The other area that Android can't protect us against is if we have a graphical user interface. So we have a GUI that is a part of our app. Now GUIs are great, we can use GUI to get information from the user that we need, like their username and password. But GUIs are also areas where other apps can try to attack our app because a GUI is a way of inputting data into our app. So although we have a process that's protecting the memory around our app, any type of GUI is an area where we're allowing data to be placed into our process. Either through fields like username and password that the user is going to provide data, or by going and adding buttons which when they're clicked, they turn into events that are injected into the memory of our application and give another app the chance to attack us. Now a GUI, another piece of malware probably can't directly manipulate your GUI, but what it can do is it can trick the user into manipulating your GUI into a state that it wants. So it can trick the user and make it think that it's doing something other than it is. So it manipulates the user to convince them that it's logging into your banking app, when in reality it's providing a fake GUI to do something else. So the GUI is another area that we have to protect. We either have to protect it from taking data that's going into our memory and corrupting them in some way, or getting knowledge of that data in some way such as username and password. Or protect it from taking a GUI that's supposed to be putting data into our process and our memory space which is protected and instead extracting that data and putting it into a piece of malware. So these are three really important areas that we have to understand what Android protects us against and what it doesn't protect us against and what we as developers have to do to make sure we write more secure apps. We want to protect our GUI, we want to make sure we protect the things that we store in terms of state on the disk. And we want to make sure that we protect our interactions with other apps through interprocess communications or other mechanisms.
