A Formal Model of Web Security Showing Malicious Cross Origin

Requests and Its Mitigation using CORP

Krishna Chaitanya Telikcherla

, Akash Agrawall

and Venkatesh Choppella

Microsoft India, Hyderabad, India

IIIT Hyderabad, Hyderabad, India

Keywords:

Web Browser, Security, Alloy, Modelling, Formal Methods, Cross Origin Request Attacks, Mitigation.

Abstract:

This document describes a web security model to analyse cross origin requests and block them using CORP, a

browser security policy proposed for mitigating Cross Origin Request Attacks (CORA) such as CSRF, Click-

jacking, Web application timing, etc. CORP is conﬁgured by website administrators and sent as an HTTP

response header to the browser. A browser which is CORP-enabled will interpret the policy and enforce it on

all cross-origin HTTP requests originating from other tabs of the browser, thus preventing malicious cross-

origin requests. In this document we use Alloy, a ﬁnite state model ﬁnder, to formalize a web security model

to analyse malicious cross-origin attacks and verify that CORP can be used to mitigate such attacks.

1 INTRODUCTION

Analyzing the security of the web platform is a daunt-

ing task, since it is based on several complicated

web speciﬁcations which are often written and imple-

mented manually. Over the years, researchers have

used formal veriﬁcation to analyze the security of

network protocols. Taking this forward, Akhawe et

al. (Akhawe et al., 2010) built a formal model of

web security based on an abstraction of the web plat-

form. They used Alloy, a ﬁnite state model ﬁnder, to

build their formal model and showed that their model

is useful in identifying well-known as well as new

vulnerabilities in web speciﬁcations. Following this

work, several researchers used Alloy to formalize se-

curity aspects of the web. They used it to verify the

soundness of both existing security aspects as well as

newer proposals. Inspired by the widespread appli-

cation of Alloy in verifying web speciﬁcations and

architectures, we have used it to formalize and ver-

ify the soundness of CORP (Cross Origin Request

Policy) (Telikicherla et al., 2014), proposed by Teli-

kicherla et al. in 2014.

1.1 An Introduction to Alloy

Alloy (Jackson, 2012) is a light weight, declarative

modelling language based on ﬁrst order relational

logic. It is used for describing the structural proper-

ties of a model. Alloy Analyzer is a constraint solver

which automates the analysis of models written in Al-

loy. Alloy supports two kinds of analysis - simulation

and checking. In simulation, the consistency of an in-

variant or operation is demonstrated by generating an

instance (a state or transition). In checking, a conse-

quence of the speciﬁcation is tested by attempting to

generate a counterexample. Alloy analyzer converts

the Alloy speciﬁcation of a model (having simulation

and checking queries) into boolean satisﬁability prob-

lems (SAT) and uses a SAT solver to solve the satisﬁ-

ability problem within a user-speciﬁed scope.

The Alloy speciﬁcation consists of signatures,

ﬁelds, facts, predicates, assertions, functions, com-

mands and scope. Signatures describe the entities that

are being reasoned and ﬁelds deﬁne the relation be-

tween signatures. Facts are additional constraints on

signatures and ﬁelds, which always hold true. Pred-

icates are constraints which are required to hold true

only when they are simulated. Assertions are con-

straints which are intended to follow from the facts of

a model. If an assertion does not hold true, the ana-

lyzer will produce a counterexample. Functions are

expressions that can be reused in different contexts.

The run command asks the alloy analyzer to gener-

ate an instance of the model and the check command

asks the analyzer to verify if an assertion holds good.

The scope command limits the size of instances con-

sidered, to make model ﬁnding feasible (the default

scope is 3).

Alloy supports the following set operators: Union

(+), intersection (&), difference (−), subset (in),

equality (=) and the following logical operators:

negation (not), conjunction (and, &&), disjunction

(or,



), implication (implies, =>), alternative (else),

516

Telikicherla, K., Agrawall, A. and Choppella, V.

A Formal Model of Web Security Showing Malicious Cross Origin Requests and Its Mitigation using CORP.

DOI: 10.5220/0006261105160523

In Proceedings of the 3rd International Conference on Information Systems Security and Privacy (ICISSP 2017), pages 516-523

ISBN: 978-989-758-209-7

double implication (<=>). The join (.) of two re-

lations is obtained by taking every combination of a

tuple from the ﬁrst relation and a tuple from the sec-

ond relation, with the condition that the last element

of the ﬁrst tuple matches with the ﬁrst element of the

second tuple, and omitting the matching tuples.

An Alloy model is interpreted as a conjunctive

logical formula. Constraints enforced by signatures

and facts become a part of the formula. Also, a pred-

icate which is being simulated becomes part of the

formula.

1.2 Characterstics of the Proposed

Model

1.2.1 Simpler Abstraction

Akhawe’s Alloy model captures the abstraction of

the web platform and can be used as a baseline for

our model. However, it gets complicated when it is

extended with DOM (Document Object Model) ele-

ments and their relations. Since the problem we are

solving is related to cross origin interactions, instead

of extending Akhawe’s model, we have borrowed the

basic signatures and captured only the relevant de-

tails, thereby building a simpler abstraction of the web

platform.

1.2.2 Non-empty Context

In a general browsing scenario, when a user opens a

new browser window, there is no initial context (we

refer to this as “Empty context”). In such a context,

the user initiates the ﬁrst HTTP request by typing a

URL in the address bar. Once the request gets a suc-

cessful HTTP response, a document is constructed,

which is the state of the browser. Subsequent HTTP

requests occur in the context of this document, which

we refer to as “Non-empty context”. Our model as-

sumes that a non-empty context of attacker’s website

is available and does not model the HTTP transaction

which built this context. This assumption makes the

model simpler to analyze.

1.2.3 Focus on Malicious X-Origin Calls

Since our model assumes that a non-empty context

of attacker’s website is available, it can easily cap-

ture malicious cross origin HTTP requests sent to

a genuine site. In a typical cross site attack sce-

nario (Cro, ), a user logs into a genuine website in one

tab of a browser and (unintentionally) opens a ma-

licious website in another tab, which generates ma-

licious cross origin HTTP requests to the genuine

Figure 1: Exﬁltration vs Cross Origin Request Attacks.

site. CSRF (CSR, 2016), Web application timing

attacks (Web, ), Clickjacking (Cli, ), Login detec-

tion (Log, 2012) etc., come under this category of at-

tacks, which we combinedly call as Cross Origin Re-

quest Attacks (CORA). The instances of our model

generated by Alloy show a document loaded from an

evil server containing a set of elements (non-empty

context), which make cross origin HTTP calls to a

genuine server. This aligns with the aforementioned

attack scenario.

Note that the model should not be confused with

data exﬁltration scenario, where a genuine website

makes X-Origin calls and sends data to an evil server

(e.g., due to an XSS ﬂaw). We mention this word of

caution since data exﬁltration can be prevented using

Content Security Policy (CSP), which is not what we

are solving using CORP. Figure 1 depicts the differ-

ence between Exﬁltration and Cross Origin Request

Attacks.

1.2.4 Minimal Scope

To keep the model simple, we have restricted Al-

loy’s instances to one Browser and 2 Servers. This

is because, to demonstrate CORA (Cross Origin Re-

quest Attack), we need a minimum of two servers (a

genuine server and an evil server) and one document

loaded from the evil server, which makes HTTP re-

quests to the genuine server. Also, as against the de-

piction in Figure 1, we are not modelling multiple tabs

in the browser. The reason is, CORA is all about a ma-

licious HTTP request originating from an evil web-

page, which causes undesirable consequences in the

state of a genuine server. So it is sufﬁcient to have

A Formal Model of Web Security Showing Malicious Cross Origin Requests and Its Mitigation using CORP

517

a single tab (synonymous to Browser in our model)

which loads a document from an evil server.

2 RELATED WORK

Telikicherla et al. proposed a formal model for

Cross Origin Request Policy (CORP) (Telikicherla

and Choppella, 2013). We have simpliﬁed the model

further and captured only the elements which are re-

quired for initiating cross-origin requests and its mit-

igation. Akhawe et al. proposed a formal model

of web security and used this model to identify the

security vulnerabilities (Akhawe et al., 2010). The

model explains the details about browser, servers,

cookies, HTTP protocol and discusses different sce-

narios based on various types of potential attackers.

We have borrowed the basic signatures and captured

the relevant details from it thereby building a simpler

abstraction of the web platform.

Ryck et al. modelled CSRF attacks and showed

how their proposed method can be used to mitigate

the attack using Alloy (De Ryck et al., 2011). Chen et

al. proposed App isolation in a single browser to get

the security of multiple browser (Chen et al., 2011).

They used alloy to model a web browser and verify

the proposed method. Cao et al. have used Alloy

to model their proposed Conﬁgurable Origin Policy

(COP) and verify it (Cao et al., 2013). There has

also been some work done in validation of web secu-

rity services by modelling (Gordon and Pucella, 2005;

Bhargavan et al., 2006; Clarke et al., 2000; Cremers,

2008; Armando et al., 2005; Carlucci Aiello and Mas-

sacci, 2001; Blanchet et al., 2005).

Cross-origin request attacks can be very danger-

ous such as CSRF (CSR, 2016), login detection (Log,

2012), clickjacking (Cli, ), web application tim-

ing (Web, ). There are certain limitations of cur-

rent methods in mitigating this class of attacks (Teli-

kicherla et al., 2014). In this paper, we explain a for-

mal model of web security showing malicious cross-

origin requests and their mitigation using CORP.

3 Pre-CORP AND Post-CORP

MODEL

For easier analysis and understanding, we have cre-

ated two Alloy models: Pre-CORP and Post-CORP.

The Pre-CORP model captures the current state of

the web platform, where unrestricted cross origin re-

quests are possible. The Post-CORP model is an ex-

tension of our Pre-CORP model wherein we add ad-

ditional signatures, facts and predicates which help in

enforcing constraints on cross origin requests.

4 MODELLING CROSS-ORIGIN

REQUESTS IN THE WEB

PLATFORM (Pre-CORP)

Figure 2 shows the meta model of Pre-CORP model.

The core components of this model are: HTTPTrans-

action, Origin and HTTPEventInitiator. The rela-

tions and constraints around these components are ex-

plained in this section.

Figure 2: Meta model of Pre-CORP Alloy model.

4.1 HTTP Transactions

The code in Listing 1 shows our abstraction of an

HTTP transaction. A HTTPTransaction is a type

which consists of exactly one HTTP request and ex-

actly one HTTP response. An HTTP request is ini-

tiated from a browser and sent to a server, while an

HTTP response is initiated from a server and sent to a

browser. Both of them are associated with an origin,

HTTP Request is associated with the server to which

it is making the request and HTTP Response is as-

sociated with the server from where the response is

originated.

ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy

518

abstract si g HTT P T r a n sa c t i o n {

req : one HTTPReque s t ,

res p : o ne HT TP R e s p o n s e

}

sig H T T P R e q u e st {

fro m : o ne Br o w s e r ,

to : o ne Se r v e r ,

hos t : Or i g i n

}

sig H T T P R e s p on s e {

fro m : o ne Se r v e r ,

to : o ne Bro w s e r ,

hos t : Or i g i n

}

Listing 1: HTTP Transaction Formalization.

4.2 Origin

The code in Listing 2 shows the basic web model

which explains a key concept of the web platform -

the origin and its relation with a browser and a server.

A browser consists of exactly one active document

(i.e., the document which a user interacts with at any

point of time). Each document has exactly one ori-

gin, which is the origin of the webpage loaded in

the browser. Document also contains elements, a set

of ActiveHTMLElements, the elements which initi-

ate HTTP Transaction (explained with more clarity in

“HTTP Event Initiators” section). Each origin points

to exactly one server.

sig Origin {

pointsTo : o ne Se r v e r

}

sig Browser {

activeD o c : Document

}

abstract si g Se r v e r {}

sig Se r ver1 , Se r v e r 2 e x t e n ds Server {}

sig Doc u m e n t {

docOrig i n : Or i g i n ,

elements : s et Acti v e H T M L E l e m e n t

}

Listing 2: Browser Origin Formalization.

4.3 HTTP Event Initiators

The code in Listing 3 shows our classiﬁcation of com-

ponents of a web page (document). A HTTPEven-

tInitiator is any component that can trigger an HTTP

transaction, and is associated with an origin. Ac-

tiveHTMLElement are modelled as HTTP event ini-

tiators. We have not included inline JavaScript in

our model since cross-origin requests originated from

these elements are automatically blocked because of

Same Origin Policy (SOP) (Zalewski, Michal, 2011).

DOM elements in a document are classiﬁed based

on their capability to trigger HTTP requests. Those

that cannot trigger HTTP calls are called as passive

HTML elements (e.g., Div, Span, Textbox etc.), while

those that can trigger HTTP calls are called as ac-

tive HTML elements. For keeping the model concise,

only active HTML elements have been included in

our speciﬁcation. ActiveHTMLElements are further

classiﬁed as LoadingElements - elements that auto-

matically trigger HTTP requests as soon as they get

added to the DOM tree (e.g., img, script, iframe etc.)

and ActionElements - elements that require an action

by humans to trigger HTTP requests (e.g., hyperlinks,

forms).

abstract si g HT T P E v e n t I n i t i a t o r {

httpTra n s : lo ne HTTPT r a n s a c t i o n ,

in i t i a t o r O r i g i n : O r igin

}

abstract si g Ac t i v e H TM L E l e m e n t e x t e n d s

HT T P E v en t I n i t i a t o r {}

abstract si g Loadi n g E l e m e n t , Acti o n E l e m en t

extends Act i v e H T M L E l e m en t {}

sig ScriptEleme n t , ImageElem e n t , Cs s E lement ,

Iframe e x t e n d s L o a d i n g E l e m e n t {}

sig Hype r l ink , Fo rm exten d s A ct i o n E l e m en t {}

Listing 3: Element Formalization.

4.4 Fact: Transaction Rules

Listing 4 shows the rules which ensure that the model

is sane with respect to HTTP transactions which

happen on the web. Below is the description of the

fact.

For all instances of HTTPTransaction, Browser and

Server, the following rules should hold:

Line 3: Request and response must belong to the

same origin.

Line 4: An HTTP request’s hostname and its destina-

tion server’s origin must be the same.

Line 5: If a request is sent to a server, response

should be received from the same server.

Line 6: If a request is sent from a browser, response

should be received by the same browser.

For any two disjoint HTTPTransactions t1, t2, the

following rules should hold good:

Line 10: Two transactions should not interfere

with each other’s request.

Line 11: Two transactions should not interfere with

each other’s response.

A Formal Model of Web Security Showing Malicious Cross Origin Requests and Its Mitigation using CORP

519

Line 13: All HTTPTransactions should be due to

some Active HTML element.

fac t T r a n s a c t i o nR u l e s {

all t : H T T P T r a n s a c t i o n , b : B rows er , s :

Server | {

t . req . h o st = t . resp . ho st

t . req . h o st = t . req . to .˜

pointsTo

s = t . r e q . to = > s = t . resp .

fro m

b = t . req . f r om = > b = t . r e sp

. to

t in H T T P E v e n t I n i t i a t o r .

httpTra n s

}

all dis j t1 , t2 : HTTPT r a n s a ct i o n | {

no ( t1 . r eq & t2 . req )

no ( t1 . re sp & t2 . r e sp )

}

HT T P T r a n s a c t i o n in A c t i v e H T M L E l e me n t

. h t t p T r a n s

}

Listing 4: Fact: Transaction Rules.

4.5 Fact: NoOrphanElement

Listing 5 shows that every element must have a par-

ent attached with it (except the root element, i.e.

HTTPEventInitiator).

fac t N o O r ph a n E l e me n t {

no ( Act i v e H T M L E l e m e n t - Document .

elements )

no ( HTTP T r a n s ac t i o n -

HT T P E v en t I n i t i a t o r . h t t p T r a n s )

no ( HTTPReq u e s t - H T T P T r a n s a c t i o n .

req )

no ( HTTPR e s p o n s e - H T T P T r a n s a c t i o n .

res p )

no ( Document - B r o w s e r . activeDoc )

no ( Se r v e r - O r i g i n . pointsTo )

no Origin - ( HTTPReq u e s t . ho s t +

HTT P R e s p o n s e . h o st + D o c u m e n t .

docOrig i n )

}

Listing 5: Fact: No Orphan Element.

4.6 Fact:

EventInitiatorsInheritParentOrigin

Listing 6 shows that for all instances of HTMLEle-

ment, the initiator’s parent document’s origin must be

the same as the element’s origin.

fac t E v e n t I n i t i a t o r s I n h e r i t P a r e n t O r i g i n {

all ele m : Act i v e H T M L E l e m en t | e l em .

in i t i a t o r O r i g i n = elem .˜ elements

. d o c O r i g i n

}

Listing 6: Fact: Event Initiators Inherit Parent Origin.

4.7 Fact: Disjointness

Listing 7 ensures that no two disjoint elements inter-

fere with each other’s operations.

fac t D i s j o i nt n e s s {

all dis j b1 , b2 : B r o wser | {

no ( b1 . activeDoc & b2 .

activeD o c )

no ( b1 . activeDoc . d o c Origin

& b2 . a ctiveD o c . docOrigin

)

}

all dis j o1 , o2 : O rigin | no ( o1 .

pointsTo & o2 . po i n t s T o )

all dis j e1 , e2 : A c t i v e H T M L E l e m e n t

| no ( e1 . httpTrans & e2 .

httpTra n s )

}

Listing 7: Fact: Disjointness.

4.8 Predicate: SameOriginTransaction

Listing 8 shows instances of same origin transactions,

which are safe. There can be only one server involved

since this is a same origin transaction.

pre d S a m e O r i g i n T r a n s a c t i o n {

one H T T P T ra n s a c t i o n

one Server

}

Listing 8: Predicate: Same Origin Transaction.

4.9 Predicate: CrossOriginTransaction

Listing 9 shows instances of cross origin transactions.

There should be 2 servers involved since this a cross

origin transaction, one of the servers to which the

HTTPEventInitiator belongs and the other server to

which the request is made.

pre d C r o s s O r i g i n T r a n s a c t i o n {

som e t: H T T P T r a n s a c t i o n | {

t . req . f rom . a c t i v e D o c .

docOrig i n . pointsTo =

Server1

t . req . to = Se r v e r 2

}

Listing 9: Predicate: Cross Origin Transaction.

ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy

520

5 MODELLING RESTRICTIONS

INTRODUCED IN CORP

(Post-CORP)

We have extended our Pre-CORP model (which de-

picts unrestricted cross origin HTTP requests) with

new signatures and enforcement rules in the form

of facts and predicates. The resultant model as-

sists web administrators in conﬁguring certain per-

missions, which limit Cross Origin Request Attacks

(CORA) to a great extent. Figure 3 shows meta model

of Post-CORP model.

Figure 3: Meta model of Post-CORP Alloy model.

5.1 Key Idea of CORP

The key idea of CORP is to preserve the seman-

tics of HTTP transactions on the web, which help

in defending against CORA. Instead of looking at

the root cause of CORA as “Confused Deputy Prob-

lem”, we borrow concepts from programming lan-

guages theory and look at root of these attacks as

“Type checking problem”. We draw an analogy be-

tween HTTP requests and typing of programming

languages, which is the base for our proposal. We

observe that HTTP transactions in the current web

model are analogous to dynamic, loosely typed lan-

guages (e.g., JavaScript), where variables do not have

type but they accept values of any type. This is similar

to an image tag making a request to a “.jsp” page and

changing its state. If we can imagine the web anal-

ogous to static, strongly typed languages (e.g., Java),

an image tag will only be able to request content of

the type “image” and not a “.jsp” page. This prevents

several malicious cross origin attacks.

Since it is not possible to infer the type of con-

tent before making a request, we propose a new HTTP

response header called CORP, which contains a key-

value mapping between “types” of content and their

“resource paths”. This ensures that a tag (e.g., image)

can make a request to a URL which matches with ”re-

source path” of that type.

5.2 Resource Paths

Every resource on the web is identiﬁed by a unique

path. As a good engineering practice, web admin-

istrators often organize different types of resources

(e.g., images, scripts etc) under different directories

(e.g., http:// A.com/ images, http://A.com/ js etc.) on

the server hosting the resources. Based on this ob-

servation, we have deﬁned the signature Path in the

Post-CORP model. It has various subtypes as shown

in Listing 10. The subtype NonSensitivePagesPath

refers to pages that do not contain any sensitive con-

tent, while the subtype SensitivePagesPath refers to

pages that contain sensitive content and need utmost

protection.

abstract si g Pa th { }

one si g Im gPat h , JsPa th , C s sPat h ,

Non S e n s i t i v e P a g esP a t h ,

Se n s i t iv e P a g e s P a t h e x t e n d s Path {}

abstract si g Se r v e r {

res o u r c e P a t h : s et Pa th

}

Listing 10: Cross Origin Transaction.

5.2.1 Predicate: maliciousXOriginTransaction

The predicate maliciousXOriginTransaction is an en-

hancement to the predicate crossOriginTransaction

deﬁned in Section 4.9. The type Server has been

extended with the subtypes EvilServer and Genuine-

Server. Listing 11 shows the contraints for this predi-

cate.

sig EvilS e r v er , G e nu i n e S e r v er extends Ser v e r

{}

pre d m a l i c i o u s X O r i g i n T r a n s a c t i o n {

som e t: H T T P T r a n s a c t i o n |{

A Formal Model of Web Security Showing Malicious Cross Origin Requests and Its Mitigation using CORP

521

t . req . f r om . a c t i v e D o c . d o c O r i g i n . pointsTo =

Evil S e r v e r

t . req . to = Genuine S e r v e r

t . req . r e q P a t h = S e n s i t i v e P a g e s P a t h

}

run m a l i c i o u s X O r i g i n T r a n s a c t i o n f or 3 but

exactly 1 HT T P T r a n s a c t i o n e x p e ct 1

Listing 11: Predicate: maliciousXOriginTransaction.

5.2.2 Predicate: CORPCompliantTransaction

The predicate corpCompliantTransaction shown in

Listing 12 takes three arguments of type Origin,

HTTPEventInitiator and Path respectively. It asks

Alloy to produce an instance of the model where

the following constraints hold good for at least one

HTTP transaction:

Line 3: The request must originate from EvilServer.

Line 4: The request must be made to GenuineServer.

Line 5: The origin of the HTTP event initiator must

be the same as the predicate’s argument o.

Line 6: The HTTP event initiator that triggers an

HTTP transaction must be the same as the predicate’s

argument ev.

Line 7: The path to which the HTTP request is made

must be the same as the predicate’s argument pt.

pre d c o r p C o m p l i a n t T r a n s a c t i o n [ o : Orig in , ev :

HTTPEve n t I n i t i a t o r , p t : Path ] {

som e t: H T T P T r a n s a c t i o n {

t . req . f r om . a c t i v e D o c . d o c O r i g i n . pointsTo =

Evil S e r v e r

t . req . to = Genuine S e r v e r

t . req . f r om . a c t i v e D o c . d o c O r i g i n = o

httpTra n s . t = ev

t . req . r e q P a t h = pt

}

pre d r e s t r i c t I m a g e s W i t h C o r p {

co r p C o m p l i a n t T r a n s a c t i o n [ o r igin 2 ,

ImageE l e m e n t , Im g P a t h ]

}

pre d r e s t r i c t S c r i p t s W i t h C o r p {

co r p C o m p l i a n t T r a n s a c t i o n [ o r igin 2 ,

ScriptEl e m e n t , Js P a t h ]

}

Listing 12: Predicate: corpCompliantTransaction.

The Listing 12 also shows three more predicates -

restrictImagesWithCorp, restrictScriptsWithCorp and

restrictJsCodeWithCorp. Each of them in-turn invoke

the predicate corpCompliantTransaction with vari-

ous arguments. For example, the predicate restric-

tJsCodeWithCorp asks Alloy to produce an instance

Figure 4: Checking the post-CORP assertion showMali-

ciousTransactionWithImage

where an HTTP request is made to a GenuineServer

by a JavaScriptCode from a document having an ori-

gin origin2. It also mandates the request to be made

only to the path NonSensitivePagesPath on the Gen-

uineServer.

5.2.3 Assert:

showMaliciousTransactionWithImage

Listing 13 shows an instance of the model where a

cross origin HTTP transaction initiated by a Image

tag can be restricted through CORP to non-sensitive

pages only. While the instances produced by Alloy

show that the predicate is consistent, it is equally im-

portant to assert the negation. i.e., To ﬁnd if there

exists a cross origin HTTP transaction triggered by

Image tag to the genuine server, where the predicate

restrictImagesWithCorp is violated?

assert sh o w M a l i c i o u s T r a n s a c t i o n W i t h I m a g e {

no t : H T T PT r a n s a ct i o n |{

re s t r i c t I m a g e s W i t h C o r p

t .˜ httpTrans . i n i t i a t o r Or i g i n

= o r i g i n 2

t .˜ httpTrans = I m a ge E l e m e n t

t . req . r e q P a t h ! = Im g P a t h

}

chec k s h o w M a l i c i o u s T r a n s a c t i o n W i t h I m a g e for

Listing 13: Assert: showMaliciousTransactionWithImage.

The assertion showMaliciousTransactionWithJs-

Code shown in Listing 13 veriﬁes if such a possibility

exists. As shown in Figure 4, Alloy fails to produce

a counterexample when the assertion showMalicious-

TransactionWithJsCode is checked.

Thus, with the results shown by the predicate re-

strictJsCodeWithCorp and the assertion showMali-

ciousTransactionWithJsCode, it can be said that the

post-CORP model is sound.

ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy

522

6 CONCLUSION AND FUTURE

WORK

In this paper, we present a simple model of web plat-

form which comprises of some basic components of

web security like origin, HTML elements and HTTP

transaction, browser and servers. Our threat model

includes modelling of malicious cross-origin requests

and showing that it can be mitigated using CORP.

This model can be extended to include other web se-

curity vulnerabilities and verifying their mitigation

measures.

As future work, we plan to model speciﬁc cross-

origin attacks, such as CSRF, clickjacking, cross-site

timing attacks, login detection, and verify that CORP

can be used to mitigate them. We also plan to test

CORP with complex cross-origin request scenarios,

such as Federated Identity Management.

REFERENCES

Clickjacking. https://www.owasp.org/index.php/

Clickjacking.

Cross-site scripting (XSS). https://en.m.wikipedia.org/wiki/

Cross-site scripting.

Web Application Timing attack. https://codeseekah.com/

2012/04/29/timing-attacks-in-web-applications/.

(2012). I Know What Websites You Are

Logged-In To (Login-Detection via

CSRF). https://www.whitehatsec.com/blog/

i-know-what-websites-you-are-logged-in-\

to-login-detection-via-csrf/.

(2016). Cross-site request forgery. https://www.owasp.org/

index.php/Cross-Site Request Forgery (CSRF).

Akhawe, D., Barth, A., Lam, P. E., Mitchell, J., and Song,

D. (2010). Towards a formal foundation of web secu-

rity. In 2010 23rd IEEE Computer Security Founda-

tions Symposium, pages 290–304. IEEE.

Armando, A., Basin, D., Boichut, Y., Chevalier, Y., Com-

pagna, L., Cu

ellar, J., Drielsma, P. H., H

eam, P.-C.,

Kouchnarenko, O., Mantovani, J., et al. (2005). The

avispa tool for the automated validation of internet

security protocols and applications. In International

Conference on Computer Aided Veriﬁcation, pages

281–285. Springer.

Bhargavan, K., Fournet, C., and Gordon, A. D. (2006). Ver-

iﬁed reference implementations of ws-security proto-

cols. In International Workshop on Web Services and

Formal Methods, pages 88–106. Springer.

Blanchet, B., Abadi, M., and Fournet, C. (2005). Auto-

mated veriﬁcation of selected equivalences for secu-

rity protocols. In 20th Annual IEEE Symposium on

Logic in Computer Science (LICS’05), pages 331–

340. IEEE.

Cao, Y., Rastogi, V., Li, Z., Chen, Y., and Moshchuk, A.

(2013). Redeﬁning web browser principals with a con-

ﬁgurable origin policy. In 2013 43rd Annual IEEE/I-

FIP International Conference on Dependable Systems

and Networks (DSN), pages 1–12. IEEE.

Carlucci Aiello, L. and Massacci, F. (2001). Verifying se-

curity protocols as planning in logic programming.

ACM Transactions on Computational Logic (TOCL),

2(4):542–580.

Chen, E. Y., Bau, J., Reis, C., Barth, A., and Jackson, C.

(2011). App isolation: get the security of multiple

browsers with just one. In Proceedings of the 18th

ACM conference on Computer and communications

security, pages 227–238. ACM.

Clarke, E. M., Jha, S., and Marrero, W. (2000). Verify-

ing security protocols with brutus. ACM Transactions

on Software Engineering and Methodology (TOSEM),

9(4):443–487.

Cremers, C. J. (2008). The scyther tool: Veriﬁcation, falsi-

ﬁcation, and analysis of security protocols. In Inter-

national Conference on Computer Aided Veriﬁcation,

pages 414–418. Springer.

De Ryck, P., Desmet, L., Joosen, W., and Piessens, F.

(2011). Automatic and precise client-side protec-

tion against csrf attacks. In European Symposium

on Research in Computer Security, pages 100–116.

Springer.

Gordon, A. D. and Pucella, R. (2005). Validating a web

service security abstraction by typing. Formal Aspects

of Computing, 17(3):277–318.

Jackson, D. (2012). Software Abstractions: logic, language,

and analysis. MIT press.

Telikicherla, K. C. and Choppella, V. (2013). Alloy model

for cross origin request policy (corp). Technical re-

port.

Telikicherla, K. C., Choppella, V., and Bezawada, B.

(2014). Corp: A browser policy to mitigate web in-

ﬁltration attacks. In International Conference on In-

formation Systems Security, pages 277–297. Springer.

Zalewski, Michal (2011). Browser Security Hand-

book. Technical report. https://code.google.com/p/

browsersec/wiki/Part2#Same-origin policy.

A Formal Model of Web Security Showing Malicious Cross Origin Requests and Its Mitigation using CORP

523