├── LICENSE ├── RemoteCrashAndroid.md ├── WebviewVuln.md └── andsec.md /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2015 Avinash 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | 23 | -------------------------------------------------------------------------------- /RemoteCrashAndroid.md: -------------------------------------------------------------------------------- 1 | 2 | ## 0x00 Background Knowledge 3 | 4 | Each Android Application is made up of Activity, Service, Content Provider and Broadcast Receiver, which are the basic components of Android. Among those components, An Activity is the main body of an application and performs most of the display and interaction work. Even to some extent, an “interface” is an Activity. 5 | 6 | An activity is a visual user interface on which users can perform some actions. For instance, an Activity can display a menu list for user to choose and some pictures that contain descriptions. A SMS application can include an Activity to display the contacts list as the recipient, an Activity to write messages to the chosen recipient, and an Activity to view recent messages or change settings. Altogether, they compose a cohesive user interface. But each Activity is independent. And each is an implementation of subclass based on Activity parent class. 7 | 8 | An application can have one or more Activities, such as the SMS application that we mentioned. Of course, the function and the number of each Activity is naturally determined by the application and its design. Normally, there is always an application marked as the first application that the user would see when starting. If an Activity needs to shift to another, the current Activity will launch the next one. 9 | 10 | **Intent Selector** 11 | There is a circumstance that more than one Activity may contain a same action. When such an action is called, a selector will pop up for user to pick. 12 | 13 | **Permissions** 14 | android:exported 15 | 16 | This property determines whether an Activity component can be launched by external applications. When it's set to true, Activity can be started by an external application. However, when it's set to false, Activity can only be launched by its own app. (same user ID or root can launch) 17 | 18 | Exported is set to false by default, if the action property of intent-filter is not configured ( without filter, you have to start the activity by explicit class names, which means the program can only be launched by itself), otherwise, exported is set to true by default. 19 | 20 | Exported property is used to limit the Activity not to expose to other apps. Setting the permission statements in configuration files can also limit external apps from starting an Activity. 21 | 22 | android:protectionLevel 23 | 24 | http://developer.android.com/intl/zh-cn/guide/topics/manifest/permission-element.html 25 | 26 | **Normal**: default value. This is a lower risk permission. The system grants this type of permission to a requesting application at install without asking for user's approval. 27 | 28 | **Dangerous**: like WRITE_SETTING and SEND_SMS, these permissions are risky, because these permissions can be used to reconfigure the device, or lead charges. This protection Level is used to identify some permissions that the user concerns. Android would display related permissions to the user at install. The specific actions vary from Android versions and devices. 29 | 30 | **Signature**: these permissions are only granted to the requesting applications signed with the same certificate as the application that declared the permission 31 | 32 | **SignatureOrSystem**: similar to signature class, except for the fact that applications in Android image also require permission. In this case, applications that vendors build in system can still be granted with permission. This protection level is helpful to integrate system compiling process. 33 | 34 | 35 | ## Security recommendations 36 | 37 | 38 | - Private Activity used in apps should not configure intent-filter. If intent-filter is configured, exported property needs to be false. 39 | - Use the default taskAffinity 40 | - Use the default launchMode 41 | - Don't set FLAG_ACTIVITY_NEW_TASK when starting an activity 42 | - Handle the received intent and its information carefully 43 | - Verify the signature of internal (in-house) app 44 | - When the Activity returns data , you should pay attention to whether the target Activity would disclose information risks. 45 | - The target Activity uses explicit start when it's clear. 46 | - Handle the returned data carefully. The target activity may return data forged by malware. 47 | - Verify if the target Activity is a malicious app, in case of intent cheat. You can use signature hash to verify. 48 | - When Providing an Asset Secondhand, the Asset should be Protected with the Same Level of Protection 49 | - Do not send sensitive information. The intent information of public activity can be read by malware. 50 | 51 | ## Test Method 52 | 53 | **Viewing the activity:** 54 | 55 | - Decompile,and view the activity component in AndroidManifest.xml (pay attention to configured intent-filter and exported is not set to false. 56 | - Use RE to open the app after install to view the configuration file directly. 57 | - Use Drozer scan to: run app.activity.info -a packagename 58 | - Dynamic view: logcat sets the tag of filter to ActivityManager 59 | 60 | **launching the activity:** 61 | - adb shell：am start -a action -n package/componet 62 | - drozer: run app.activity.start --action android.action.intent.VIEW ... 63 | - Write your own app to call startActiviy () or startActivityForResult () 64 | 65 | ## Reference : 66 | 67 | http://www.jssec.org/dl/android_securecoding_en.pdf 68 | -------------------------------------------------------------------------------- /WebviewVuln.md: -------------------------------------------------------------------------------- 1 | ### Vulnerability Description 2 | 3 | A lot of the time we use WebView to display a Webpage,for example many applications in order to achieve the server control, many results page is Webpage, rather than the local implementation, which has many advantages, such as interface change does not need to release a new version, directly modify the line at Server end. With Webpage to display interface, usually are more or less with the Java code have interaction, such as a button click Webpage above, we need to know the button click event, or we have to call a method, make the page to perform some action, in order to achieve these interactions, we usually use JS to achieve, while WebView has provided such a method, the specific usage is as follows: 4 | 5 | 6 | mWebView.getSettings().setJavaScriptEnabled(true); 7 | mWebView.addJavascriptInterface(new JSInterface(), "jsInterface"); 8 | 9 | We asked WebView to register a name "jsInterface" of the object, and then can access to the jsInterface object in JS, you can invoke some methods of the object, the final call to Java code, so as to realize the interaction of JS and Java code. 10 | We work together to have a look on the **addJavascriptInterface** method on the Android website description: 11 | 12 | _This method can be used to allow JavaScript to control the host application. This is a powerful feature, but also presents a security risk for applications targeted to API level JELLYBEAN or below, because JavaScript could use reflection to access an injected object's public fields. Use of this method in a WebView containing untrusted content could allow an attacker to manipulate the host application in unintended ways, executing Java code with the permissions of the host application. Use extreme care when using this method in a WebView which could contain untrusted content._ 13 | 14 | JavaScript interacts with Java object on a private, background thread of this WebView. Care is therefore required to maintain thread safety. 15 | The Java object's fields are not accessible. 16 | 17 | 18 | Simply put, is to use addJavascriptInterface may lead to insecurity, because JS may contain malicious code. This loophole and today we want to say is this, when JS contains malicious code, it can do anything. 19 | 20 | -------- 21 | 22 | 23 | ### Vulnerablity Impact: 24 | Through the JavaScript, anything can access the device on the SD card, and even contact information, SMS etc.. It's disgusting, quack. 25 | 26 | 1. WebView adds a JavaScript object, and the current application with SDCard read and write permissions, or: android.permission.WRITE_EXTERNAL_STORAGE 27 | 28 | 2. Through the window object can be found in JS, the object "getClass" method, and then through the reflection mechanism, get the Runtime object, then call the static method to run some commands, such as access to the file command. 29 | 30 | 3. The string returned from the execution command input stream, you can get the information of the file name. Then do what you want to do, good risk. The core JS code as follows: 31 | 32 | 33 | function execute(cmdArgs) 34 | { 35 | for (var obj in window) { 36 | if ("getClass" in window[obj]) { 37 | alert(obj); 38 | return window[obj].getClass().forName("java.lang.Runtime") 39 | .getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs); 40 | } 41 | } 42 | } 43 | 44 | ------ 45 | 46 | ### Exploitation 47 | 48 | In order to prove this loophole, I'm just loading a malicious JS code of the local Webpage, HTML the code as follows: 49 | 50 | 51 | 52 | 53 | 54 | 86 | 87 | 106 | 107 | 108 | 109 |

Click on the image to the URL to Java code

110 | 116 |

117 | 118 | 119 | 120 | 121 | 1. Please seeexecute()The method, which the traversal of all window object, an object with a getClass method and then find, use this object class, find the java.lang.Runtime object, then call the "getRuntime" static method to get an instance of Runtime, and then call exec () method to execute a command. 122 | 2. getContents()Methods, read from the stream, displayed in the interface. 123 | 3. Key code is in the following sentences 124 | 125 | `return window[obj].getClass().forName("java.lang.Runtime").getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);` 126 | 127 | Java code is as follows: 128 | 129 | mWebView = (WebView) findViewById(R.id.webview); 130 | mWebView.getSettings().setJavaScriptEnabled(true); 131 | mWebView.addJavascriptInterface(new JSInterface(), "jsInterface"); 132 | mWebView.loadUrl("file:///android_asset/html/test.html"); 133 | 134 | Need to add permissions: 135 | 136 | 137 | 138 | 139 | 140 | ------ 141 | 142 | ### Mitigation 143 | - System Android 4.2 or above 144 | In Android 4.2 or above, Google was modified, the statement on the Java remote method of a @JavascriptInterface, as in the following code: 145 | 146 | 147 | class JsObject { 148 | @JavascriptInterface 149 | public String toString() { return "injectedObject"; } 150 | } 151 | webView.addJavascriptInterface(new JsObject(), "injectedObject"); 152 | webView.loadData("", "text/html", null); 153 | webView.loadUrl("javascript:alert(injectedObject.toString())"); 154 | 155 | - System Android 4.2 below 156 | 157 | This problem is difficult to solve, but also can not solve. 158 | First of all, we must not call the addJavascriptInterface method. On this issue, the core is to know the JS event this one action, JS interacts with Java we know, there are several, than the prompt, alert, such action would correspond toWebChromeClientMethod, the corresponding class for prompt, which corresponds to theonJsPromptMethod, this method statement as follows: 159 | 160 | 161 | public boolean onJsPrompt(WebView view, String url, String message, 162 | String defaultValue, JsPromptResult result) 163 | 164 | By this method, JS can make information (text) transfer to Java, and Java also can get information (text) is transmitted to the JS. 165 | -------------------------------------------------------------------------------- /andsec.md: -------------------------------------------------------------------------------- 1 | # *Effective Android Security* 2 | 3 | `Tips Stolen from various resources` 4 | 5 | ### Android Platform 6 | 7 | Android is open source and designed with a flexible multilayer. Android seeks to be a secure platform for the users, thus Android seeks to 8 | 9 | * Protect user data 10 | * Protect system resources (including the network) 11 | * Provide application isolation 12 | 13 | To accomplish a secure application, Android provides: 14 | 15 | * Robust security at the OS level through the Linux kernel 16 | * Mandatory application sandbox for all applications 17 | * Secure interprocess communication 18 | * Application signing 19 | * Permissions 20 | 21 | * * * 22 | 23 | Read list 24 | 25 | * [https://source.android.com/devices/tech/security/overview/index.html#android-platform-security-architecture](https://source.android.com/devices/tech/security/overview/index.html#android-platform-security-architecture) 26 | 27 | ### Linux Security 28 | 29 | Android is built on linux kernel and it's been around for a long time, because of that linux kernel has been maintained and fixed and made stable. Linux kernel provides several key security features: 30 | 31 | * A user-based permissions model 32 | * Process isolation 33 | * Extensible mechanism for secure IPC 34 | * The ability to remove unnecessary and potentially insecure parts of the kernel 35 | 36 | Linux is a multiuser operating system and linux kernel isolate user resources from another one another for the security reasons. Linux aim to protect user data, thus linux: 37 | 38 | * Prevents user A from reading user B's files 39 | * Ensures that user A does not exhaust user B's memory 40 | * Ensures that user A does not exhaust user B's CPU resources 41 | * Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS, bluetooth) 42 | 43 | * * * 44 | 45 | Read list 46 | 47 | * [https://source.android.com/devices/tech/security/overview/kernel-security.html#linux-security](https://source.android.com/devices/tech/security/overview/kernel-security.html#linux-security) 48 | 49 | ### The Application Sandbox 50 | 51 | The android platform uses the linux user-based protection model to isolate one application from the another. In linux, multiple applications can run with the same user permission. But android assigns a unique user id (UID) to each application and run it in a separate process. Each application is like a user 52 | 53 | This sets up a kernel-level Application Sandbox. The kernel enforces security between the applications and system at the process level by using linux features. By default, applications cannot interact with eachother and they have limited access to system resources. 54 | 55 | The application sandbox is in kernel, thus it extends to native code and operating system applications as well. All runs within the application sandbox 56 | 57 | 58 | * * * 59 | 60 | * A user-based permissions model 61 | * Process isolation 62 | * Extensible mechanism for secure IPC 63 | * The ability to remove unnecessary and potentially insecure parts of the kernel 64 | 65 | Linux is a multiuser operating system and linux kernel isolate user resources from another one another for the security reasons. Linux aim to protect user data, thus linux: 66 | 67 | * Prevents user A from reading user B's files 68 | * Ensures that user A does not exhaust user B's memory 69 | * Ensures that user A does not exhaust user B's CPU resources 70 | * Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS, bluetooth) 71 | 72 | * * * 73 | 74 | Read list 75 | 76 | * [https://source.android.com/devices/tech/security/overview/kernel-security.html#linux-security](https://source.android.com/devices/tech/security/overview/kernel-security.html#linux-security) 77 | 78 | ### Personal Information 79 | 80 | Access to sensitive user data is available only through protected APIs 81 | 82 | 83 | * * * 84 | 85 | Read list 86 | 87 | * [https://source.android.com/devices/tech/security/overview/app-security.html#personal-information](https://source.android.com/devices/tech/security/overview/app-security.html#personal-information) 88 | 89 | ### SIM Card Access 90 | 91 | Low level access to the SIM card is not available to third-party apps. The OS Handles all communication with the SIM Card. 92 | 93 | Read list 94 | 95 | * [https://source.android.com/devices/tech/security/overview/app-security.html#sim-card-access](https://source.android.com/devices/tech/security/overview/app-security.html#sim-card-access) 96 | 97 | ### Cost Sensitive APIs 98 | 99 | Cost sensitive means using them might generate cost, thus android provides a protection in OS level. Applications must grant explicit permission to use these APIs. 100 | 101 | * Telephony 102 | * SMS/MMS 103 | * Network/Data 104 | * In-App Billing 105 | * NFC Access 106 | 107 | * * * 108 | 109 | Tips: 110 | 111 | * With Android 4.2, the user gets a notification when the SMS feature is used, then user decides to whether send the message or not. 112 | 113 | Read list 114 | 115 | * [https://source.android.com/devices/tech/security/overview/app-security.html#cost-sensitive-apis](https://source.android.com/devices/tech/security/overview/app-security.html#cost-sensitive-apis) 116 | 117 | ### Sensitive Data Input Devices 118 | 119 | Applications must grant an explicit permission to use input devices such as: 120 | 121 | * GPS 122 | * Camera 123 | * Microphone 124 | 125 | * * * 126 | 127 | Read list 128 | 129 | * [https://source.android.com/devices/tech/security/overview/app-security.html#sensitive-data-input-devices](https://source.android.com/devices/tech/security/overview/app-security.html#sensitive-data-input-devices) 130 | 131 | ### Device Metadata 132 | 133 | Device information might contains user information, thus applications must grant to access : 134 | 135 | * Operating system logs 136 | * Browser history 137 | * Phone number 138 | * Hardware / network identification information 139 | 140 | * * * 141 | 142 | Read list 143 | 144 | * [https://source.android.com/devices/tech/security/overview/app-security.html#sensitive-data-input-devices](https://source.android.com/devices/tech/security/overview/app-security.html#sensitive-data-input-devices) 145 | 146 | ### * Application Signing 147 | 148 | * Signing allows developers to identify the author of the application. 149 | * Every application must be signed, otherwise it will be rejected 150 | * Application signing is the first step for the application sandbox. 151 | * Application signing ensures that one application cannot access any other application except through well-defined IPC 152 | * Do not sign the application with a publicly known key 153 | * Do not sign with the platform key 154 | * Applications with the same package name should not be signed with the different keys 155 | 156 | * * * 157 | 158 | Tips: 159 | 160 | * Never ever forget your keystore. Send it via email to yourself to keep it. If you lose your keystore, you won't be able to get it back and you cannot update your application anymore. 161 | 162 | Read list 163 | 164 | * [https://source.android.com/devices/tech/security/overview/app-security.html#application-signing](https://source.android.com/devices/tech/security/overview/app-security.html#application-signing) 165 | 166 | ### Storing Data - Internal Storage 167 | 168 | * By default, files that you create on internal storage are accessible only to your app 169 | * Avoid MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE 170 | * Use content provider for share 171 | * Consider Encryption for additional protection 172 | 173 | * * * 174 | 175 | Read list 176 | 177 | * [http://developer.android.com/training/articles/security-tips.html#StoringData](http://developer.android.com/training/articles/security-tips.html#StoringData) 178 | 179 | ### Storing Data - External Storage 180 | 181 | * Globally readable and writeable 182 | * Always perform input validation 183 | * Do not store executables or class files 184 | * Always retrieve signed and verified files. 185 | 186 | * * * 187 | 188 | Read list 189 | 190 | * [http://developer.android.com/training/articles/security-tips.html#StoringData](http://developer.android.com/training/articles/security-tips.html#StoringData) 191 | 192 | ### * Storing Data - Content Providers 193 | 194 | A structured storage mechanism. You must register it within manifest file. 195 | 196 | 197 | 198 | * * * 199 | 200 | * You can set export option to provide data to other applications or not. (android:export in manifest file). The default value is "true" for applications that set either android:minSdkVersion or android:targetSdkVersion to "16" or lower. For applications that set either of these attributes to "17" or higher, the default is "false". 201 | * Use signature protection level to limit with your own apps.Signature protection: Only the applications which are signed by the same key can access 202 | * Use parameterized query methods such as query(), update(), delete to avoid SQL injection 203 | * Do not use content provider if you will use only in your app. 204 | 205 | * * * 206 | 207 | Tips: 208 | 209 | * Always set export atribute. 210 | 211 | * * * 212 | 213 | Read list 214 | 215 | * [http://developer.android.com/training/articles/security-tips.html#StoringData](http://developer.android.com/training/articles/security-tips.html#StoringData) 216 | 217 | ### Shared Preferences 218 | 219 | * Shared preference is an xml file which stored in the application directory. (/data/data) 220 | * They can be read easily with the root priviliges. Because of that, do not store any sensitive information in there. 221 | * Without root priviliges, no other application can access that area. It is protected by the application sandbox. 222 | * Use crypto if you need to store an information which might be sensitive such as bank account number etc. 223 | * Data is stored as key/value pair. Make your keys to hard to understandable such as random characters. Such as KEY_NAME = "asdfadsf" 224 | 225 | * * * 226 | 227 | Read list 228 | 229 | * [http://stackoverflow.com/questions/9244318/android-sharedpreference-security](http://stackoverflow.com/questions/9244318/android-sharedpreference-security) 230 | 231 | ### Android Resources/Assets 232 | 233 | * Do not store any sensitive information in the resources/assets such as keystore key etc. They can be read and accessed easily. 234 | 235 | * * * 236 | 237 | Read list 238 | 239 | * [http://stackoverflow.com/questions/3406581/security-of-android-assets-folder](http://stackoverflow.com/questions/3406581/security-of-android-assets-folder) 240 | 241 | ### Using Permissions 242 | 243 | * Minimize the permission request. 244 | * Do not request unless you really really need it 245 | * Do not leak permission-protected data. 246 | * Use permissions to protect IPC. This occurs when your app exposes data over IPC that is only available because it has a specific permission 247 | 248 | * * * 249 | 250 | Read list 251 | 252 | * [http://developer.android.com/training/articles/security-tips.html#Permissions](http://developer.android.com/training/articles/security-tips.html#Permissions) 253 | 254 | ### Using IP Networking 255 | 256 | * Use of HTTPS over HTTP anywhere that HTTPS is supported on the server. 257 | * Do not trust data downloaded from HTTP or other insecure protocols. 258 | * To interact to another application always use android interprocess mechanisms 259 | 260 | * * * 261 | 262 | Read list 263 | 264 | * [http://developer.android.com/training/articles/security-tips.html#Networking](http://developer.android.com/training/articles/security-tips.html#Networking) 265 | 266 | ### Using Telephony Networking 267 | 268 | * SMS is neither encrpyted not strongly authenticated. 269 | * SMS messages are transmitted as broadcast intents, so they may be read or captured by other applications that have the READ_SMS permission. 270 | * Consider using GCM or IP Networking for data transfer 271 | 272 | * * * 273 | 274 | Read list 275 | 276 | * [http://developer.android.com/training/articles/security-tips.html#Networking](http://developer.android.com/training/articles/security-tips.html#Networking) 277 | 278 | ### Performing Input Validation 279 | 280 | Insufficient input validation is one of the most common security problems affecting applications, regardless of what platform they run on. 281 | 282 | * Beware of script injection such as javascript and SQL 283 | * Use parameterized queries to avoid injections 284 | * Always verify the format 285 | * Beware of potential secure issues when using native code. 286 | 287 | * * * 288 | 289 | Read list 290 | 291 | * [http://developer.android.com/training/articles/security-tips.html#InputValidation](http://developer.android.com/training/articles/security-tips.html#InputValidation) 292 | 293 | ### Handling User Data 294 | 295 | * Minimize the use of APIs that access sensivite data 296 | * Consider hash/non-reversible form of the data when storing such as md5 297 | * Do not expose user data to other apps such as IPC, store to external storage, network etc 298 | * If a GUID is required, use UUID. Do not use phone identifiers. 299 | * Do NOT log these data 300 | 301 | * * * 302 | 303 | Read list 304 | 305 | * [http://developer.android.com/training/articles/security-tips.html#UserData](http://developer.android.com/training/articles/security-tips.html#UserData) 306 | 307 | ### Using WebView 308 | 309 | * Beware of cross-site-scripting (Javascript), because webview consume web content 310 | * Do not call setJavaScriptEnabled() if your app does not directly use JavaScript. By default, WebView does not execute JavaScript 311 | * Use clearCache() when accessing sensitive data 312 | * Use addJavaScriptInterface() with particular care because it allows JavaScript to invoke operations that are normally reserved for Android applications. If you use it, expose addJavaScriptInterface() only to web pages from which all input is trustworthy. 313 | 314 | * * * 315 | 316 | Read list 317 | 318 | * [http://developer.android.com/training/articles/security-tips.html#WebView](http://developer.android.com/training/articles/security-tips.html#WebView) 319 | 320 | ### Handling Credentials 321 | 322 | * Minimize the frequency of asking for user credentials, use authorization token and refresh it 323 | * Where possible, do not store username and password in the device 324 | * Perform initial authentication using the username and password supplied by the user, and then use a short-lived, service-specific authorization token. 325 | * Use account manager to prevent pass credentials to wrong application 326 | * Consider KeyStore for storage 327 | 328 | * * * 329 | 330 | Read list 331 | 332 | * [http://developer.android.com/training/articles/security-tips.html#WebView](http://developer.android.com/training/articles/security-tips.html#WebView) 333 | * [http://developer.android.com/reference/android/accounts/AccountManager.html](http://developer.android.com/reference/android/accounts/AccountManager.html) 334 | 335 | ### Using cryptography 336 | 337 | * Do not implement your own cryptographic algorithms. Android provides a wide array of algorithms for protecting data using cryptography. 338 | * Use AES or RSA 339 | * Use a secure random generator, (SecureRandom) 340 | * Use KeyStore if you need to store a key for repeated use 341 | * Use the highest level of pre-existing framework implementation 342 | * Consider using HttpsURLConnection or SSLSocket, rather than writing your own protocol. 343 | 344 | * * * 345 | 346 | Read list 347 | 348 | * [http://developer.android.com/training/articles/security-tips.html#Crypto](http://developer.android.com/training/articles/security-tips.html#Crypto) 349 | * [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard](http://en.wikipedia.org/wiki/Advanced_Encryption_Standard) 350 | * [http://en.wikipedia.org/wiki/RSA_%28cryptosystem%29](http://en.wikipedia.org/wiki/RSA_%28cryptosystem%29) 351 | * [http://docs.oracle.com/javase/7/docs/api/java/security/MessageDigest.html](http://docs.oracle.com/javase/7/docs/api/java/security/MessageDigest.html) 352 | 353 | ### Using Interprocess Communication 354 | 355 | * When you need to communicate with another application use android system functionality such as Intent, Binder or Messenger with a Service, and BroadcastReceiver. 356 | * The Android IPC mechanisms allow you to verify the identity of the application connecting to your IPC and set security policy for each IPC mechanism. 357 | * If your IPC mechanism is not intended for use by other applications, set the android:exported attribute to "false" in the component's manifest element, such as for the service. 358 | 359 | * * * 360 | 361 | Read list 362 | 363 | * [http://developer.android.com/training/articles/security-tips.html#IPC](http://developer.android.com/training/articles/security-tips.html#IPC) 364 | 365 | ### Using Broadcast Receivers 366 | 367 | ![](images/broadcast.png) 368 | 369 | * * * 370 | 371 | * Intents are the preferred mechanism for asynchronous IPC in Android by using broadcast receivers. 372 | * Set export atribute to receivers. By default, receivers are exported 373 | * Consider applying a permission to make sure the malicious apps cannot receive. 374 | * Use LocalBroadcastManager for internal broadcast. 375 | * Make input validation when you consume a broadcast. 376 | 377 | * * * 378 | 379 | Read list 380 | 381 | * [http://developer.android.com/training/articles/security-tips.html#IPC](http://developer.android.com/training/articles/security-tips.html#IPC) 382 | 383 | ### Using Services 384 | 385 | A Service is often used to supply functionality for other applications to use. Each service class must have a corresponding declaration in its manifest file 386 | 387 | * Always set exported attribute, by default it is false. 388 | * Always use permissions to limit to access 389 | * Use checkCallingPermission() before executing the call 390 | 391 | * * * 392 | 393 | Read list 394 | 395 | * [http://developer.android.com/training/articles/security-tips.html#IPC](http://developer.android.com/training/articles/security-tips.html#IPC) 396 | 397 | ### Using IPC - Binder and Messenger Interface 398 | 399 | * Preferred for RPC-style IPC 400 | * Use checkCallingPermission() to verify whether the caller has a required permission 401 | * Binder and Messenger objects are not declared in manifest, therefore you cannot apply permissions 402 | * If calling an interface provided locally by your own application, it may be useful to use the clearCallingIdentity() to satisfy internal security checks. 403 | 404 | * * * 405 | 406 | Read list 407 | 408 | * [http://developer.android.com/training/articles/security-tips.html#IPC](http://developer.android.com/training/articles/security-tips.html#IPC) 409 | * [http://stackoverflow.com/questions/6686686/android-binder-security](http://stackoverflow.com/questions/6686686/android-binder-security) 410 | 411 | ### Dynamically Loading Code 412 | 413 | * Do not load code from outside 414 | * The code runs in the same permissions as the application 415 | * Verify the source if you need to load 416 | 417 | * * * 418 | 419 | Read list 420 | 421 | * [http://developer.android.com/training/articles/security-tips.html#DynamicCode](http://developer.android.com/training/articles/security-tips.html#DynamicCode) 422 | 423 | ### Logging 424 | 425 | * Logs are a shared resource 426 | * Do not log sensitive data such as user name, credit card, password etc 427 | * Do not log data provided from 3rd parties. You don't know the content, thus don't expose it. 428 | * Remove debug logs in release version by using proguard 429 | 430 | * * * 431 | 432 | Read list 433 | 434 | ### Use Proguard 435 | 436 | * Obfuscate your code, thus it makes hard for reverse engineering 437 | * Removes your debug logs 438 | * Decrease the size 439 | * Optimizes slightly. 440 | 441 | * * * 442 | 443 | Read list 444 | 445 | * [http://developer.android.com/tools/help/proguard.html](http://developer.android.com/tools/help/proguard.html) 446 | 447 | ### Security with HTTPS and SSL 448 | 449 | * Anyone can generate their own certificate and private key, simple handshake does NOT prove that it is secure. 450 | * Use certificate authorities (CA) 451 | * Android 4.2 currently contains over 100 CAs. 452 | * Android uses blacklisting. Certain certificates or even whole CAs are prevented. 453 | * Use pinning. Restrict an app's trusted CAs, An app can further protect itself from fraudulently issued certificates by a technique known as pinning 454 | * Client certificates : SSL also supports the notion of client certificates that allow the server to validate the identity of a client. 455 | 456 | * * * 457 | 458 | Read list 459 | 460 | * [http://developer.android.com/training/articles/security-ssl.html](http://developer.android.com/training/articles/security-ssl.html) 461 | 462 | ### Be aware of reverse engineering 463 | 464 | * The application apk can be exported easily. Apk itself is a zip folder and it is very easy to extract it. 465 | * Reverse engineer can be done easily to the apk by using apktool. Apktool is a tool for reverse engineering 3rd party, closed, binary Android apps. It can decode resources to nearly original form and rebuild them after making some modifications; it makes possible to debug smali code step by step. Also it makes working with app easier because of project-like files structure and automation of some repetitive tasks like building apk, etc. 466 | 467 | * * * 468 | 469 | Read list 470 | 471 | * [https://code.google.com/p/android-apktool](https://code.google.com/p/android-apktool/) 472 | 473 | ### Be aware of app licensing 474 | 475 | Google Play offers a licensing service that lets you enforce licensing policies for applications that you publish on Google Play. With Google Play Licensing, your application can query Google Play at run time to obtain the licensing status for the current user, then allow or disallow further use as appropriate. 476 | 477 | * * * 478 | 479 | Read list 480 | 481 | * [http://developer.android.com/google/play/licensing/index.html](http://developer.android.com/google/play/licensing/index.html) 482 | 483 | --------------------------------------------------------------------------------