1000 ways to die in mobile oauth - black hat briefings 1.0a. user service provider relying party 1....

80

Upload: truongxuyen

Post on 28-Mar-2018

221 views

Category:

Documents


5 download

TRANSCRIPT

Page 1: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 3: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Page 4: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 5: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Page 6: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 7: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 8: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 9: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 10: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Resource Owner/End User Relying PartyService Provider

Page 11: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Service Provider

A process for end-users to grant a third-party website access to their private resources stored on a service provider.

Resource Owner

Relying Party

?

Page 12: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

A process for end-users to grant a third-party website access to their private resources stored on a service provider.

Resource Owner

Relying Party Service Provider

?

Page 13: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

○○○○

Page 14: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

○○○○

Page 15: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 16: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Register your application on the service provider

Page 17: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party1. [App ID, Resource_type ]

2. Req Token

Verifies signature

● ‘[]’ means signed with app secret

● Resource_type can be: email, user’s photos, etc

Page 18: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party1. [App ID, Resource_type ]

2. Req Token

Verifies signature

3. Req Token + Redirect URI, Redirect User to gain permissions

Page 19: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party1. [App ID, Resource_type ]

2. Req Token

Verifies signature

3. Req Token + Redirect URI, Redirect User to gain permissions

Page 20: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party1. [App ID, Resource_type ]

2. Req Token

Verifies signature

3. Req Token + Redirect URI, Redirect User to gain permissions

4. Req Token, Redirect User back to relying party

5. [Req Token]

6. Access Token

Verifies signature

7. [Access Token]

8. Protected resource: email, contact, etc

Verifies signature

Page 21: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 22: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party’s web server1. [App ID, Resource_type ]

2. Req Token

Verifies signature

3. Req Token + Redirect URI, Redirect User to gain permissions

4. Req Token, Redirect User back to relying party

5. [Req Token]

6. Access Token

Verifies signature

7. [Access Token]*

8. Protected resource: email, contact, etc

Verifies signature

* The secret is only known between the relying party and service provider

Page 23: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 24: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party’s mobile client1. [App ID, Resource_type ]

2. Req Token

Verifies signature

3. Req Token + Redirect URI, Redirect User to gain permissions

4. Req Token, Redirect User back to relying party

5. [Req Token]

6. Access Token

Verifies signature

7. [Access Token]*

8. Protected resource: email, contact, etc

Verifies signatureMany applications decide to bundle this secret into their mobile apps.

Page 25: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

src/com/pinterest/activity/signin/TwitterAuthActivity.java

26: return (new ServiceBuilder()).

provider(org/scribe/builder/api/TwitterApi).

apiKey("Zr6TVkMT2KhKIZwERTB8IQ").

apiSecret("WYmVb7f0a************************X83gNCGQ0").

callback("oauth://twitter").

build();

Page 26: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 27: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 28: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

● After we notified Quora and Pinterest in 2014○ Both Quora and Pinterest revoked their

existing relying party secrets.○ Quora’s twitter authentication was

non-functional after our report.● Both are not using twitter login

anymore...

Page 29: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Page 30: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party1. [App ID, Resource_type ]

2. Req Token

Verifies signature

3. Req Token + Redirect URI, Redirect User to gain permissions

4. Req Token + Verifier , Redirect User back to relying party

5. [Req Token, Verifier]

6. Access Token

Verifies signature, Verifier

7. [Access Token]*

8. Protected resource

Verifies signature

Verifier is only sent to the registered redirect URL

OAuth 1.0a

Page 31: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 32: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party1. [App ID, Resource_type ]

2. Req Token

Verifies signature

3. Req Token + callback URI, Redirect User to gain permissions

4. Req Token + Verifier , Redirect User back to relying party

5. [Req Token, Verifier]

6. Access Token

Verifies signature, Verifier

7. [Access Token]*

8. Protected resource

Verifies signature Evernote doesn’t checkThe redirect URI

Get the local secrets of a benign app to fake the login

Change the callback URI

Page 33: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Page 34: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 35: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 36: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 37: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party1. client_id, scope, redirect_uri Redirect User to gain permissions

2. Access Token , Redirect User back to relying party

3. Access Token

Verifies redirect URI

Relying party must supply a “redirect URI” to receive access tokens from the service provider

● No relying party secret!● No signature/encryption● Access token is not

bound to a RP

4. Protected resource

Page 38: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party1. client_id, scope, redirect_uri Redirect User to gain permissions

2. Access Token , Redirect User back to relying party

3. Access Token

Verifies redirect URI*

*The receiver of the access token must be the same as the registered redirect URI

Browser redirection (HTTP 302)

4. Protected resource

Page 39: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

spotify server

User’s device

Facebook server

Access token Access token

intent://token

The “intent” URI- scheme is registered by the receiving relying party application

Page 40: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 41: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

spotify server

User’s device

Facebook server

Access token

Access token

intent://token

attacker server

The attacker can registerand overwrite the callback for the “intent” scheme

Page 42: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 43: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

○○

relying_party = Activity.getCallingPackage();

dev_key_hash = getPackageManager().

getPackageInfo(relying_party, PackageManager.GET_SIGNATURES);

Page 44: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 45: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

AuthenticationA process for a user to prove his or her identity to a relying party, utilizing his or her existing session with the service provider.

Service Provider Resource Owner

?Relying Party

Page 46: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

AuthenticationA process for a user to prove his or her identity to a relying party, utilizing his or her existing session with the service provider.

Service Provider Relying PartyResource Owner

?

Page 47: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Authentication

Service Provider

Resource Owner

Relying Party

Authorization

Relying Party

Service Provider

?

Resource Owner

?

Page 48: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 49: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

The OAuth 2.0 implicit flow is not secure for authentication

User Service Provider Relying Party1. client_id, scope, redirect_uri Redirect User to gain permissions

2. Access Token , Redirect User back to relying party

3. Access Token is not bound to a relying party

4. UserID

Page 50: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Attacker server

Smartphone

AuthenticatesBob’s Access token

Bob

Facebook server

Bob’s Access token

Wish server

Smartphone

AuthenticatesAttacker’s Access token

Attacker

Facebook server

Bob’s Access token

Bob’s Access tokenUser ID

Page 51: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

<script

type="text/javascript">window.location.href="fbconnect:\/\/succe

ss#granted_scopes=user_birthday\u00252Cuser_hometown\u00252Cuser

_location\u00252Cuser_likes\u00252Cuser_friends\u00252Cemail\u00

252Ccontact_email\u00252Cpublic_profile&denied_scopes=&access_to

ken=XXXXXXXXXXX&expires_in=5182633";</script>

GET /v2.2/me?access_token=XXXXXXXXXXX&format=json&sdk=android

...

{

"id": "100007872092560",

"birthday": "11\/25\/1989",

"email": "yutong\u0040lockie.io",

"first_name": "Yutong",

"gender": "male",

"last_name": "Pei",

"link":

"https:\/\/www.facebook.com\/app_scoped_user_id\/100007872092560

\/",

"locale": "en_US",

"name": "Yutong Pei",

"timezone": -7,

"updated_time": "2014-02-22T02:45:44+0000",

"verified": false

}

Page 52: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Page 53: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 54: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 55: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwic3ViIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiczZCaGRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwLCJpYXQiOjEzMTEyODA5NzAsImF0X2hhc2giOiI3N1FtVVB0alBmeld0RjJBbnBLOVJRIn0.VW_s1XIAkhlFTfx90VjofHjbRqM5MEtMA5mlctc7dCE

{ "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "at_hash": "77QmUPtjPfzWtF2AnpK9RQ" }

Page 56: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party1. client_id, scope, redirect_uri Redirect User to gain permissions

2. Authorization Code , Redirect User back to relying party

3. Authorization Code + Client Credential

5. Access Token

6. Protected resource

4. Access Token Service side request

Page 57: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Relying Party1. client_id, scope, redirect_uri Redirect User to gain permissions

2. Authorization Code , Redirect User back to relying party

3. Authorization Code + Client Credential

5. Access Token

6. Protected resource

4. Access Token

The authorization code should be one-time password

The service provider should verify that the authorization code belongs to the same relying party

Page 58: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 59: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Attacker server

Android

OAuth2 code flowBob’s

Authorization code

Bob

Sina server

Bob’s Authorization code

Sohu server

Android

OAuth2 code flow

Attacker’s Authorization code

Attacker

Sina server

Bob’s Authorization code

Bob’s Authorization code

Bob’s Access token

Page 60: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 61: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Page 62: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 63: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 64: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Malicious Relying party

2. User logs into Tencent3. Access token,

[App ID, User ID]

1. App ID, redirect URI

Verifies redirect URI

4. Access token, [App ID, User ID]

● No information about relying party for Tencent mobile UI

User’s device App ID is public information

The user sees the same Tencent login-dialog for all relying parties

Page 65: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

User Service Provider Malicious Relying party

2. User logs into Tencent3. Access token,

[App ID, User ID]

1. App ID, redirect URI

Verifies redirect URI

4. Access token, [App ID, User ID]

● No information about relying party for Tencent mobile UI

Attacker Service Provider Relying party

2. Attacker logs into Tencent3. Access token,

[App ID, User ID]

1. App ID, redirect URI

Verifies redirect URI

4. Access token, [App ID, User ID]

User’s device Attacker’s device

Impact:~700 million users affected. Tencent acknowledged the vulnerability and patched it within a week.

Page 66: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 67: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 68: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 69: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Smartphone

Login attacker’s account

Attacker

Github server

Phishing link to attacker’s account

Bob will be logged into attacker’s account

Bob

Smartphone

Page 70: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Attacker starts the OAuth flow on his machine:https://github.com/login/oauth/authorize?client_id=2722d7d1c25dca9b3559

&redirect_uri=https://app.autocode.run&scope=user:email,public_repo

Tricks the user into rendering this iframe:<iframe src="https://app.autocode.run/?code=f3ec63e21bb4841d01f9"

style="visibility:hidden;display:none"></iframe>

Page 71: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

○○

Page 72: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 73: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 74: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Webview provides the feature that app can get the cookies from the webview it embeds

Facebook uses long term cookie even inside webview, and attacker can reuse the cookie to log in as the user.

Page 75: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Page 76: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 77: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback
Page 78: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Page 79: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

Page 80: 1000 ways to die in mobile OAUTH - Black Hat Briefings 1.0a. User Service Provider Relying Party 1. [App ID, Resource_type ] 2. Req Token Verifies signature 3. Req Token + callback

{eric.chen,yuan.tian,patrick.tague}@sv.cmu,[email protected]@uber.com