Slides - NUS Security Research

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

21 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

79 εμφανίσεις

Explicating SDKs:

Uncovering Assumptions Underlying
Secure Authentication and Authorization

Rui

Wang,
Yuchen

Zhou,
Shuo

Chen,

Shaz

Qadeer
, David Evans, Yuri
Gurevich

In
Usenix

Security 2013

Web Authentication & Single Sign
-
On


Single Sign
-
On (SSO)


BrowserID

(Mozilla)


Facebook

Connect


250+ Million users, 2,000,000
websites


OpenID


one billion users, 50,000 websites




2


Web Authentication

Single Sign
-
On


Functionality provided by Token


Authentication: Authenticate end user to SP


Authorization: SP can access user’s social data on IDP

Alice

Identity Provider (IDP)

Service Provider (SP)

e.g.,

e.g.,

Development Paradigm

IDP

SDK
-
Client

SDK
-
Server

SP

Client:
FooApp
c

Server:foo.com

Development

Deployment

Motivation


Security relies on:


SDKs


Underlying system


Implicit assumptions


undocumented


SDK providers are
unaware

of them


If developers use the SDKs in a
reasonable

ways, will the resulting
applications be
secure
?

NO!

A real example: use of Microsoft Live ID





The attacker can request a token
to view
public information
for
the victim and present it to App
server.



Goal of this paper


To systematically identify the
assumptions

required to use
an
SDK

to produce
secure

applications


Approach Overview

Semantic
Model

Results


Test three sets of applications using major
authentication/authorization SDKs


Facebook

PHP SDK,
Miscrosoft

Live Connect, Windows 8
Authentication Broker SDK


78%, 86%, 67% are vulnerable


Lead to modification of
OAuth

2.0 specification


Outline


Threat Model & Security Properties


Semantic Modeling


Modeling language


Modeling adversary


Modeling concrete modules


Results


Threat Model




Malicious application


Unconstrained behavior


Only limited to functionality provided by client
runtime


Unconstrained external server

Security Properties


Secrecy


Access tokens, codes, app secret, session ID


Authentication


Attacker may impersonate as victim


Authorization


Attacker can do whatever the
FooApp

can do on the IDP


Association


(user’s ID, user’s permission, session’s ID)


Model Checker & Modeling Language


Corral


Performs bounded verification on a C program with
embedded
assertions


Explores
all

possible execution path to check whether the
assertions can be violated


Boogie language


ASSERT(p)
: whenever the program gets to this line, p holds


ASSUME(p)
: assume p holds whenever the program gets
to this line


INVARIANT(p):
p always holds



If Boogie fails to prove an assertion or an invariant, it
reports a counter example

Modeling SDKs
---

Rewrite

PHP

Boogie

Modeling Underlying Systems


IDP’s

behaviors according to different input


Challenge: no source code


Solution:
fuzzing


Data processing on
client runtime


1. data redirection from one server to another


2. delivering data to
FooAppc


3. attaching cookies to outgoing request


Session, request and cookies on the
server side


Modeling Security Properties
---
Authentication


Whenever an attacker acquires a knowledge k

An
authentication violation
occurs when an attacker acquires
some knowledge that could be used to convince
FooAppS

that
the knowledge holder is Alice.

Modeling Security Properties
---
Authorization


Whenever an attacker acquires a Code c

An
authorization violation
occurs when an attacker acquires
some permission that allows him to do whatever the session
can do.

Asserts that Code c is not associated with Alice on
FooApp

Modeling Security Properties
---
Association

At the return point of every web API on
FooAppS
, we need to
ensure
the correct association
of the
user ID
, the
permission
, and
the
session

ID
.

Case Study #1: session hijacking

Session Variables:

_SESSION[‘
sessionid
’] = 0x01

Alice

FooAppS

Token

How
FooAppS

handles the token?

Session Variables:

_SESSION[‘
sessionid
’] = 0x01

_SESSION[‘
user_id
’] = Alice

Case Study: session hijacking

Session Variables:

_SESSION[‘
sessionid
’] = 0x01

_SESSION[‘
user_id
’] = Alice

Alice

FooAppS

Token

Session Variables:

_SESSION[‘
sessionid
’] = 0x02

0x02

Attack Using
Subdomains

Session Variables:

_SESSION[‘
sessionid
’] = 0x01

_SESSION[‘
user_id
’] = Alice

Alice

FooApp.heroku.com

0x02


Facebook’s

developer portal :
Heroku


Each service app runs in a
subdomain

under heroku.com

MalApp.heroku.com

Case Study #2: Wrong Association

Session Variables:

_SESSION[‘
access_token
’] = 0xabc

_SESSION[‘
user_id
’] = Alice

Attacker’s valid signed request

Attacker

Case Study #3: token leakage

http://facebook.com/logout.html?......&
access_token

=ao231rusd…

getAccessToken
()

getAccessToken
()

Secret shared between
FB and App

Secret shared among FB,
user and App

http://facebook.com/logout.html?......&
access_token

=ao231rusd…

Conclusion


This paper uses formal methods to identify the
underlying security assumptions form web
authentication/authorization.



Security of implementations relies on multiple
underlying assumptions.












Thank you!