Hacking OAuth 2 Avoiding Security Pitfalls in your Deployment

electricianpathInternet και Εφαρμογές Web

13 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

65 εμφανίσεις

Session ID:
Session Classification:
HTA-­‐F43
xxxxxxxxxxxx
Hacking OAuth 2
Avoiding Security Pitfalls in your
Deployment
Ping Identity
John

Bradley
Friday, 25 January, 13
Agenda

OAuth 2 (RFC 6749) Basic Concepts

Analysis of 2 real deployment failures resulting in complete
security compromise.

Facebook (Implicit flow used for Authrntication)

foursquare & iOS Developer framework (Back Channel
authentication)

Review of design choices.
Friday, 25 January, 13
Basic Concepts

OAuth is designed for Authorization not Authentication

There are two basic flows supported

Implicit - for Java Script clients in the browser

Code - for server or native clients

OAuth has a four party model

Authorization Server

Client

Protected Resource
Friday, 25 January, 13
SSO Flows
Friday, 25 January, 13
SSO Flows
Friday, 25 January, 13
SSO Flows
Friday, 25 January, 13
OAuth 2 Implicit Flow
Friday, 25 January, 13
OAuth 2 Code Flow
Friday, 25 January, 13
Facebook Connect Implicit flow
Friday, 25 January, 13
Facebook Connect Implicit flow

The Website (client in OAuth speak) redirects the user to Facebook
asking for access to the users portion of the Facebook Graph API
endpoint.

Facebook gets the users Authorization to give that access.

Facebook then redirects the user back to the client passing an access
token in the URL fragment.

The client performs a GET on the Facebook API endpoint using the
access token from step 3.

The Graph API endpoint returns a JSON object that contains a
Facebook user_id and other public and perhaps private information
based on what access the user granted.

The Website logs in user in as the user_id from the Graph API
endpoint.
Friday, 25 January, 13
Facebook Connect Implicit flow

The advantage to this is that anyone can read the instructions on
the
Facebook Developers Page
 and make there website a client.

The disadvantage is that they have no security.  Not to put too
fine a point on it, they have not Authenticated the User.  They
have gotten delegated access to the users information.

Any site that the user has granted access to there Facebook
profile can log into any site accepting Facebook login as the user.

Facebook has updated there JS libraries to use a type of audience
restriction. This is not well documented for developers of 3rd
party libraries.

Other people have made similar design choices leaving them
open to attack.
Friday, 25 January, 13
foursquare & iOS Native Apps

The foursquare Native app redirects the user to Facebook asking
for access to the users portion of the Facebook Graph API
endpoint.

Facebook gets the users Authorization to give that access.

Facebook then redirects the user back to the client passing an
code in the URL query parameter.

The client performs a GET on the Facebook Token endpoint using
the access token from step 3.

The token endpoint returns a access token for the Facebook
Graph API.

The Native app then passes the access token to its API Server
backend.
Friday, 25 January, 13
foursquare & iOS Native Apps

The backend API server performs a GET on the Facebook API
endpoint using the access token from step 3.

The Graph API endpoint returns a JSON object that contains a
Facebook user_id and other public and perhaps private
information based on what access the user granted.

The API server gives the native client access to the users location
and other information in the foursquare case.
Friday, 25 January, 13
foursquare & iOS Native Apps

On the face of it the client has authenticated the
use, so what’s the problem.

Like the first case anyone with a valid access token
to a Facebook users graph API endpoint can access
FourSquare as that user.

It is simple to access the FourSquare API and feed in
any access token.

FourSquare and other native app providers are now
passing the code to the backend or using other
audience restriction methods.
Friday, 25 January, 13
Design Choices

Never make security decisions based on tokens
that might have been issued to other clients.

Use OpenID Connect for Oauth based SSO

It adds Client Audience restriction to OAuth.

It protects against several other token swapping attacks.

Use the OAuth assertion flow for authenticating
native apps to backend API.

Google is implementing this with openID Connect for the Play
Store.
Friday, 25 January, 13
Questions?

OAuth 2 is only as secure as
you make it...
Friday, 25 January, 13