Model-checking Driven Security Testing of Web-based Applications

wispxylopolistInternet and Web Development

Aug 7, 2012 (5 years and 8 days ago)

318 views



Model
-
checking Driven Security Testing of
Web
-
based Applications

Giancarlo Pellegrino

giancarlo.pellegrino@sap.com


A joint work with:





A. Armando
armando@dist.unige.it



R. Carbone
carbone@dist.unige.it



L.
Compagna

luca.compagna@sap.com



K. Li
kequi.li@sap.com




A ANTSSAR



International Workshop

on Modeling and Detection

of Vulnerabilities


April 10
th
, 2010

http://www.avantssar.eu/

©
SAP AG 2009. All rights reserved. / Page
2

Agenda

1.
Introduction

2.
A motivating example

3.
Model
-
checking driven security testing of web
-
base applications


Our approach


Automatic Test Sequence Generation


Automatic Test Execution Engine

4.
Assessment

5.
Conclusions

©
SAP AG 2009. All rights reserved. / Page
3

Introduction


A variety of techniques exists to unveil security flaws:


Automated reasoning techniques


Model
-
checking


Detect flaws in the logic of distributed applications, but


no support to test actual implementations


Security Testing


penetration testing


Detect low
-
level vulnerabilities on the actual system, but


heavily relies on the user’s expertise



but they are normally used in isolation



Our contribution:


Combines Model
-
Checking with Security Testing


Model
-
Checking Driven Security Testing of Web
-
based Applications!


Automatic test cases extraction and execution


Assessment on a real world use case


©
SAP AG 2009. All rights reserved. / Page
4

Case study: SAML
-
based SSO for G. Apps


Requirements:


Hospital takes advantage of web
-
based services to handle its basic IT services (email,
calendar, …)


Keeps the control of the identity management


Employees are authenticated once to access to these outsourced services


Solution:


SAML
-
based Single Sign
-
On

for Google Apps


Besides SP services

(i.e. Docs, Gmail, Calendar),

Google offers an

easy
-
to
-
be
-
deployed
IdP

service


©
SAP AG 2009. All rights reserved. / Page
5

SAML
Web Browser SSO profile: outline

Google Calendar

resource?

SP asks for my credentials

My credentials

Your credentials?

Here they are your credentials!

You can access to Google Calendar

if then

Doctor (C)

Hospita
l
(
IdP
)

Google (SP)

©
SAP AG 2009. All rights reserved. / Page
6

SAML SSO
vs

SAML
-
based SSO for G. Apps

…by Google

Doctor (C)

Hospita
l
(
IdP
)

Google (SP)

©
SAP AG 2009. All rights reserved. / Page
7

An abstract attack to SAML
-
based SSO for G.
Apps

Ref.

A. Armando, R. Carbone, L.
Compagna
, J. Cuellar and L.
Tobarra
. “
Formal Analysis of SAML 2.0 Web Browser Single
Sign
-
On: Breaking the SAML
-
based Single Sign
-
On for Google Apps
”.
October 27th, 2008


bob

idp

sp

Abstract attack found via model checking:

malicious

medical insurance

©
SAP AG 2009. All rights reserved. / Page
8

A real attack to SAML
-
based SSO for G. Apps

Video
:
http://www.ai
-
lab.it/armando/GoogleSSOVulnerability.html

Is the abstract attack applicable on the actual implementation?

©
SAP AG 2009. All rights reserved. / Page
9

Methodology applied so far

1.
Modeling phase:


An abstract model amenable for
formal analysis is specified

2.
Model Checking


Validate the abstract model


Returns an abstract counter
-
example

3.
Testing


Extraction of abstract messages
from the counter
-
example


Concrete messages are built and
sent to Google’s SP


Analysis of responses



Modeling

Model Checking

Informal Protocol Spec.

Counter
-
example

Test Result

Formal Specification

Test

©
SAP AG 2009. All rights reserved. / Page
10

Modeling

Our approach

Test Sequence

Generation

Model Checking

Test Execution

Engine

SUT

Informal Protocol Spec.

Counter
-
example

Test Sequence

Observation Point

Control Point

Test Result

Formal Specification

Message Mappings

1.
Modeling phase:


An abstract model amenable for
formal analysis is specified


Message Mappings

2.
Model Checking


Validate the abstract model


Returns an abstract counter
-
example

3.
Test Sequence Generation


Extract abstract test cases
sequence from the counter
-
example

4.
Test Execution Engine


Execute test cases sequence
against the SUT


Produce a verdict



©
SAP AG 2009. All rights reserved. / Page
11

Modeling

Test
Sequence

Generation

Model
Checking

Test
Execution

Engine

SUT

Informal Protocol Spec.

Counter
-
example

Test Sequence

Observation Point

Control Point

Test Result

Formal Specification

Message Mappings

Automatic Test Sequence Generation


System Under Testing: Google (sp);


Abstract counter
-
example found through Model Checking (MC):










Abstract test cases sequence:

S1. c
-
>
i

:
c.i.uri_i

A1.
i

-
> c :
c.idp.n.i.uri_i

A2. c
-
>
idp

:
c.idp.n.i.uri_i

S1.
i
(c)
-
> sp :
c.sp.uri_sp

A3.
idp

-
> c :
i
.{c.idp}_inv(
kidp
).
uri_i

A1. sp
-
> c :
c.idp.id.sp.uri_sp

A4. c
-
>
i

:
i
.{c.idp}_inv(
kidp
).
uri_i

A4.
i
(c)
-
> sp : sp.{c.idp}_inv(
kidp
).
uri_sp

S2. sp
-
> c :
resource.uri_sp

S1.
i
(c)
-
> sp :
c.sp.uri_sp

A1. sp
-
> c :
c.idp.id.sp.uri_sp

A4.
i
(c)
-
> sp : sp.{c.idp}_inv(
kidp
).
uri_sp

S2. sp
-
> c :
resource.uri_sp

Abstract message to probe
the SUT

Expected outputs from the
SUT

©
SAP AG 2009. All rights reserved. / Page
12

Automatic Test Execution Engine

Abstract level

Concrete level

Abstract

t
est
sequence

Message generation

Message abstraction

Test Execution Engine

SUT

Evaluation

Message checking

Modeling

Test
Sequence

Generation

Model
Checking

Test
Execution

Engine

SUT

Informal Protocol Spec.

Counter
-
example

Test Sequence

Observation Point

Control Point

Test Result

Formal Specification

Message Mappings

a
m

α
(a
m
)

β
(c
m
)

c
m

c
-
> sp :
c.sp.uri

HTTP/1.1 302 Moved Temporarily

Location: idp.com/?
SAMLRequest
=[…]

sp
-
> c :
c.idp.id.sp.uri

a"
m

Expected output of the SUT

a"
m

==
β
(c
m
) ?

GET object HTTP/1.1

Host: calendar.google.com […]

Observation Point

Control Point

©
SAP AG 2009. All rights reserved. / Page
13

Message Mappings Table

During the modeling phase:


A concrete message…







… is abstracted:




Mapping information and fields transformation are stored in 2 tables:


POST
SP
-
Endpoint

HTTP/1.1

Host:
SP
-
Domain

Content
-
Type: application/x
-
www
-
form
-
urlencoded

Content
-
Length: xyz


RelayState

=
UrlEncode
(
URIResource
)

&

SAMLResponse
=
AuthnResponse
(ID
R
, II
R
, S,


AuthAssertion
(ID
AA
,
IdP
, II
AA
, NB, NA, AI, C))

A4. C
-
> SP: SP.{
C.IdP
}_inv(
K_IdP
).URI

Concretization Mapping Table (CMT):

Abstraction Mapping Table (AMT):

f
1
(SP) = SP
-
Endpoint

f
2
(SP) = SP
-
Domain

f
3
(URI) =
URIResource

f
4
(
IdP
) =
IdP

f
5
(C) = C

h
1
(SP
-
EndPoint
) = SP

h
2
(SP
-
Domain) = SP

h
3
(
URIResource
) = URI

h
4
(
IdP
) =
IdP

h
5
(C) = C

Modeling

Test
Sequence

Generation

Model
Checking

Test
Execution

Engine

SUT

Informal Protocol Spec.

Counter
-
example

Test Sequence

Observation Point

Control Point

Test Result

Formal Specification

Message Mappings

©
SAP AG 2009. All rights reserved. / Page
14

Message Format Table

POST
$SP
-
EndPoint

HTTP/1.1

Host:
$SP
-
Domain

Content
-
Type: application/x
-
www
-
form
-
urlencoded

Content
-
Length: xyz


RelayState

=
#Encode(URL, $
URIResource
)

&

SAMLResponse
=

#Encode(BASE64
,



<
samlp:Response

[…] ID=
$ID_R



IssueInstant
=
$II_R

[…]>


<Signature […]> <
SignatureValue
>
$S
</
SignatureValue
> </Signature>


<Assertion […]>


<Issuer>
$
IdP
</Issuer>


<Subject><
NameID

[…]>
$C
</
NameID
></Subject>


<Conditions […]></Conditions>


<
AuthnStatement

AuthnInstant
=
$AI
>[…]</
AuthnStatement
>


</Assertion>


</
samlp:Response
>

)


For each concrete message a Message Format is created


Composed by: fixed structure,
field placeholders

and
directives














Stored in a table

Modeling

Test
Sequence

Generation

Model
Checking

Test
Execution

Engine

SUT

Informal Protocol Spec.

Counter
-
example

Test Sequence

Observation Point

Control Point

Test Result

Formal Specification

Message Mappings

©
SAP AG 2009. All rights reserved. / Page
15

Message Generation

Given an abstract message:

A4. c
-
> sp: sp.{c.idp}_inv(
k_idp
).
uri_sp

1) Look up for the message format:

POST
$SP
-
EndPoint

HTTP/1.1

Host:
$SP
-
Domain


RelayState

=
#Encode(URL, $
URIResource
)

&

SAMLResponse
=
#Encode(BASE64
,



<
samlp:Response

[…] ID=
$ID_R
IssueInstant
=
$II_R

[…]><Assertion […]>


<Issuer>
$
IdP
</Issuer><Subject><
NameID

[…]>
$C
</
NameID
></Subject>


<Conditions […]></Conditions><
AuthnStatement

AuthnInstant
=
$AI
>[…]


</
AuthnStatement
> </Assertion></
samlp:Response
>

)

POST endpoint/ HTTP/1.1

Host: calendar.google.com

[…]

2) Substitution of field placeholders according to CMT:

3) Substitution of other fields (calculated at runtime such as timestamps):

[…] <
AuthnStatement

AuthnInstant
=‘2009
-
05
-
07T13:36:35Z’>[…]</
AuthnStatement
>[…]

4) Directives computation:

[…]
RelayState

= https%3A%2F%2Fcalendar.google.com […]

f
1
(sp) = endpoint/

f
2
(sp) = calendar.google.com

Modeling

Test
Sequence

Generation

Model
Checking

Test
Execution

Engine

SUT

Informal Protocol Spec.

Counter
-
example

Test Sequence

Observation Point

Control Point

Test Result

Formal Specification

Message Mappings

©
SAP AG 2009. All rights reserved. / Page
16

Message Abstraction

Given a concrete message:

POST
endpoint/

HTTP/1.1

Host:
calendar.google.com

Content
-
Type: application/x
-
www
-
form
-
urlencoded

Content
-
Length: xyz


RelayState

=
UrlEncode
(
https://calendar.google.com
) &

SAMLResponse
=
AuthnResponse
(…,
AuthAssertion
(…,
idp.ai
-
lab.it, …, username
))

2) Parsing of the incoming message:

SP
-
EndPoint

= endpoint/

SP
-
Domain = calendar.google.com

URIResource

= https://calendar.google.com

IdP

= idp.ai
-
lab.it

C = username

3) Calculation of abstract value according to the AMT:

h
1
(“
endpoint/”) = sp

h
2
(“
calendar.google.com”) = sp

h
3
(“
https://calendar.google.com”) =
uri_sp

h
4
(“
idp.ai
-
lab.it”) =
idp

h
5
(“
username”) = c

1) Look up for the message format:

POST
$SP
-
EndPoint

HTTP/1.1

Host:
$SP
-
Domain


RelayState

=
#Encode(URL, $
URIResource
)

&

SAMLResponse
=
#Encode(BASE64
,

<
samlp:Response

[…] ID=
$ID_R
IssueInstant
=
$II_R

[…]>

Modeling

Test
Sequence

Generation

Model
Checking

Test
Execution

Engine

SUT

Informal Protocol Spec.

Counter
-
example

Test Sequence

Observation Point

Control Point

Test Result

Formal Specification

Message Mappings

©
SAP AG 2009. All rights reserved. / Page
17

Assessment


Since the flawed version of SAML
-
based
SSO for Google Apps is no longer available


Google has fixed it in Sept. 2008



We assessed our approach by comparing
the HTTP messages generated with the
ones captured previously


Outgoing messages were equivalent


We concluded that our system would
have been able to detect the flaw

Modeling

Test Sequence

Generation

Model Checking

Test Execution

Engine

Informal Protocol Spec.

Counter
-
example

Test Sequence

Observation Point

Control Point

Test Result

Formal Specification

Message Mappings

Store

©
SAP AG 2009. All rights reserved. / Page
18

Modeling

Conclusions

Test Sequence

Generation

Model Checking

Test Execution

Engine

SUT

Informal Protocol Spec.

Counter
-
example

Test Sequence

Observation Point

Control Point

Test Result

Formal Specification

Message Mappings



Proposed a methodology which combines
Model
-
checking with Security Testing


It check whether security vulnerabilities
discovered at model level affect actual
implementations



It relates abstract to concrete levels (and
the other way around) in a systematic way



Automatically derives and executes test
cases



It is protocol independent and could be
applied generally to any web
-
based
security protocol



Thank you

More info

©
SAP AG 2009. All rights reserved. / Page
22

Case study: SAML
-
based
SSO
for G. Apps

A. Johnson, CIO of the San Francisco Bay Pediatrics said:


When it comes to our email systems, our doctors don’t have
the time or the budgets to deal with managing technology or
defending against spam [..]


With Google Apps Premier Edition we don’t have to worry
about downloading the latest spam filters or navigating
unwieldy servers. This is where we let Google do what it does
best, so we can do what we do best


help our patients.



http://www.google.com/intl/en/press/pressrel/google_apps.html

©
SAP AG 2009. All rights reserved. / Page
23

The complete story

August, 2006

Google
launched
Google Apps as
a free service

February, 22 2007

Google introduced
Google Apps
Premier Edition
($50 per account
per year) including
SSO

April, 2008

AVANTSSAR
discovers a flaw in
the SAML
-
based
SSO for Google
Apps

May, 2008

AVANTSSAR
has notified
Google about
the vulnerability

July, 2 2008

Google informed
their customer that
they

discovered a
vulnerability attack
and that they
patched it


All the customers
are invited to
update the
software

September, 2008

Google has
updated its API to
fix the flaw
discovered by
AVANTSSAR