600.250 UI Cross Platform Development and the Android Security Model
2 likes865 views
The document discusses the challenges of cross-platform UI development, emphasizing the need for consistent user interfaces across various mobile operating systems and the complexities involved in transitioning between desktop and mobile. It reviews several third-party solutions designed to simplify this process, including frameworks such as PhoneGap and Mono, while also highlighting security considerations crucial in mobile app development, such as data isolation and input validation. Ultimately, it stresses the importance of incorporating security principles into the design of applications to mitigate risks associated with user data and application permissions.
600.250 UI Cross Platform Development and the Android Security Model
- 1. Cross-Platform UI Development 600.250 User Interfaces and Mobile Applications Michael Rushanan
- 2. Problems ● Providing a consistent UI across multiple platforms. – Most common/inefficient solution: implement UI individually for each platform. ● Number of platforms, at least in mobile, is increasing: – Ubuntu Touch – Android – IOS – Tizen – Moblin – MeeGo – Symbian – Windows 8 Phone – BlackBerry
- 3. Trivia Time! ● How many of you have heard of Tizen, Bada, Moblin, or MeeGo? ● Can anyone share an experience developing something event-driven (another mobile app maybe) while contrasting it with Android development so far? ● How do you mock up UI designs?
- 4. More Problems ● Providing a consistent UI across multiple platforms.... desktop vs. mobile. – What problems would you run into when transitioning from Desktop-to-Mobile, or Mobile-to-Desktop?
- 5. Welcome to UI Hell
- 6. Alternative Solutions ● Manufacturers have not been forthcoming with solutions in which to handle the inefficient approach to multi-platform support. The best you have is: – Xcode SDK supports streamlined development for both OS X and IOS development. It's at least in the same language. – Ubuntu and other Linux Mobile variants are leaning more heavily toward HTML5 for UI development (with an exposed API for gesture support). ● Third-party providers have been busy trying to solve the above and provide an intuitive UI development environment for not-well-versed programmers.
- 7. Trivia Time! ● Has anyone used a third-party UI development tool/SDK? ● How do you feel about HTML5, CSS, JavaScript... C#?
- 8. Third-Party Calling... ● MoSync SDK: Cross-platform SDK and HTML5 tools for mobile app development. – The Good: Free and open source. A free commercial license that removes support. Supports more than a handful of devices. – The Bad: Windows and OS X Only. ● PhoneGap: Unified UI development via one language: HTML, CSS, JavaScript. – The Good: I've used this to mock up applications before. It exposes device features via an API. Examples: Accelerometer, Camera, Compass, Geolocation, File, Notification, Storage. I can get this to work on Linux! – The Bad: Eh, it's all web based. Maybe this is ok? It also allows you to do some pretty non-standard things that blow off Android/IOS standardization. ● Mono: Cross platform, open source .NET development framework. – The Good: If you ever wanted to do .NET dev on a machine other than Windows, this was your calling. Mono offers MonoTouch (now Xamarin.iOS) for iOS and Mono (now Xamarin.Android) for Android. – The Bad: There are two separate SDKs for supporting iOS and Android. You have to purchase licenses to use these. You really have to <3 C# to make this transition However, the added perk of native code is speed and efficiency.
- 9. Transition UI consistency is hard to achieve, but a warranted task. Perhaps more painful, is achieving UI consistency while maintaining appropriate security design. Note: this is just an introduction to Android security.
- 10. Android Security Model 600.250 User Interfaces and Mobile Applications Michael Rushanan
- 11. Why Talk Security? This is a UI and Mobile Development class, right? Why do we care about security? – Whether it's event driven, or a simple deterministic shell script – you should always include security in your design! – When introducing principles of security into any application, there is often a trade-off between security and usability? Why do you think that is? – Can you think of some Android specific security considerations when implementing your application? ● Hint: Storage (external/internal), Content Providers, Networking, Input Validation, WebView, Interprocess Communication.
- 12. Core Security Features The, “things you don't have to worry about because it's already handled.” – Android Application Sandbox. ● Isolates data and code from other apps. – Encrypted Filesystem. – Application framework that provides secure functionality. ● Cryptography (never ever invent your own). ● Application Specific Permissions. ● Secure Interprocess Communication (IPC). – Granular Multi-layered Permissions. ● Application-defined. ● User-granted (don't rely on the user).
- 13. Storage ● Is the data I store on the device accessible to other applications? – Context.MODE_WORLD_READABLE/WRITEABLE ● No, and for good reason. Should Fruit Ninja have access to your ToDo list? Why? ● What about physical theft?
- 14. External Storage ● When and why would you use External Storage?
- 15. External Storage ● Music/ - Media scanner classifies all media found here as user music. ● Podcasts/ - Media scanner classifies all media found here as a podcast. ● Ringtones/ - Media scanner classifies all media found here as a ringtone. ● Alarms/ - Media scanner classifies all media found here as an alarm sound. ● Notifications/ - Media scanner classifies all media found here as a notification sound. ● Pictures/ - All photos (excluding those taken with the camera). ● Movies/ - All movies (excluding those taken with the camcorder). ● Download/ - Miscellaneous downloads. Oh... and caching too! Shamelessly stolen from: http://developer.android.com/guide/topics/data/data-storage.html#filesInternal
- 16. Content Providers ● Content providers are useful for offering a storage mechanism that can be limited to your application, or exported to allow access to some set of applications. ● Input validation. Why should we validate input from an untrusted application? ● What about an untrusted user? ;)
- 17. Final Note on Input Validation ● Android already has query methods that manage input validation for you... hence doing RAW QUERIES is bad. No, doing you own input validation does not make it better. – query() – update() – delete() Come on, what could go wrong? SQL Injection (we're interested in this), buffer overflows, use after free, and off-by-one errors (these last few are native code implementation errors that have bad consequences).
- 18. Permissions
- 19. ToDo Permissions ● What permissions should your ToDo app have? String String String READ_SMS NFC CAMERA Allows an application to read SMS messages. Allows applications to perform I/O operations over NFC Required to be able to access the camera device. String String String CALL_PHONE BRICK BLUETOOTH Allows an application to initiate a phone call Required to be able to disable the device (very Allows applications to connect to paired bluetooth without going through the Dialer user dangerous!). devices interface for the user to confirm the call being placed. String String String SET_ALARM VIBRATE SEND_SMS Allows an application to broadcast an Intent to set an Allows access to the vibrator Allows an application to send SMS messages. alarm for the user. String String String FORCE_BACK READ_CALL_LOG WRITE_SMS Allows an application to force a BACK Allows an application to read the user's call log. Allows an application to write SMS messages. operation on whatever is the top activity.
- 20. Networking ● IP Networking – you're data is only as secure as the protocol that you use. ● Encrypted socket-level communication can be easily implemented using the SSLSocket class. In a game app, why would you want to use the SSLSocket class?
- 21. Networking ● SMS is not secure. There has been work in academia to encrypt the contents of SMS, but the constraint on such implementations is the allowable size of SMS. ● Google recommends the use of Google Cloud Messaging (GCM) and IP networking for sending data messages.
- 22. WebView ● WebView consumes web content, that includes malformed JavaScript. Thus, common web security issues such as cross-site scripting can occur. ● We can turn JS off by not calling setJavaScriptEnabled(). ● Android provides addJavaScriptInterface() such that JS can directly interface with some set of your android methods. If you allow a general WebView to enable such functionality, a malicious JS could do what it pleases with your methods.
- 23. Cryptography ● We've already seen an example with SSLSocket and HTTPSUrlConnect. ● The take-away here is always the same, “Don't invent your own cryptographic methods/ciphers/whatever.” ● There is a Cipher class in Android that provides the appropriate methods for symmetric and asymmetric encryption. ● There is a secure random number generator in Android, SecureRandom. Please don't use a seeded random method instead.
- 24. Interprocess Communication ● Intents are the preferred mechanisms for asynchronous IPC in Android. – sendBroadcast() – sendOrderedBroadcast() ● You can apply access permissions to broadcasted intents so only certain applications can register to see the intents. If you're doing this, you might just consider invoking the receiver directly. – android:exported ● Allow use of IPC by other apps. – android:protectionLevel ● Characterizes the potential risk implied in the permission and indicates the procedure the system should follow when determining whether or not to grant permission to requester. – “normal” = default low risk, requests isolated application features. – “dangerous” = high-risk, requests private user data or control. – “signature” = granted only if the requesting application is signed with the same certificate as the application that declared the permission. – “signatureOrSystem” = system grants only to applications that are in the Android system image or as above. – android:permission ● Applications will need to declare a corresponding <uses-permission> element in their manifest to start, stop, or bind service.
- 25. Everything Else ● Dynamically Loading Code. – Discouraged to load code outside of APK. That's why libraries get bundled in the APK. ● Security in a Virtual Machine. – Dalvik is Andriod's runtime virtual machine. – This provides an application sandbox in which to run applications. If you're interested in more about sandboxes, ask me – I have links to some relevant papers (all in the Android world if you like). ● Security in Native Code. – Google encourages development with the SDK. However, you can use the NDK to write more complex code for runtime efficiency and performance. – Native code tends to be problematic because bugs lead to root level compromises (buffer overflows). – Native code written for an application is SANDBOXED. Just because it's native, doesn't mean that it escapes the model. However, it also makes it easier to escape the sandbox with buggy/insecure native code.