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

The Links Multi-Tier Programming Language
Source-Based Reasoning for Links
Standard and Secure Semantics
References

Secure Compilation of a Multi-Tier Web Language

Ioannis G. Baltopoulos
(ioannis.baltopoulos@cl.cam.ac.uk)

Computer Laboratory

Joint work with Andrew D. Gordon from Microsoft Research
To appear in TLDI ’09
Semantics Lunch - Monday, December 8, 2008

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

References

Web Programming Languages - Issues

Nobody would question the success of the web, but people do
question the need for so many web programming languages.
One must be well versed in multiple languages to write
even trivial applications.
Impedance mismatch [Meijer et al., 2003]
The data exchanged between the diﬀerent tiers of the same
application often comes in incompatible shapes and formats.
Security reviews
They require detailed knowledge of
the language on each tier.


References

Multi-Tier Languages - A solution

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

Links is a strongly typed,
multi-tier, functional
programming language for the
web [Cooper et al., 2006];
HOP [Serrano et al., 2006] is a
Scheme-based language for
creating interactive applications
across the web;
Hilda, ML5, GWT, LINQ.

References

Principle of Source-Based Reasoning

To say a language is high-level means that it supports a
programming model that abstracts from the details of the
lower-level code to which the language is compiled.
Links in particular abstracts from the details of JavaScript
and SQL and supports a high-level model based on
call-by-value functional programming with XML literals.
Security is an aspect of correctness, so high-level languages
should allow security reasoning in terms of the abstract
programming model.
Principle of Source-Based Reasoning. Security properties of
compiled code should follow from review of the source code and its
source-level semantics.


References

This talk

Motivation: In the context of programming languages that
implement continuations on the client side using either cookies or
hidden fields, the continuations are open to client manipulation.

Objective: Allow security reasoning about multi-tier programs at
the source level. We are studying specific anomalies, such as those
arising from storing state in untrusted clients, and seeking
countermeasures.

Solution: We propose to apply authenticated encryption to
closures to fix these problems. Authenticated encryption is a
combination of secrecy and integrity protection where we initially
hash the data and subsequently encrypt the data itself along with
the hash.


References

Outline

1

2

3


References

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 the
resource associated with the URI; its production should cause
no side-eﬀects. In the case of a dynamic resource an
additional query string contains data to be passed to the web
application.
The POST method is used to send data to the server,
potentially updating server state.


References

The Edinburgh Links implementation

Links is a simply-typed, call-by-value λ-calculus with XML values
for representing web pages.
The Links system is called as a CGI program, to process an
HTTP request and produce an XML response.
A user executes the program by entering its URL; this
corresponds to a GET request with no query string.
A user can click on a link; this corresponds to a GET request
with a query string.
A user can ﬁll in a form and submit it; this corresponds to a
POST request.
Suspended expressions inside XML pages are transformed,
along with their environment bindings, into a continuation
string.

References

A Simple Web Application: Sale

fun buy(value, dbpass) server {
intToXml(value) # omitting actual call to the database
}
fun sellAt(price) server {
var dbpass = quot;secretquot;;
<form l:onsubmit=quot;{buy(price,dbpass)}quot; method=quot;POSTquot;>
<button type=quot;submitquot;>Buy</button>
</form>
}
sellAt(42)


References

An attack on secrecy and integrity

We will now demonstrate an attack on the sale program.

Demo


References

So what went wrong?

The expressions that are to be evaluated as a result of clicking
buttons or reference links are encoded, along with their
necessary surrounding context, into a continuation string.
For example, the expression buy(price,dbpass) along with
the environment env = {price → 42, dbpass → ”secret”} got
encoded into
EPY5uxEAquKhp4g-aOicyAQBBXByaWNlBgECNDI=
The one that I used for the hack was the same expression
under the environment binding
env = {price → 10, dbpass → ”secret”} which was encoded
into
EPY5uxEAquKhp4g-aOicyAQBBXByaWNlBgECMTA=

References

Failures of Source-Based Reasoning

The client may learn secret data that is held in a closure
1

embedded in a web page; for example, they may learn server
data such as a password.
The client may break the integrity of server data by
2

modifying a closure embedded in a web page so as to change
future behaviour of the application; for example, the client
may change the price of an item in a shopping cart.
The client may change the control ﬂow of the program by
3

discovering an unreachable function held in one closure, and
then modifying a function value held in another closure.


References

Threat model

In what follows we assume:
An untrustworthy client browser controlled by the attacker,
who may run software to capture, decode, and modify web
pages received from the server.
That transport layer security (SSL/TLS) protects against
attacks by a third party.
That the source code of both the application program and the
Links system itself are public (and hence implementation
mechanisms such as encoding formats are known to the
attacker).
We only consider Links programs that keep no mutable state in a
database, and where all functions reside on the server.


References

Formalisation

We define a formal semantics for an extended fragment which
1

we call TinyLinks, and develop a type-and-effect system
that allows source level reasoning about integrity.
We then develop a translation of type correct programs to a
2

concurrent λ-calculus with refinement types and formal
cryptography (F7).


References

Values of TinyLinks:
f , y, x Variables
p Predicate symbol
c ::= Data type constructor
Unit | Zero | Succ | String unit, integers, string
Nil | Cons | Tuple list, tuple
Elem | Text HTML constructors
g ::= + | − | intToXml | . . . Primitive functions
L ::= p(V1 , . . . , Vn ) Event: tag p with a list of values
V , U ::= Value
x variable
c(V1 , . . . , Vn ) constructor
λx1 , . . . , xn .E abstraction
href (E ) link
form ([ℓ1 , . . . , ℓn ], E ) form


References

Links and forms

An href value represents a link which, when clicked,
evaluates the suspended expression E . The evaluation request
for the expression is implemented using a GET message.
A form value represents an HTML form with a suspended
computation that requires additional user input to proceed.
The labels represent the available input ﬁelds a client can
provide or modify, both visible and hidden. The evaluation
request for a form is implemented using a POST message.


References

Expressions of TinyLinks:
E ::= Expression
V value
(E :W ) type-and-eﬀect annotation
var x = E1 ; E2 variable binding
g (U1 , . . . , Un ) primitive application
V (U1 , . . . , Un ) function application
switch (V ) {
case c(x1 , . . . , xn ) → E1
pattern matching
case → E2
}
get (V ) get request
post ((li = Vi )i ∈1..n , U) post request
event L mark an event
assert L assertion of a prior event


References

Modelling browsing behaviour

We have included get and post expressions within TinyLinks
so we may formally express the browsing behaviour of users as
TinyLinks 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 of
the web application Eurl .
The expression Eclient [Eurl ] obtained by ﬁlling the hole in
Eclient with Eurl is a formal representation of the client Eclient
browsing the web application Eurl .
We thus reduce source-based reasoning about the security
properties of a web application Eurl to a formal question: for all
client contexts Eclient , does Eclient [Eurl ] enjoy the intended
property?

References

Correspondence assertions

The annotations assert L and event L have no
computational signiﬁcance, and are included in TinyLinks
simply to express certain safety properties.
We say an expression is safe to mean that whenever an
assertion assert L occurs in an execution, there is a previous
occurrence 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 specifying
integrity properties of security mechanisms [Gollmann, 2003].


References

A Type-and-Eﬀect system

Inspired by a simple system for typing correspondences in a
process calculus.
A type describes a value, and a type-and-eﬀect describes an
expression.
The rules are in bidirectional style [Pierce and Turner, 1998]
and correspond directly to our implementation.


References

Syntax of Types, Effects, and Environments:
F ::= L1 , . . . , Lm Effect: a set of events
W ::= x:T {F } (monadic) Type-and-Effect
P ::= x1 :T1 . . . xn :Tn {F } polyadic Type-and-Effect
B ::= unit | int | string | xml Base Types
S, T , H ::= Types
B base type
[T ] list
T1 × · · · × Tn tuple
P →W polyadic function
Γ ::= x1 :T1 , . . . , xn :Tn Environment
dom(x1 :T1 , . . . , xn :Tn ) = {x1 , . . . , xn }


References

Judgments:
Γ⊢⋄ Γ is well-formed
val
Γ; F ⊢ V T value V synthesises output type T
val
Γ; F ⊢ V T value V type-checks against input T
exp
Γ; F ⊢ E W expression E synthesises output W
exp
Γ; F ⊢ E W expression E type-checks against input W

Assigning a type-and-effect W = x:T {F ′ } to an expression
means 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 have
occurred before execution;
the effect F ′ is a postcondition, a set of events safe to assume
after execution.

References

Algorithmic Typing Rules for Values (partial):
(T-Abs)
exp
Γ, x1 :T1 . . . xn :Tn ; F , F1 ⊢ E W
T = x1 :T1 . . . xn :Tn {F1 } → W x1 , . . . , xn ∈ fv(F ), T closed
/
val
Γ; F ⊢ (λx1 , . . . , xn .E ) T

(T-Swap) (T-Href)
exp
val
Γ; F ⊢ E ( : xml ) {}
Γ; F ⊢ V T
val
val
Γ; F ⊢ href (E ) xml
Γ; F ⊢ V T

(T-Form)
exp
Γ, ℓ1 :string , . . . , ℓn :string ; F ⊢ E ( : xml ) {}
ℓ1 . . . ℓn ∈ fv(F )
/
val
Γ; F ⊢ (form ([ℓ1 , . . . , ℓn ], E )) xml


References

Algorithmic Rules for Expressions (partial)
(T-App)
val
Γ; F ⊢ U T T = x1 :T1 . . . xn :Tn {F1 } → W T closed
val
Γ; F ⊢ Vi Ti ∀i ∈ 1..n F1 [V1 /x1 ] . . . [Vn /xn ] ⊆ F
exp
Γ; F ⊢ U(V1 , . . . , Vn ) W [V1 /x1 ] . . . [Vn /xn ]

(T-Assert)
Γ ⊢ ⋄ fv(F , L) ⊆ dom(Γ) L ∈ F
val
L = p(V1 , . . . , Vn ) Γ; F ⊢ Vi Ti ∀i ∈ 1..n
exp
Γ; F ⊢ assert L :unit {L}

(T-Event)
Γ ⊢ ⋄ fv(F , L) ⊆ dom(Γ)
val
L = p(V1 , . . . , Vn ) Γ; F ⊢ Vi Ti ∀i ∈ 1..n
exp
Γ; F ⊢ event L :unit {L}

References

Provable safety

Deﬁnition
A web application Eurl is provably safe if and only if there is a
proof within the type-and-eﬀect system of the judgment
exp
∅; ∅ ⊢ Eurl ( : xml ) {}.

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


References

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 = quot;secretquot;;
event PriceIs(price);
<form l:onsubmit=quot;{buy(price,dbpass)}quot; method=quot;POSTquot;>
<button type=quot;submitquot;>Buy</button>
</form>
}
sellAt(42)


References

Semantics

We use a concurrent λ-calculus (RCF) with reﬁnement types,
1

and its implementation in the practical typechecker F7
A server implementing TinyLinks is modelled as a function
2

from HTTP requests to XML responses in F7.
We give a semantics for the standard implementation of
3

Links by translating a provably safe TinyLinks web
application Eurl to an F7 expression [[Eurl ]].
We describe our secure implementation strategy as a simple
4

modiﬁcation of the standard implementation.


References

Translation algorithm

Throughout the two translations, we consider some fixed well-typed
TinyLinks expression Eurl , and a structure W = (Eurl , J , H).
The first step is to perform type-directed closure conversion on
all the λ-abstractions, forms and links occurring in the source
and generate suitable datatypes for representing them in F7.
Generate mutually recursive function listeners (fHj ); each
corresponding 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 the
type and function definitions: (M1) fixed datatypes; (M2) gener-
ated datatypes; (M3) generated functions; (M4) toplevel webserver
function.

References

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


References

Translation of types and values

The translation rules for types are mostly structural. The following
two cases are of interest:
[[xml ]] = (linkclos , formclos )xml
[[P → W ]] = funclos P→W

Similarly for values the interesting cases are generating the
closures:
[[(λ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 )) for
J = ((xi :Ui )i ∈1..n , F , V , T ) ∧ J ∈ J

References

(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

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

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


References

(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 → xml
and 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 → xml
and 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

References

(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
(| HJ (g ) → fHJ g )
J∈J ∧J=(Γ,F ,href (E ),T )
| Post (clos , ls ) →
match clos , ls with
| HJ (g ), [ℓ1 ; . . . ; ℓn ] →
fHJ g [ℓ1 ; . . . ; ℓn ]
J∈J ∧J=(Γ,F ,form ([ℓ1 ,...,ℓn ],E ),T )


References

Translation from Eurl in TinyLinks to [ Eurl ]] in F7:
Let [[Eurl ]] be the F7 module obtained from Eurl by concatenating
the type and function deﬁnitions displayed previously: (M1) ﬁxed
datatypes; (M2) generated datatypes; (M3) generated functions;
(M4) toplevel webserver function. Let the interface of the module
be: val webserver : (linkclos , formclos )webapp .

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

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

References

Robust safety in F7

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

A significant result concerning F7 is the robust-safety-by-typing
theorem: 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 not
public, because of the refinements on types for the constructors HJ
of linkclos and formclos .


References

The make and check functions construct and deconstruct the
authenticated encryption of a continuation.
We use diﬀerent keys for hashing and encrypting; in total there are
four keys used for hashing links and forms, and for encrypting links
and forms respectively.
Modiﬁcations 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 ) in
FormElem (ciph , [ℓ1 , . . . , ℓn ])


References

Modiﬁcations 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
(| HJ (g ) → fHJ g )
J∈J ∧J=(Γ,F ,href (E ),T )
| Post (ciph , ls ) →
match (check fSKey fHKey ciph ), ls with
| HJ (g ), [ℓ1 ; . . . ; ℓn ] →
fHJ g [ℓ1 ; . . . ; ℓn ]
J∈J ∧J=(Γ,F ,form ([ℓ1 ,...,ℓn ],E ),T )

The function type (cipher,cipher)webapp is public, because there are no
reﬁnement types in its argument type.


References

Our main theorem is a corollary, given the robust-safety-by-typing
theorem of F7, of Lemma 2.
Lemma
exp
Suppose that ∅; ∅ ⊢ Eurl ( : 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.


References

Summary

We have obtained practical and theoretical results
demonstrating that it is possible to perform source-based
security analysis in a multi-tier web programming language.
To further validate our approach, we have implemented both
a type-and-eﬀect checker and our secure translation producing
executable semantics in F#, that can form part of a certiﬁed
web server.
What about state?
What about concurrency?
Fully distributed implementation?
http://www.cl.cam.ac.uk/~ib249/

Thank you!

References

Bibliography

E. Cooper, S. Lindley, P. Wadler, and J. Yallop. Links: Web
Programming Without Tiers. In FMCO: Proceedings of 5th
International Symposium on Formal Methods for Components
and Objects, LNCS. Springer-Verlag, 2006.
D. Gollmann. Authentication by correspondence. IEEE Journal on
Selected 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 ACM
Symposium on Principles of Programming Languages
(POPL’98), pages 252–265, 1998.
M. Serrano, E. Gallesio, and F. Loitsch. Hop: a language for
programming the web 2.0. In OOPSLA ’06: Companion to the
21st ACM SIGPLAN symposium on Object-oriented
programming systems, Baltopoulos
Ioannis G. languages, and applications, pages
Secure Compilation of a Multi-Tier Web Language

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

Recommended

Recommended

More Related Content

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

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

More from Ioannis Baltopoulos

More from Ioannis Baltopoulos (6)

Recently uploaded

Recently uploaded (20)

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