Android SSO 相关文章

Android第三方登录相关文章

---

Oauth2.0 协议 （originally created in late 2006）

---

相关工作(Oauth)

Sun, San-Tsai, and Konstantin Beznosov. “The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems.” Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012. paper

• Examined the implementations of three major IdPs (Facebook, Microsoft, and Google), and 96 Facebook RPs listed on Google Top 1000 website.
• Relied on the analysis of the HTTP messages passing through the browser during an SSO login session.
• Evaluation And Results:
  
  • Access token eavesdropping
  • Access token theft via XSS
  • Impersonation
  • Session swapping
  • Force-login CSRF
• Recommendations for IdPs
  
  • Explicit authorization flow registration
  • Whitelist redirect URIs
  • Support token refresh mechanism
  • Enforce single-use of authorization code
  • Avoid saving access token to cookie
  • Explicit user consent
  • Explicit user authentication
• Recommendations for RPs
  
  • SSO Domain separation
  • Confidentiality of SSO credentials
  • Authenticity of SSO credentials

---

相关工作（Mobile）

Wang, Rui, et al. “Unauthorized origin crossing on mobile platforms: Threats and mitigation.” Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 2013. paper

Our study inspects the main cross-origin channels on Android and IOS, including intent, scheme and web-accessing utility classes, and further analyzes the ways popular web services(Facebook, Dropbox, etc) and their apps utilize those channels to serve other apps.

By dissecting popular apps like Facebook, Dropbox, Google Plus, Yelp, and their SDKs, to understand how they utilize these channels to serve other apps on different mobile OSes. Our study found 5 generic cross-origin weaknesses in those high-profile apps and SDKs, which can be exploited through CSRF, login CSRF and cross-site scripting (XSS).

We present in this paper the design of the first mobile origin-based defense mechanism, called Morbs.

Exploiting the Intent Channel

Using “NEXT_INTENT” to invoke the app’s private Activity

Facebook

1. LoggedOutWebViewActivity
2. Malicious Javascript on SD card

Dropbox

1. LoginOrNewAcctActivity
2. VideoPlayerActivity
3. Malicious website

Abusing the Scheme Channel

Fbconnect(Android)

• “fbconnect://success#…”
• More specifically, a malicious app on the device first registers this fbconnect:// scheme, and then invokes the browser to load a Dialog URL, in an attempt to request the sensitive data of another app (e.g., the TexasHoldem app) from the Facebook server. This can be easily done by setting client_id in the URL to that of TexasHoldem because an app’s client_id is public.

Invoking Apps from the Web (Android and iOS)

Login CSRF attacks on Dropbox iOS SDK

• Dropbox
• PlainText (a popular text-editing app)
• A scheme URL: db- < APP_ID >://1/connect?oauth_token&oauth_token_secret&uid
• Attacker builds this URL and shares it on his Google Plus statu

Bypassing Facebook’s app authentication mechanism**

• Yelp and Facebook.
• Invoke Facebook via Yelp’s webview.
• Whoever posts a comment (contains special schemes) on Yelp acquires the same privilege as Yelp has on the victim’s Facebook account.

Attacks on Web-Accessing Utility Classes

#Exploiting Callbacks(iOS)

On iOS, we studied a WebView callback method the Facebook app registers, “shouldStartLoadWithRequest”, which is triggered each time the app’s WebView instance is navigated to a link.

If this link is in the form “fbrpc://appID=xyz&foo=123”, the callback method (provided by Facebook) creates a new URL “fbxyz://foo=123” to invoke an app with the appID “xyz” and set its input argument to “123”.

Origin-based Defense

Morbs (mobile origin based security)

• it exposes to the developers the true origins of the messages their apps/websites receive, enableing them to build protections based on such information.
• it allows the developers to specify their intentions, in the form of whitelists of origins their apps/websites can get messages from and send messages to.

Functions

void setOriginPolicy(type, senderOrRecipient, channelID, origins)
bool checkOriginPolicy(type, senderOrRecipient, channelID, from, to)

The framework of Morbs on Android

---

相关工作(Mobile Oauth)

Chen, Eric Y., et al. “Oauth demystified for mobile application developers.” Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2014. paper

• An in-house study of the OAuth protocol documentation that aims to identify what might be ambiguous or unspecified for mobile developers;
• A field-study of over 600 popular mobile applications that highlights how well developers fulfill the authentication and authorization goals in practice.
• Among the 149 applications that use Oauth, 89 of them (59.7%) were incorrectly implemented and thus vulnerable.

Differences between mobile and web platforms that affect Oauth security

• Different redirection mechanisms
• Lack of application identity
• Client-side protocol logic

Study of Real-world Mobile Application

• Storing relying party secrets locally
• Using authorization flows for authentication
• Handling redirection in mobile applications
  
  • Custom scheme and Intent
  • Mobile browser and WebView
    
    • Using custom schemes and custom Intent filters
    • Using URI parameters
• Inventing home-brewed protocol flows
  
  • Tencent
    

    ---

相关工作(Android Oauth)

Wang, Hui, et al. “Vulnerability assessment of oauth implementations in android applications.” Proceedings of the 31st Annual Computer Security Applications Conference. ACM, 2015. paper

AUTHDROID

• Proposed a framework utilizes an systematic security assessing methodology that adopts a five-party, three-stage model to detect typical vulnerabilities of popular OAuth implementations in Android apps.
• Studies the Chinese mainland mobile app markets (Baidu App Store, Tencent, Anzhi) that covers 15 mainstream OAuth service providers and top 100 relevant relying party apps.

• Further perform an empirical study of over 4000 apps to validate how frequently developers misuse the Oauth protocol. 86.2% of apps incorporating OAuth services are vulnerable.

• Considers issues of both Web-based and mobile-based OAuth protocol to build a more comprehensive security model for Android app’s OAuth usage.

• Apps of SP and RP are considered as important roles in our model.
• Three stages:
  
  1. the login stage
  2. the authorization stage
  3. the resource access stage
• Finally, security of the events in each stage is evaluated in two main aspects:
  
  1. whether the OAuth SDK implementations violate the security requirements of RFC specifications;
  2. whether developers misuse the SDKs or misunderstand SPs’ OAuth specification

According to our observation, most attack surfaces of OAuth in Android relate to the incorrect implementation of authorization grants or the use of improper user-agents. We summarize these attack surfaces in the following:

• User-agent hijacking: WebView is used as the user-agent.
• Client impersonation: App id/secret is hard coded in the RP app or is obtained during runtime and stored in the shared preferences.
• Network attack surface: SSL

Assessment Methodology

AuthDroid first utilizes static pattern matching to extract basic elements (e.g., user-agent, identity of SP) from RP app to get the major participants in the five-party model. The following aspects are assessed automatically:

• Service Providers
• User-agents
• Hard-coded Strings
• SSL Validation

Traffic analysis

• Burp Suite
• MitmProxy

Vulnerabilities

We summarize the most severe vulnerabilities as follows:

• V1: Improper User-agent
• V2: Lack of Authentication
• V3: Inadequate transmission protection
• V4: Insecure secret Management
• V5: Problematical server-side validation
• V6: Wrong authentication proof

---

Features of major SPs’ OAuth implementations. Three authorization grants are used: auth code (Authorization code grant), implicit (implicit grant), password (Resource Owner Password Credentials). Three types of user-agent in Android: WebView (W), SP app (A) and System browser (B).

Vulnerabilities of each SP’s OAuth implementation

---

相关工作(Android SSO Formal Analysis)

Ye, Quanqi, et al. “Formal analysis of a Single Sign-On protocol implementation for Android.” Engineering of Complex Computer Systems (ICECCS), 2015 20th International Conference on. IEEE, 2015. paper

we formally analyze the security properties of the implementation of the most widely used SSO service— Facebook Login service. We built a formal model in typed Pi-calculus for the extracted implicit protocol of Facebook Login via examining the network traces and source code of its SDK. Using ProVerif to analyze the model against a set of security properties, we successfully identified a major vulnerability which allows a malicious app to obtain the authentication credentials associated with the victim’s Facebook account. We have constructed a concrete attack on the real-world implementation after examining the counterexamples.

Modeling Attackers

• Network Attacker: The adversary can intercept, drop and replay the network messages on the channel
• Malicious SP_C Attacker: In this model, the attacker can communicate with IdP_C as normal app. It can access the local storage and access whatever data that belongs to it. But it can not intercept on the communication channel between IdP_C and IdP_S.
• Malicious App in System
  
  • App with root privilege: App can access to the local storage and access to all the data including app’s data.
  • App without root privilege: App can also access to Local Storage, but it can only access to its own data in it.

Identified Vulnerability

The IdP_C stores the credentials in the local storage including the cookies and access token. With root privilege, an third party app can have access to other app’s private storage and when the cookies belong to Facebook are stored in local storage without being encrypted, it is possible for an attacker to get this credential and have access to user’s Facebook account.

---

相关工作(Oauth Model-based Security Testing)

Yang, Ronghai, et al. “Model-based security testing: an empirical study on OAuth 2.0 implementations.” Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security. ACM, 2016. paper

we propose an adaptive model-based testing framework to perform automated, large-scale security assessments for OAuth 2.0 implementations in practice.

• its ability to identify existing vulnerabilities and discover new ones in an automated manner;
• improved testing coverage as all possible execution paths within the scope of the model will be checked
• its ability to cater for the implementation differences of practical OAuth systems/applications, which enables the analyst to offload the manual efforts for large-scale testing of OAuth implementations.

We have designed and implemented OAuthTester to realize our proposed framework. Using OAuthTester, we examine the implementations of 4 major Identity Providers as well as 500 top-ranked US and Chinese websites which use the OAuth-based Single-Sign-On service provided by the formers.

Our empirical study discovers 3 previously unknown yet critical vulnerabilities while demonstrating new exploits for one old problem.

• Misuse of the STATE Parameter
• Amplification Attack via Dual-Role IdPs
• Failure to Revoke Authorization
• New Discoveries on the Failure to Adopt TLS Protection

---

相关工作(SSO Implementations Automatic Extraction)

Bai, Guangdong, et al. “AUTHSCAN: Automatic Extraction of Web Authentication Protocols from Implementations.” NDSS. 2013. paper

In this paper, we address a complementary problem of automatically extracting specifications from implementations. We propose AUTHSCAN, an end-to-end platform to automatically recover authentication protocol specifications from their implementations. AUTHSCAN finds a total of 7 security vulnerabilities using off-the-shelf verification tools in specifications it recovers, which include SSO protocol implementations and custom web authentication logic of websites with millions of users.

Attacker Models

• Network Attacker
  
  • We model the network attacker using the Dolev-Yao model, that is, an active network attacker is able to eavesdrop all messages and control the contents of unencrypted messages in the public network under the constraints of cyptographic primitives.
• Web Attacker
  
  • modeling the same-origin restrictions
  • model HTTP headers like Referrer
  • we also model the semantics of postMessage by encrypting all messages transmitted through postMessage with a key.
  • We do not model web attackers with the ability to perform Cross-Site Scripting (XSS) attacks and complex social-engineering attacks in this work.

Evaluation Subjects

• BrowerID
• Facebook Connect
• Windows Live ID
• Standalone Web Sites

Protocol Analysis and Vulnerabilities

• Replay Attack in BrowserID
• CSRF Attack in BrowserID
• Secret Token Leak in Facebook Connect
• Non-secret Token in Using Windows Live ID
• Guessable Token in Standalone Sites

Statistics in our experiments

---

相关工作(OAuth 2.0 Formal Security Analysis)

Fett, Daniel, Ralf Küsters, and Guido Schmitz. “A comprehensive formal security analysis of oauth 2.0.” Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2016. paper

In this paper, we carry out the first extensive formal analysis of the OAuth 2.0 standard in an expressive web model. Our analysis aims at establishing strong authorization, authentication, and session integrity guarantees, for which we provide formal definitions. In our formal analysis, all four OAuth grant types (authorization code grant, implicit grant, resource owner password credentials grant, and the client credentials grant) are covered.

Found Attacks

• 307 Redirect Attack
• IdP Mix-Up Attack
• State Leak Attack
• Naïve RP Session Integrity Attack

All four attacks can be applied to OpenID Connect as well.

---

相关工作(Phishing on Mobile Devices

Felt, Adrienne Porter, and David Wagner. Phishing on mobile devices. na, 2011. paper

We assess the risk of phishing on mobile platforms. We conduct a systematic analysis of ways in which mobile applications and web sites link to each other. To evaluate the risk, we study 85 web sites and 100 mobile applications and discover that web sites and applications regularly ask users to type their passwords into contexts that are vulnerable to spoofing.

We categorize the attacks according to whether the sender and target are mobile applications or web sites: mobile-to-mobile, mobile-to-web, web-to-mobile, and web-to-web. For each of the four categories, we present both direct and man-in-the-middle attacks.

In a direct phishing attack, the sender is a malicious application that links the user to its own spoof screen instead of the real target application. In a man-in-the-middle attack, the sender is benign, but another party intercepts the link and loads a spoofed target application in place of the intended target application.

The contributions of this paper are:

• We believe we are the first to discuss phishing attacks between mobile applications and web sites.
• We present data on how mobile applications and web sites interact. This provides insight into the application behaviors that users are familiar with.
• We present and evaluate 15 types of phishing attacks. 13 of the attacks are novel, and 1 improves a known mobile browser spoofing technique.

Background

User Interfaces on Mobile Devices

• Mobile Application Identity Only one mobile application can control the screen at a time. No major smartphone operating system displays the identity of the foreground application.
• Web Site Identity Mobile browsers display only one browser window at a time. Web sites can hide the URL bar once the page has loaded; this commonly used feature allows the web site to fill the available screen.

Common Control Transfers
We study popular Android, iOS, and web applications to identify how often and when control transfers lead to password or payment entry.

• Mobile -> Mobile: Sharing, Upgrades, Music, Credits.
• Mobile -> Web: Social sharing. Payment.
• Web -> Mobile: Share content, Download application.
• Web -> Web: Web-to-web links are a standard part of the Internet.

Phishing Attacks

Mobile -> Mobile

Direct Attack

A malicious application could similarly include “Share on Facebook” or “Upgrade this application” buttons. Clicking on one of the buttons would send the user to a screen that spoofs the target application.

Man-In-The-Middle

• Scheme Squatting
• Task Interception

Mobile -> Web

A malicious application could present the user with butatons to share content or purchase an item. The attacker can then eavesdrop on the user’s interaction with an embedded web site or present the user with a site in a fake browser.

Direct Attack

• Embedded Web Content. Both Android and iOS allow applications to insert JavaScript into embedded WebViews, and there is no mechanism for web sites to prevent this.
• Web Browser. If the target web site hides its URL bar, then the mobile application could load a phishing web site in the browser. The phishing web site would then hide the URL bar. If the target web site does not hide its URL bar, then the attacker can spoof the trusted browser chrome. There are two ways to do this. First, the attacker could launch the browser, hide the URL bar, and then present a fake URL bar. Alternately, the attacker could display a fake browser that looks identical to the real browser, except it lies about the current URL.
  

Man-In-The-Middle

When users of mobile devices connect to the Internet over insecure WiFi hotspots, they are at risk of man-in- the-middle attacks.

Web -> Mobile

Direct Attack

Malicious web sites could mimic this behavior without appearing suspicious. For example, a phishing site might provide a link to buy a song from the iTunes Store. When the user clicks on the button, the web site can pretend to transfer the user to the target application, but actually display a fake version of the target application.

Man-In-The-Middle

Web-to-mobile links are vulnerable to the same man-in- the-middle attacks as mobile-to-mobile links, with the same strengths and weaknesses。

Web -> Web

Direct Attack

Niu et al. present detailed web-to-web phishing attacks on mobile devices. They discuss how phishing attacks can be built by hiding the browser URL bar or spoofing the URL bar. URL bar spoofing has three steps: (1) the attacker hides the legitimate URL bar, (2) the attacker adds a spoofed URL bar to the visible top of the page, and (3) the attacker catches any attempts to scroll to the real top of the page and instead jumps to the fake URL bar.

Man-In-The-Middle

If the user ever visits any HTTP page in the browser while there is an active attacker tampering with the network connection, then all subsequent browsing can be compromised.

We match each attack technique with the legitimate behavior that it subverts, along with how common the legitimate behavior is.

---

相关工作(Attacks on Android WebView)

Luo, T., Hao, H., Du, W., Wang, Y., & Yin, H. (2011, December). Attacks on WebView in the Android system. In Proceedings of the 27th Annual Computer Security Applications Conference (pp. 343-352). ACM. paper

To achieve a better interaction between apps and their embedded“browsers”, WebView provides a number of APIs, allowing code in apps to invoke and be invoked by the JavaScript code within the web pages, intercept their events, and modify those events.

Two essential pieces of the Web’s security infrastructure are weakened if WebView and its APIs are used: the Trusted Computing Base (TCB) at the client side, and the sandbox protection implemented by browsers. As results, many attacks can be launched either against apps or by them. The objective of this paper is to present these attacks, analyze their fundamental causes, and discuss potential solutions.

In the Android Market, 86 percent of the top 20 most downloaded Android apps in each of the 10 categories use WebView.

What truly makes customization possible is the APIs provided by WebView. WebView not only allows apps to display web content, more importantly, through its APIs, it enables apps to interact with the web content. The interaction is two-way:

• From apps to web pages, apps can invoke JavaScript code within web pages or insert their own JavaScript code into web pages; apps can also monitor and intercept the events occurred within web pages, and respond to them.
• From web pages to apps, apps can register interfaces to WebView, so JavaScript code in the embedded web pages can invoke these interfaces.

Tutorial On WebView

Run JavaScript

WebView webView = new WebView();
webView.getSettings().setJavaScriptEnabled(true);

Event monitoring

WebViewClinet wvclient = new WebViewClient(){
    public boolean shouldOverrideUrlLoading(WebView view,String url){
        //codes
    };
}

Invoke JavaScript From Java

String str="
Hello World
";
webView.loadUrl("javascript:document.appendChild(str);");
webView.loadUrl("javascript:document.cookie=’’;");

Invoke Java from JavaScript

WebView provides a mechanism for the JavaScript code inside it to invoke Android apps’ Java code. The API used for this purpose is called addJavascriptInterface. Android applications can register Java objects to WebView through this API, and all the public methods in these Java objects can be invoked by the JavaScript code from inside WebView.

wv.addJavascriptInterface(new FileUtils(), "FUtil");
 ...
// The FileUtils class has the following methods:
public int write (String filename, String data, boolean append); 
public String read (filename);

<script> 
    filename = '/data/data/com.livingsocial.www/' + id + '_cache.txt';
    FUtil.write(filename, data, false);
script>

Threat Models

Attacks from Malicious Web Pages

In this attack model, we assume that apps are benign, and they are intended to serve a web application, such as Facebook. The objective of attackers is to compromise the apps and their intended web application. To achieve this, the attackers need to trick the victim to load their web pages into the apps, and then launch attacks on the target WebView.

Attacks from Malicious Apps

In this threat model, we assume that an attacker owns a malicious app, designed specifically for a web application, e.g., Facebook. The goal of the attacker is to directly launch attacks on the web application. Obviously, these attacks only make sense for third-party apps.

Attacks from web pages

Attacks through Holes on the Sandbox

Among all WebView’s APIs, addJavascriptInterface is probably the most interesting one.

• Attacks on the System. [DroidGap, myFBApp] Malicious web pages can be loaded into WebView, and its JavaScript code can access the ContactManager interface to steal the user’s personal contact information.
• Attacks on Web Application. [LivingSocial]

Attacks through Frame Confusion

The JavaScript function contacts.droidFoundContact in the example is more like a callback function handler registered by the LivingSocial web page. The use of the asynchronous mode is quite common among Android applications. Unfortunately, if a page has frames (e.g. iframes), the frame making the invocation may not be the one receiving the callback. This interesting and unexpected property of WebView becomes a source of attacks.

• Frame Confusion
• Attack from Child Frame
• Attack from Main Frame

Attack from malicious apps

Attack Methods

There are several ways to launch the attacks on WebView. We classified them in two categories, based on the WebView features that were taken advantaged of.

JavaScript Injection

class MyJS {
     public void SendSecret(String secret)
    { 
        ... do whatever you want with the secret ...
    } 
}
webview.addJavascriptInterface(new MyJS(), "JsShow");
webview.setWebViewClient(new WebViewClient() {     
    public void onPageFinished(WebView view, String url){
        view.loadUrl("javascript: 
                     window.JsShow.SendSecret(document.cookie)");
    }
}

Event Sniffing and Hijacking The WebViewClient class defines 14 interfaces, using which applications can register event handlers to WebView. With those 14 hooks, host applications can know almost everything that a user does within WebView.

---

相关工作(WebView Android Access Control)

Yu J, Yamauchi T. Access control to prevent attacks exploiting vulnerabilities of WebView in Android OS[C]//High Performance Computing and Communications & 2013 IEEE International Conference on Embedded and Ubiquitous Computing (HPCC_EUC), 2013 IEEE 10th International Conference on. IEEE, 2013: 1628-1633. paper

By using the APIs provided in WebView, Android applications can interact with web pages. The interaction allows JavaScript code within the web pages to access resources on the Android device by using the Java object, which is registered into WebView. If this WebView feature were exploited by an attacker, JavaScript code could be used to launch attacks. To address these threats, we propose a method that performs access control on the security-sensitive APIs at the Java object level. The proposed method uses static analysis to identify these security-sensitive APIs, detects threats at runtime, and notifies the user if threats are detected, thereby preventing attacks from web pages.

Contributions of this work are as follows:

• Detect all threats that come from web pages.
• Support the user in making a decision.
• Prevent the threats without stopping the Android app.

Solution

1. We use static analysis to determine what APIs are used in the Android app. Tools: Dedexer, dex2jar, JD-GUI.
2. By analyzing the assembly code generated by dexdump, we can determine which Java class includes the security-sensitive APIs that need to be controlled.
3. we hook the addJavascriptInterface API at runtime to detect whether a threat exists in the Java object. Threat detection is based on the result of the static analysis. If the Java object is determined to invoke the security-sensitive APIs, the user will be warned and prompted to decide whether to grant permission based on the information presented.

---

相关工作(Enhance OAuth Implementations In Smart Phones)

Shehab M, Mohsen F. Towards enhancing the security of oauth implementations in smart phones[C]//Mobile Services (MS), 2014 IEEE International Conference on. IEEE, 2014: 39-46. paper

In this paper, we analyze the different OAuth implementations adopted by the SDKs of the popular resource providers on smartphones and demonstrate possible attacks on most OAuth implementations. By analyzing source code of more than 430 popular Android apps we summarized the trends followed by the service providers and by the OAuth development choices made by application developers. In addition, we propose an application-based OAuth Manager framework, that provides a secure OAuth flow in smartphones that is based on the concept of privilege separation and does not require high overhead.

We analyze the different OAuth implementations adopted by the SDKs of the popular resource providers on smartphones, which include Facebook, Twitter, Dropbox, Microsoft Live, Google Plus, Box, Instagram, LinkedIn, and Flickr.

OAuth and Mobile Applications

On desktops, the web browser’s isolation mechanisms, such as the same origin policy, provides the required separation between the user-agent, client and authorization server. The user-agent presents the resource owner with the authentication and authorization information, and the user-agent is used to redirect and pass tokens between the client and the authorization server. In mobile applications, the user agent is implemented using WebView, system browser, and provider app.

Attacks Against OAuth Embedded Web Browser

• Stealing User Credentials. An attack to steal the user credentials (username and password) during the authentication stage can easily be executed by a malicious app in two stages, first injecting JavaScript in the WebView to retrieve the user’s email and password upon clicking the submit button, and second registering a JavaScript interface that enables the embedded JavaScript to send the retrieved email and password to the hosting app.
• Modifying the Authorization Interface. Since the authorization page is displayed in a WebView, a malicious client app can easily modify the list of requested permissions displayed in the authorization page. This attack will trick the user into incorrectly interpreting the level of access requested by the app.

Attacks against System Native Browser

Compared to the embedded web component, the system browser provides stronger isolation guarantees. However, a malicious app can exploit the channel between the intent manager and the client app. For instance, a malicious app could register similar intent filter as the client app, which would result in passing the access token to the malicious app.

Resource Provider Native App

This approach provides the required separation between the client and the user-agent and some provider apps maintain a user authentication session, which does not require the user to re-authenticate during the OAuth flow and reduces the user effort.

Adversary Model

In this paper, we assume an attacker is a skillful developer that implements malicious apps and makes them available on the internet. The malicious apps provide a service, like connecting to Facebook, Twitter, etc. The apps contain code segments for collecting users’ credentials with the different service providers. The victim (Android user) downloads these apps to enjoy the services they provide. An attacker may also have a physical access to the victim device to manually install malicious apps. The malicious apps take advantage of the vulnerabilities that exist in the providers’ SDKs and developers’ apps. The attacker needs to have good knowledge of these SDKs and reverse engineering techniques.

Proposed Approach

We propose to use the privilege separation concept to ensure that the client application has no control over the user-agent. We removed the critical OAuth components and implemented it in a separate application (secure sandbox), which we refer to as the OAuth Manager. OAuth Manger running on a separate application and communicating with the client apps via the intents.

---

相关工作(Access Control Web Code Android)

Tuncay G S, Demetriou S, Gunter C A. Draco: A System for Uniform and Fine-grained Access Control for Web Code on Android[C]//Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2016: 104-115. paper

In this work, our goal is to provide a generic solution that works for all apps that utilize embedded web browsers and protects all channels that give access to internal app and device resources. Towards realizing this goal, we built Draco, a uniform and fine-grained access control framework for web code running on Android embedded browsers (viz.,WebView). Draco provides a declarative policy language that allows developers to define policies to specify the desired access characteristics of web origins in a fine-grained fashion, and a runtime system that dynamically enforces the policies.

We do not assume any modifications to the Android operating system, and implement Draco in the Chromium Android System WebView app to enable seamless deployment.

Draco Access Control

Draconian Policy Language

Draco supports a declarative policy language that allows app developers to describe their security policies with respect to remote code origins. Here we present the Draconian Policy Language(DPL)

By default, if a DPL rule does not exist to allow the web code to access any resource, then access is denied. Draco allows developers to write policy rules which dictate how sensitive resources can be accessed by web code. We define the syntax of a DPL rule as:

<policy rule>::=<subject> ';' <trust level> | <subject> ';'
                   <channel> ';' <decision point>

Each Draconian policy rule is applied on a subject. The subject indicates the web origin whose web content was loaded in the WebView.

Draco Runtime System architecture