A Formal Model of Web Security Showing Malicious Cross Origin
Requests and Its Mitigation using CORP
Krishna Chaitanya Telikcherla
1
, Akash Agrawall
2
and Venkatesh Choppella
2
1
Microsoft India, Hyderabad, India
2
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 configured 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 finite state model finder, 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 specifications which are often written and imple-
mented manually. Over the years, researchers have
used formal verification 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 finite state model finder, to
build their formal model and showed that their model
is useful in identifying well-known as well as new
vulnerabilities in web specifications. 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 specifications 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 first 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 specification is tested by attempting to
generate a counterexample. Alloy analyzer converts
the Alloy specification of a model (having simulation
and checking queries) into boolean satisfiability prob-
lems (SAT) and uses a SAT solver to solve the satisfi-
ability problem within a user-specified scope.
The Alloy specification consists of signatures,
fields, facts, predicates, assertions, functions, com-
mands and scope. Signatures describe the entities that
are being reasoned and fields define the relation be-
tween signatures. Facts are additional constraints on
signatures and fields, 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 finding 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
Copyright
c
2017 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
double implication (<=>). The join (.) of two re-
lations is obtained by taking every combination of a
tuple from the first relation and a tuple from the sec-
ond relation, with the condition that the last element
of the first tuple matches with the first 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 first 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: Exfiltration 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 exfiltration scenario, where a genuine website
makes X-Origin calls and sends data to an evil server
(e.g., due to an XSS flaw). We mention this word of
caution since data exfiltration can be prevented using
Content Security Policy (CSP), which is not what we
are solving using CORP. Figure 1 depicts the differ-
ence between Exfiltration 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 sufficient 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 simplified 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 Configurable 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 classification 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 classified 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 specification. ActiveHTMLElements are further
classified 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 configuring 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 identified 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 defined 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
defined 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 find 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
20
Listing 13: Assert: showMaliciousTransactionWithImage.
The assertion showMaliciousTransactionWithJs-
Code shown in Listing 13 verifies 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 specific 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 Verification, pages
281–285. Springer.
Bhargavan, K., Fournet, C., and Gordon, A. D. (2006). Ver-
ified 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 verification 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). Redefining web browser principals with a con-
figurable 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: Verification, falsi-
fication, and analysis of security protocols. In Inter-
national Conference on Computer Aided Verification,
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-
filtration 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