1 / 37

Draco: A System for Uniform and Fine-grained Access Control for Web Code on Android

Draco is a system for strict access control on web code in Android apps. It addresses flaws in existing WebView interactions by providing origin-based access policies through Draconian Policy Language (DPL). Protect your app from malicious web content now.

ccindy
Download Presentation

Draco: A System for Uniform and Fine-grained Access Control for Web Code on Android

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Draco: A System for Uniform and Fine-grained Access Control for Web Code on Android Presented By – Nikhil PAwar

  2. Publication and Authors. • ACM Conference on Computer and Communications Security 2016. • GülizSerayTuncay - UIUC • SoterisDemetriou– UIUC • Carl A. Gunter - UIUC

  3. Hand Raiser. • How many of you are familiar with how websites or web apps work? • How many are familiar with JavaScript and HTML5? • Lastly Android and iPhone Users?

  4. Mobile App Technology Stacks.

  5. Embedded Browser. Web Container for showing web pages in app context. 85% of the apps in the GooglePlay store contain at least one embedded browser. Use Cases Displaying web Content Displaying Ads Reuse of web code Hybrid Apps

  6. Webview. A Chromeless/Safariless browser window that’s typically configured to run full screen. A View that displays web pages. Earlier packaged with the OS now ships as a separate downloadable system application. UIWebView: iPhone : Apple’s WebKit. WebView: Android : Chromium : Apple’s webkit

  7. App – web code interaction.

  8. App – web code interaction.

  9. BRIDGES???

  10. App – web code interaction (Channels).

  11. Webview with JavaScript Interfaces. Register a Java object with a specific WebViewinstance, mWebView. The WebView API allows inserting Java objects into WebViews using the addJavaScriptInterface() method. JavaScript loaded in the WebView can have access to application’s internal Java code, giving web code the ability to interact more tightlywith an app, and in some cases get access to system resources.

  12. Webview with JavaScript Event handlers. • The WebView API allows developers to handle the alert, prompt and confirm JavaScript events, by registering the onJsAlert(), onJsPrompt() and onJsConfirm() Java callback methods. • Whenever the JavaScript side calls any of these event methods, their respective handler will be called, if it is overridden. • The developer is free to implement any logic in these event handlers. • Used in some hybrid frameworks to connect the web side to the local side

  13. Webview with HTML 5 APIs. The rise of HTML5 has broughtin a set of APIs that can give web applications the ability to access device hardware via JavaScript. E.g. Geolocation and getUserMedia, which enable access to GPS and to media devices such as camera and microphone Developer needs to make use of onGeolocationShowPrompt (for geolocation), and onPermissionRequest(for media devices) to grant or deny permission to the requests.

  14. prevalence of webview api.

  15. Ideal Scenario.

  16. Threat Model.

  17. Threat Model.

  18. Threat Model.

  19. Threat Model.

  20. Prior Studies Shortcomings. • Limited scope : since they mainly target hybrid apps. • Incomplete : since they focus only on protecting permission protected resources (e.g. camera, microphone) • Rely on whitelisting policies that always block unknown domains. • Ad hoc : since they focus only on a subset of resource access channels.

  21. CASE Study : USPS APP. Developer loaded pages from untrusted domains in the browser instead of the WebView Flawed navigation control logic The developer checks if the loaded URL contains “usps.com” rather than checking if the host’s domain name matches “usps.com”

  22. CASE STUDY : CVS CAREMARK APP. Developers registered two different javascript interfaces with the WebViewviz. ‘native’ and ‘WebJSInterface’ Native was meant to be used for internal use only, that is by trusted CVS domains while “WebJSInterface” was meant to be used in a more generic context and by untrusted domains But both of these interfaces belong to the same WebViewinstance.

  23. TEST ATTACK on CVS CAREMARK APP. The attack domain was able to retrieve personal information (like the user’s name, health care ID, email address, pharmacy preference, and location). Also was able to execute app functions such as using the camera on the victim device for barcode scanning functionality and retrieving images of user’s prescription drugs.

  24. CASE STUDY : JOB SEARCH. Has over 550 lines of code to contain flaws of webview But then the app offers the user the choice of adding web sites as a part of their profile and allowing the user to navigate to these sites! Attack using the JS interface by navigating to test "malicious" website exploiting a vulnerable interface. In this interface, the app offers the device’s unique ID, enabling/disabling Google play.

  25. NEED for change. • Redirection to malicious websites OR presence of malicious code in iframes on a non alien origin. • Lack on access control mechanism on foreign code of unknown origin. • Current disorganized and complex nature of interactions between web origins and applications creates confusion for developers. • Faulty implementation of navigation control logic or multiple WebViews with different levels of exposure.

  26. Enter DRACO. Draco, a fine grained, origin-based access control system for WebViews, with Draconian Policy Language (DPL), which allows app developers to declare policy rules dictating how different components within a WebView should be exposed to different web origins. A Draco Runtime System (DRS), which takes policy rules on system and internal app resources (i.e., JavaScript bridges) as an input from the developer and enforces them dynamically when a resource request is made by a web origin.

  27. DPL Grammar.

  28. Additional Features. Supports wild cards for origins in DPL, in order to allow creation of rules that can be applied to any origin. DPL also allows app developers to provide a description message for the user. This can be useful in cases the DPL rule governs resources at a very fine-granularity (e.g. at the method level) which might be challenging for the user to understand. A key aspect of the design of DRS is to avoid any modifications in the Android OS to make DRS easier to both deploy and update. In particular, DRS is built on top of the WebView system app on Android.

  29. Solutions.

  30. Architecture.

  31. RUNTIME DSA Unit.

  32. POLICY AND PERMISSION PARSING.

  33. IN-app RUNTIME.

  34. Summary. • How many of you are familiar with how websites or web apps work? • How many are familiar with JavaScript and HTML5? • Lastly Android and iPhone Users?

  35. Acknowledgement. • DarshanMhatre • Divyansh Bhatnagar

  36. References. • https://seclab.illinois.edu/wp-content/uploads/2016/10/draco-ccs-2016.pdf • https://myshadesofgray.wordpress.com/2014/04/15/hybrid-applications-and-android-native-browser/ • http://developer.telerik.com/featured/what-is-a-webview/

  37. Thank You.

More Related