Secure Compilation of a Multi-Tier Web Language (Semantics Lunch)

The Links Multi-Tier Programming LanguageSource-Based Reasoning for Links

Standard and Secure SemanticsReferences

Secure Compilation of a Multi-Tier Web Language

Ioannis G. Baltopoulos([email protected])

Computer Laboratory

Joint work with Andrew D. Gordon from Microsoft ResearchTo appear in TLDI ’09

Semantics Lunch - Monday, December 8, 2008

Ioannis G. Baltopoulos Secure Compilation of a Multi-Tier Web Language



Web Programming Languages - Issues

Nobody would question the success of the web, but people doquestion the need for so many web programming languages.

One must be well versed in multiple languages to writeeven trivial applications.

Impedance mismatch [Meijer et al., 2003]The data exchanged between the different tiers of the sameapplication often comes in incompatible shapes and formats.

Security reviewsThey require detailed knowledge ofthe language on each tier.




Multi-Tier Languages - A solution

Multi-tier programming language. A high-level webprogramming language that compiles to code, split between eachof the tiers of a web application.

Links is a strongly typed,multi-tier, functionalprogramming language for theweb [Cooper et al., 2006];

HOP [Serrano et al., 2006] is aScheme-based language forcreating interactive applicationsacross the web;

Hilda, ML5, GWT, LINQ.




Principle of Source-Based Reasoning

To say a language is high-level means that it supports aprogramming model that abstracts from the details of thelower-level code to which the language is compiled.

Links in particular abstracts from the details of JavaScriptand SQL and supports a high-level model based oncall-by-value functional programming with XML literals.

Security is an aspect of correctness, so high-level languagesshould allow security reasoning in terms of the abstractprogramming model.

Principle of Source-Based Reasoning. Security properties ofcompiled code should follow from review of the source code and itssource-level semantics.




This talk

Motivation: In the context of programming languages thatimplement continuations on the client side using either cookies orhidden fields, the continuations are open to client manipulation.

Objective: Allow security reasoning about multi-tier programs atthe source level. We are studying specific anomalies, such as thosearising from storing state in untrusted clients, and seekingcountermeasures.

Solution: We propose to apply authenticated encryption toclosures to fix these problems. Authenticated encryption is acombination of secrecy and integrity protection where we initiallyhash the data and subsequently encrypt the data itself along withthe hash.




Outline

1 The Links Multi-Tier Programming Language

2 Source-Based Reasoning for Links

3 Standard and Secure Semantics




The HTTP protocol (review)

The HyperText Transfer Protocol (HTTP) is a stateless,request-response protocol that uses a client-server model.

The GET method instructs the browser to retrieve theresource associated with the URI; its production should causeno side-effects. In the case of a dynamic resource anadditional query string contains data to be passed to the webapplication.

The POST method is used to send data to the server,potentially updating server state.




The Edinburgh Links implementation

Links is a simply-typed, call-by-value λ-calculus with XML valuesfor representing web pages.

The Links system is called as a CGI program, to process anHTTP request and produce an XML response.

A user executes the program by entering its URL; thiscorresponds to a GET request with no query string.

A user can click on a link; this corresponds to a GET requestwith a query string.

A user can fill in a form and submit it; this corresponds to aPOST request.

Suspended expressions inside XML pages are transformed,along with their environment bindings, into a continuationstring.




A Simple Web Application: Sale

fun buy(value, dbpass) server {intToXml(value) # omitting actual call to the database

}fun sellAt(price) server {

var dbpass = "secret";<form l:onsubmit="{buy(price,dbpass)}" method="POST">

<button type="submit">Buy</button></form>

}sellAt(42)




An attack on secrecy and integrity

We will now demonstrate an attack on the sale program.

Demo




So what went wrong?

The expressions that are to be evaluated as a result of clickingbuttons or reference links are encoded, along with theirnecessary surrounding context, into a continuation string.

For example, the expression buy(price,dbpass) along withthe environment env = {price 7→ 42, dbpass 7→ ”secret”} gotencoded into

EPY5uxEAquKhp4g-aOicyAQBBXByaWNlBgECNDI=

The one that I used for the hack was the same expressionunder the environment bindingenv = {price 7→ 10, dbpass 7→ ”secret”} which was encodedinto

EPY5uxEAquKhp4g-aOicyAQBBXByaWNlBgECMTA=




Failures of Source-Based Reasoning

1 The client may learn secret data that is held in a closureembedded in a web page; for example, they may learn serverdata such as a password.

2 The client may break the integrity of server data bymodifying a closure embedded in a web page so as to changefuture behaviour of the application; for example, the clientmay change the price of an item in a shopping cart.

3 The client may change the control flow of the program bydiscovering an unreachable function held in one closure, andthen modifying a function value held in another closure.




Outline







Threat model

In what follows we assume:

An untrustworthy client browser controlled by the attacker,who may run software to capture, decode, and modify webpages received from the server.

That transport layer security (SSL/TLS) protects againstattacks by a third party.

That the source code of both the application program and theLinks system itself are public (and hence implementationmechanisms such as encoding formats are known to theattacker).

We only consider Links programs that keep no mutable state in adatabase, and where all functions reside on the server.




Formalisation

1 We define a formal semantics for an extended fragment whichwe call TinyLinks, and develop a type-and-effect systemthat allows source level reasoning about integrity.

2 We then develop a translation of type correct programs to aconcurrent λ-calculus with refinement types and formalcryptography (F7).




Values of TinyLinks:

f , y , x Variablesp Predicate symbolc ::= Data type constructor

Unit | Zero | Succ | String unit, integers, stringNil | Cons | Tuple list, tupleElem | Text HTML constructors

g ::= + | − | intToXml | . . . Primitive functionsL ::= p(V1, . . . ,Vn) Event: tag p with a list of valuesV ,U ::= Value

x variablec(V1, . . . ,Vn) constructorλx1, . . . , xn.E abstractionhref (E ) linkform ([ℓ1, . . . , ℓn],E ) form




Links and forms

An href value represents a link which, when clicked,evaluates the suspended expression E . The evaluation requestfor the expression is implemented using a GET message.

A form value represents an HTML form with a suspendedcomputation that requires additional user input to proceed.The labels represent the available input fields a client canprovide or modify, both visible and hidden. The evaluationrequest for a form is implemented using a POST message.




Expressions of TinyLinks:

E ::= ExpressionV value(E :W ) type-and-effect annotationvar x = E1;E2 variable bindingg(U1, . . . ,Un) primitive applicationV (U1, . . . ,Un) function applicationswitch (V ) {

case c(x1, . . . , xn) → E1

case → E2

}

pattern matching

get (V ) get requestpost ((li = Vi)

i∈1..n,U) post requestevent L mark an eventassert L assertion of a prior event




Modelling browsing behaviour

We have included get and post expressions within TinyLinks

so we may formally express the browsing behaviour of users asTinyLinks expressions.Let a client be any expression context Eclient within TinyLinks

containing a hole of the form href (−).

The value href (Eurl ) represents a link to the main page ofthe web application Eurl .The expression Eclient [Eurl ] obtained by filling the hole inEclient with Eurl is a formal representation of the client Eclient

browsing the web application Eurl .

We thus reduce source-based reasoning about the securityproperties of a web application Eurl to a formal question: for allclient contexts Eclient , does Eclient [Eurl ] enjoy the intendedproperty?




Correspondence assertions

The annotations assert L and event L have nocomputational significance, and are included in TinyLinks

simply to express certain safety properties.

We say an expression is safe to mean that whenever anassertion assert L occurs in an execution, there is a previousoccurrence within the execution of an event event L.

Such properties are known as (non-injective) correspondences[Woo and Lam, 1993], and are widely used for specifyingintegrity properties of security mechanisms [Gollmann, 2003].




A Type-and-Effect system

Inspired by a simple system for typing correspondences in aprocess calculus.

A type describes a value, and a type-and-effect describes anexpression.

The rules are in bidirectional style [Pierce and Turner, 1998]and correspond directly to our implementation.




Syntax of Types, Effects, and Environments:

F ::= L1, . . . ,Lm Effect: a set of eventsW ::= 〈x :T 〉{F} (monadic) Type-and-EffectP ::= 〈x1:T1 . . . xn:Tn〉{F} polyadic Type-and-EffectB ::= unit | int | string | xml Base TypesS ,T ,H ::= Types

B base type[T ] listT1 × · · · × Tn tupleP → W polyadic function

Γ ::= x1:T1, . . . , xn:Tn Environmentdom(x1:T1, . . . , xn:Tn) = {x1, . . . , xn}




Judgments:

Γ ⊢ ⋄ Γ is well-formed

Γ;F ⊢ Vval T value V synthesises output type T

Γ;F ⊢ Vval T value V type-checks against input T

Γ;F ⊢ Eexp W expression E synthesises output W

Γ;F ⊢ Eexp W expression E type-checks against input W

Assigning a type-and-effect W = 〈x :T 〉{F ′} to an expressionmeans that:

assuming that the set of events in T have occurred,evaluation of the expression is safe;

the effect F is a precondition, a set of events assumed to haveoccurred before execution;

the effect F ′ is a postcondition, a set of events safe to assumeafter execution.




Algorithmic Typing Rules for Values (partial):

(T-Abs)

Γ, x1:T1 . . . xn:Tn;F ,F1 ⊢ Eexp W

T = 〈x1:T1 . . . xn:Tn〉{F1} → W

Γ;F ⊢ (λx1, . . . , xn.E )val T

x1, . . . , xn /∈ fv(F ), T closed

(T-Swap)

Γ;F ⊢ Vval T

Γ;F ⊢ Vval T

(T-Href)

Γ;F ⊢ Eexp ( : xml ) {}

Γ;F ⊢ href (E )val xml

(T-Form)

Γ, ℓ1:string , . . . , ℓn:string ;F ⊢ Eexp ( : xml ) {}

Γ;F ⊢ (form ([ℓ1, . . . , ℓn],E ))val xml

ℓ1 . . . ℓn /∈ fv(F )




Algorithmic Rules for Expressions (partial)

(T-App)

Γ;F ⊢ Uval T T = 〈x1:T1 . . . xn:Tn〉{F1} → W T closed

Γ;F ⊢ Vival Ti ∀i ∈ 1..n F1[V1/x1] . . . [Vn/xn] ⊆ F

Γ;F ⊢ U(V1, . . . ,Vn)exp W [V1/x1] . . . [Vn/xn]

(T-Assert)Γ ⊢ ⋄ fv(F ,L) ⊆ dom(Γ) L ∈ F

L = p(V1, . . . ,Vn) Γ;F ⊢ Vival Ti ∀i ∈ 1..n

Γ;F ⊢ assert Lexp 〈 :unit 〉{L}

(T-Event)Γ ⊢ ⋄ fv(F ,L) ⊆ dom(Γ)

L = p(V1, . . . ,Vn) Γ;F ⊢ Vival Ti ∀i ∈ 1..n

Γ;F ⊢ event Lexp 〈 :unit 〉{L}




Provable safety

Definition

A web application Eurl is provably safe if and only if there is aproof within the type-and-effect system of the judgment∅; ∅ ⊢ Eurl

exp ( : xml ) {}.

The idea is that a web application is a closed expression that yieldsa page of type xml , and that no assert involved in creating thispage, or any subsequent page, may fail.




Data Integrity with Assertions: Sale

sig buy : <value:int, dbpass:string>{PriceIs(value)} →<r:xml>{}fun buy(value,dbpass) server {

assert PriceIs(value);intToXml(value) # omitting actual call to the database

}sig sellAt: <price:int>{} →<r:xml>{}fun sellAt(price) server {

var dbpass = "secret";event PriceIs(price);<form l:onsubmit="{buy(price,dbpass)}" method="POST">

<button type="submit">Buy</button></form>

}sellAt(42)




Outline







Semantics

1 We use a concurrent λ-calculus (RCF) with refinement types,and its implementation in the practical typechecker F7

2 A server implementing TinyLinks is modelled as a functionfrom HTTP requests to XML responses in F7.

3 We give a semantics for the standard implementation ofLinks by translating a provably safe TinyLinks webapplication Eurl to an F7 expression [[Eurl ]].

4 We describe our secure implementation strategy as a simplemodification of the standard implementation.




Translation algorithm

Throughout the two translations, we consider some fixed well-typedTinyLinks expression Eurl , and a structure W = (Eurl ,J ,H).

The first step is to perform type-directed closure conversion onall the λ-abstractions, forms and links occurring in the sourceand generate suitable datatypes for representing them in F7.Generate mutually recursive function listeners (fHj); eachcorresponding to the closures that were generated previously.Finally, translate the top level web server listener.

Translation from Eurl in TinyLinks to [[Eurl ]] in F7:

Let [[Eurl ]]be the F7 module obtained from Eurl by concatenating thetype and function definitions: (M1) fixed datatypes; (M2) gener-ated datatypes; (M3) generated functions; (M4) toplevel webserverfunction.




A Datatype for the Web

(M1) Types for HTTP, XHTML, and Web Applications:

type (’g, ’p) req =| Get of ’g option| Post of ’p ∗ string list

type (’g, ’p) xml =| Elem of string ∗ (’g, ’p) xml list| Text of string| Href of ’g| FormElem of ’p ∗ string list

type (’g, ’p) webapp = (’g, ’p) req → (’g, ’p) xml




Translation of types and values

The translation rules for types are mostly structural. The followingtwo cases are of interest:

[[xml ]]= (linkclos , formclos )xml

[[P → W ]]= funclos P→W

Similarly for values the interesting cases are generating theclosures:

[[(λx1, . . . , xn.E )]]= C[[λx1, . . . , xn.E ]]

[[href (E )]]= Href ( C[[href (E )]] )

[[form ([ℓ1, . . . , ℓn],E )]]=FormElem (C[[form ([ℓ1, . . . , ℓn],E )]], [ℓ1, . . . , ℓn])

C[[V ]] = HJ ((x1, . . . , xn)) forJ = ((xi :Ui)

i∈1..n,F ,V ,T ) ∧ J ∈ J




(M2) Generated datatypes:

type funclos P→W =∑

{

HJ of [[Γ;F ]]| J = (Γ,F , (λx1, . . . , xn.E ),P → W ) ∧ J ∈ J

}

and formclos =∑

{

HJ of [[Γ;F ]]| J = (Γ,F , form ([ℓ1, . . . , ℓm],E ), xml ) ∧ J ∈ J

}

and linkclos =∑

{

(HJ of [[Γ;F ]])| J = (Γ,F ,href (E ), xml ) ∧ J ∈ J

}

where [[Γ;F ]]= (x1: [[T1]]∗ · · · ∗ xn: [[Tn]]){F} if Γ = x1:T1, . . . , xn:Tn.




(M3) Generated Functions:

fHJ :[[

(xi :Ui)i∈1..n;F

]]

→ [[P ]]→ [[W ]]let rec fHJ g y =

match g with (x1, . . . , xn) →match y with (y1, . . . , yn) → E [[E ]]where J = ((xi :Ui)

i∈1..n,F , λx1, . . . , xn.E ,P → W ) and J ∈ J

fHJ :[[

(xi :Ui)i∈1..n;F

]]

→ xmland fHJ g = match g with (x1, . . . , xn) → E [[E ]]

where J = ((xi :Ui)i∈1..n,F ,href (E ), xml ) and J ∈ J

fHJ :[[

(xi :Ui)i∈1..n;F

]]

→ string list → xmland fHJ g ls =

match g with (x1, . . . , xn) →match ls with [ℓ1; . . . ; ℓn] → E [[E ]]where J = ((xi :Ui)

i∈1..n,F , form ([ℓ1, . . . , ℓn],E ), xml ) and J ∈ J




(M4) Top Level Web Server Listener:

and webserver req : (linkclos , formclos )webapp =match req with| Get (None ) → E [[Eurl ]]| Get (Some (l)) →

match l with∏

J∈J∧J=(Γ,F ,href (E),T )

(| HJ(g) → fHJ g)

| Post (clos , ls ) →match clos , ls with

∏

J∈J∧J=(Γ,F ,form ([ℓ1,...,ℓn],E),T )

(

| HJ (g), [ℓ1; . . . ; ℓn] →fHJ g [ℓ1; . . . ; ℓn]

)




Translation from Eurl in TinyLinks to [[Eurl ]] in F7:

Let [[Eurl ]] be the F7 module obtained from Eurl by concatenatingthe type and function definitions displayed previously: (M1) fixeddatatypes; (M2) generated datatypes; (M3) generated functions;(M4) toplevel webserver function. Let the interface of the modulebe: val webserver : (linkclos , formclos )webapp .

Lemma

If Eurl is provably safe then [[Eurl ]] is a closed expression of F7 oftype: [[Eurl ]]:(linkclos , formclos )webapp .

Theorem

If Eurl is provably safe at the source level, then the (standard)webserver [[Eurl ]] is safe.




Robust safety in F7

Let an opponent be an arbitrary F7 expression context. We say anF7 expression is robustly safe if it is safe whenever it is placedwithin any opponent context.

A significant result concerning F7 is the robust-safety-by-typingtheorem: that a closed well-typed expression is robustly safe,provided its type satisfies conditions for being public.

In particular, the function type (linkclos,formclos)webapp is notpublic, because of the refinements on types for the constructors HJ

of linkclos and formclos .




The make and check functions construct and deconstruct theauthenticated encryption of a continuation.We use different keys for hashing and encrypting; in total there arefour keys used for hashing links and forms, and for encrypting linksand forms respectively.

Modifications for the Secure Translation: [[Eurl ]]s

[[xml ]]s = (cipher , cipher )xml

[[href (E )]]s =let ciph = make lkSKey lkHKey (C[[href (E )]]s) in Href ( ciph )

[[form ([ℓ1, . . . , ℓn], E )]]s =let ciph = make fSKey fHKey ( C[[form ([ℓ1, . . . , ℓn], E )]]s ) inFormElem (ciph , [ℓ1, . . . , ℓn])




Modifications for the Secure Top-Level Listener

let webserver (req : (cipher , cipher )req ) → (cipher , cipher )xml =match req with| Get (None ) → E [[Eurl ]]s| Get (Some (ciph )) →

match (check lSKey HKey ciph ) with∏

J∈J∧J=(Γ,F ,href (E),T )

(| HJ(g) → fHJ g)

| Post (ciph , ls ) →match (check fSKey fHKey ciph ), ls with

∏

J∈J∧J=(Γ,F ,form ([ℓ1,...,ℓn],E),T )

(

| HJ(g), [ℓ1; . . . ; ℓn] →fHJ g [ℓ1; . . . ; ℓn]

)

The function type (cipher,cipher)webapp is public, because there are no

refinement types in its argument type.




Our main theorem is a corollary, given the robust-safety-by-typingtheorem of F7, of Lemma 2.

Lemma

Suppose that ∅; ∅ ⊢ Eurlexp ( : xml ) {}. Then [[Eurl ]]s is a closed

expression of F7 of type: [[Eurl ]]:(cipher , cipher )webapp .

Theorem

If Eurl is provably safe at the source level, then the (secure)webserver [[Eurl ]]s is robustly safe.




Summary

We have obtained practical and theoretical resultsdemonstrating that it is possible to perform source-basedsecurity analysis in a multi-tier web programming language.To further validate our approach, we have implemented botha type-and-effect checker and our secure translation producingexecutable semantics in F#, that can form part of a certifiedweb server.What about state?What about concurrency?Fully distributed implementation?

http://www.cl.cam.ac.uk/~ib249/

Thank you!Ioannis G. Baltopoulos Secure Compilation of a Multi-Tier Web Language

http://www.cl.cam.ac.uk/~ib249/



Bibliography

E. Cooper, S. Lindley, P. Wadler, and J. Yallop. Links: WebProgramming Without Tiers. In FMCO: Proceedings of 5thInternational Symposium on Formal Methods for Componentsand Objects, LNCS. Springer-Verlag, 2006.

D. Gollmann. Authentication by correspondence. IEEE Journal onSelected Areas in Communication, 21(1):88–95, 2003.

E. Meijer, W. Schulte, and G. Bierman. Programming with circles,triangles and rectangles. In XML Conference, 2003.

B. C. Pierce and D. N. Turner. Local type inference. In ACMSymposium on Principles of Programming Languages(POPL’98), pages 252–265, 1998.

M. Serrano, E. Gallesio, and F. Loitsch. Hop: a language forprogramming the web 2.0. In OOPSLA ’06: Companion to the21st ACM SIGPLAN symposium on Object-orientedprogramming systems, languages, and applications, pagesIoannis G. Baltopoulos Secure Compilation of a Multi-Tier Web Language

Technology

Secure Compilation of a Multi-Tier Web Language (Semantics Lunch)