Achieving Security Assurance with Assertion-based Application Construction

Achieving Securiy Assurance wih Asserion-based Applicaion Consrucion Carlos E. Rubio-Medrano and Gail-Joon Ahn Ira A. Fulon Schools of Engineering Arizona Sae Universiy Tempe, Arizona, USA, 85282 {crubiome, gahn}@asu.edu Karsen Sohr Cener for Compuing Technologies (TZI) Universiä Bremen 28359 Bremen, Germany sohr@zi.de Absrac Modern sofware applicaions are commonly buil by leveraging pre-fabricaed modules, e.g. applicaion programming inerfaces (APIs), which are essenial o implemen he desired funcionaliies of sofware applicaions, helping reduce he overall developmen coss and ime. When APIs deal wih securiy-relaed funcionaliy, i is criical o ensure hey comply wih heir design requiremens since oherwise unexpeced flaws and vulnerabiliies may be consequenly occurred. Ofen, such APIs may lack sufficien specificaion deails, or may implemen a semanically-differen version of a desired securiy model o enforce, hus possibly complicaing he runime enforcemen of securiy properies and making i harder o minimize he exisence of serious vulnerabiliies. This paper proposes a novel approach o address such a criical challenge by leveraging he noion of sofware asserions. We focus on securiy requiremens in rolebased access conrol models and show how proper verificaion a he source-code level can be performed wih our proposed approach as well as wih auomaed sae-of-he-ar asserionbased echniques. I. INTRODUCTION In recen years, here has been an increasing ineres in leveraging heerogeneous pre-fabricaed sofware modules, e.g. applicaion programming inerfaces (APIs) and sofware developmen kis (SDKs), in order o no only reduce he overall developmen coss and ime in producing high-qualiy applicaions, bu also minimize he number of incorrec behaviors (bugs) observed in he final produc. However, recen lieraure has shown ha such modules ofen lack he proper specificaion deails (in he form of formal or informal specificaion) ha are essenial o guide how a given module can be used correcly for implemening securiy-relaed funcionaliy [1] [2]. Such a problem may poenially become he source of serious securiy vulnerabiliies, as developers may no be fully aware of he omissions and flaws hey may inroduce ino heir applicaions by failing o implemen a securiy model in a proper way. In order o solve his problem, we propose an asserion-based approach o capure securiy requiremens of securiy models and creae well-defined represenaions of hose requiremens. This way, he securiy feaures could be effecively undersood by all paricipans in he sofware developmen process so ha hey can leverage hese feaures when implemening securiy-relaed funcionaliies for muli-module applicaions while being engaged in a highly-collaboraive environmen a he same ime. These asserion-based securiy specificaions would be used in conjuncion wih exising saeof-he-ar mehodologies and ools o verify securiy properies a he source-code level. In his paper, we choose he wellknown role-based access conrol (RBAC) [3] as securiy model o enforce access conrol requiremens over an applicaion ha is in urn composed of several heerogeneous modules. Also, we uilize exising ools o verify a se of securiy properies, hus providing a way o locae and possibly correc poenial securiy vulnerabiliies in sofware applicaions. This paper is organized as follows: we sar by providing some background in Secion II. Nex, we examine he general problem, as well as he problem insance discussed in his paper in Secion III. We hen presen our approach in Secion IV, and a case sudy depicing hree Java-based sofware applicaions and an experimenal process in Secion V. In Secion VI, we provide some discussion on he benefis and observed shorcomings of our approach as well as some relaed work. Finally, Secion VII presens direcives for our fuure work and concludes he paper. II. BACKGROUND Sofware asserions are commonly described as formal consrains inended o describe wha a sofware sysem is expeced o do a runime, and are commonly wrien as annoaions in he sysem s source code [4]. Using asserions, developers can specify wha condiions are expeced o be valid before and afer a cerain porion of code ges execued, e.g. he expeced range of values inended for he parameer of a given funcion. Design by conrac (DBC) [5] is a sofware developmen mehodology based on asserions and he assumpion ha he developers and he prospecive users (cliens) of a given sofware module esablish a conrac beween each oher in order for he module o be used correcly. Commonly, such a conrac is defined in erms of asserions in he form of pre and pos condiions, among oher relaed consrucs. Before using a DBC-based sofware module M, cliens mus make sure ha M s precondiions hold. In a similar fashion, developers mus guaranee ha M s poscondiions hold once i has finished execuion, assuming is corresponding precondiions were saisfied beforehand. The Java Modeling Language (JML) [6], is a behavioral inerface specificaion language (BISL) for Java, wih a rich suppor for DBC conracs. Using JML, he behavior of Java modules can be specified using pre and pos condiions, as well as class invarians, which are commonly expressed in he form of asserions, and are added o Java source code as he form of commen such as //@ or /*@...@*/. Fig. 1 shows an excerp of a Java inerface COLLABORATECOM 2014, Ocober 22-25, Miami, Unied Saes Copyrigh 2014 ICST DOI 10.4108/ics.collaboraecom.2014.257691

1 public inerface Accoun{ 2 3 //@ public insance model double balance; 4 5 //@ public invarian balance > 0.0; 6 7 /*@ public normal_behavior 8 @ requires am > 0.0; 9 @ assignable balance; 10 @ ensures balance == (\old(balance) - am); 11 @*/ 12 public void wihdraw(double am) 13 hrows SecuriyExcepion; 14 15 } Fig. 1: An Excerp of a JML-annoaed Banking Applicaion. named Accoun, which belongs o a banking applicaion and has been annoaed wih JML specificaions. A summary of he JML feaures exercised in his paper can be found in [6] and [7]. In recen years, he American Naional Insiue of Sandards (ANSI) released a sandard documen ha provides welldefined descripions of he main componens and funcions ha define RBAC [8], and i is mosly based on he well-known Z specificaion language [9]. In addiion, a dedicaed profile has been inroduced o provide suppor for expressing RBAC policies by aking boh he aforemenioned ANSI RBAC sandard as a reference foundaion as well as he well-known exensible Access Conrol Markup Language (XACML), which is a sandard language for supporing he disribued definiion and sorage & enforcemen of rich access conrol policies [10], [11]. III. PROBLEM DESCRIPTION As menioned earlier, recen lieraure includes examples showing ha mission-criical applicaions, e.g. banking mobile applicaions, have suffered from serious securiy vulnerabiliies derived from an incorrec use of heir supporing securiy APIs a he source-code level [1], [2]. Among he possible causes of his problem, insufficien sofware specificaions, including he definiion of prerequisies and hidden assumpions, as well as he exisence of muliple semanic variaions of a given securiy model, e.g., he lack of foundaion on a sandardized, well-defined model serving as a reference, are cied as common sources of incorrec implemenaions. Moreover, he problem ges aggravaed by he lack of effecive sofware verificaion procedures a he source-code level, which could affec he chances of idenifying and poenially correcing securiy vulnerabiliies exhibied by applicaions before deploying in a producion sysem. In his paper, we address an insance of his problem by choosing RBAC as he securiy model o enforce access conrol requiremens in a sofware applicaion ha is in urn composed of several modules. Each of hem possibly implemens a differen version of RBAC whose semanics may or may no sricly adhere o an exising RBAC reference model such as he one described in [8]. We herefore aim o verify ha such heerogeneous modules, when used o build a arge applicaion, correcly enforce a well-defined and consisen high-level RBAC policy, despie he differences hey may exhibi wih respec o heir inner workings relaed o RBAC feaures, which could evenually resul in securiy vulnerabiliies. Fig. 2 (a) and Fig. 2 (b) show a Java-based example where a high-level RBAC policy is enforced a runime by placing auhorizaion checks before performing securiy-sensiive operaions. In boh insances, a policy depics a role manager as a senior role o eller, and allows for users, who are assigned o roles ha happen o be senior o manager, o execue boh he ransfer and wihdraw operaions, whereas users holding eller role are allowed o execue he wihdraw operaion only. Fig. 2 (a) shows a Java class BankAccoun, which leverages he Spring Framework API [12] for implemening an auhorizaion check (lines 7-16). Similarly, Fig. 2 (b) shows anoher class DebiBankAccoun depicing an auhorizaion check using he Apache Shiro API [13] (lines 7-11). In such a seing, i is desirable o evaluae he correc enforcemen of he aforemenioned RBAC policy as follows: firs, he auhorizaion checks depiced in boh examples mus correcly specify he roles ha are allowed o execue each of he securiy-sensiive operaions. For insance, he auhorizaion check depiced in Fig. 2 (a) incorrecly allows for anoher role agen o also execue he wihdraw mehod, which in urn represens a poenial securiy vulnerabiliy. Second, he role hierarchy depiced in he high-level policy mus be correcly implemened a he source-code level by leveraging boh APIs. As roles ha happen o be senior o role manager should be allowed o execue boh he ransfer and wihdraw mehods, he role hierarchy mus be correcly implemened by placing accurae auhorizaion checks wihin he source code. In addiion, he role hierarchy mus be also defined correcly in he supporing API configuraion files. as an incorrec implemenaion, e.g. missing role names wihin he XML files defined for he Spring API, may preven users wih he role manager from execuing he ransfer mehod. A more serious problem may be originaed if users wih he role eller are allowed o execue he ransfer mehod. Finally, if users wih he role manager are allowed o execue he ransfer mehod, bu are disallowed from execuing he wihdraw mehod (Fig. 2 (b)) by incorrecly configuring he Spring API depiced in Fig. 2 (a), a given objec of class DebiBankAccoun may be lef in an inconsisen sae, hus also creaing a serious securiy problem. IV. OUR APPROACH: ASSERTION-BASED APPLICATION CONSTRUCTION In order o provide a soluion o he problem described in Secion III, we propose an approach ha combines he conceps of specificaion modeling and sofware asserions for describing securiy feaures a he source-code level. These socalled asserion-based securiy models are inended o provide compac, well-defined and consisen descripions ha may serve as a common reference for implemening securiy-relaed funcionaliy. Our approach srives o fill in he gap beween high-level descripions of securiy feaures, which are mosly absrac and implemenaion-agnosic, and supporing descripions focused a he source-code level, which are inended o cope wih boh securiy-relaed and behavioral-based specificaions. As i will be described in Secion VI, previous work has also explored he use of sofware asserions and DBClike conracs for specifying access conrol policies. However, our approach is inended o leverage he modeling capabiliies offered by sofware specificaion languages using a welldefined reference descripion of a securiy model as a source,

1 impor org.springframework.securiy.core.*; 2 public class BankAccoun implemens Accoun{ 3 4 public void wihdraw(double am) 5 hrows SecuriyExcepion{ 6 7 Ieraor ier = SecuriyConexHolder 8.geAuhoriies().ieraor(); 9 10 while(ier.hasnex()){ 11 GranedAuhoriy auh = ier.nex(); 12 if (!auh.geauhoriy().equals("eller") 13!auh.geAuhoriy().equals("agen")){ 14 hrow new SecuriyExcepion("Access Denied"); 15 } 16 } 17 his.balance -= am; 18 } 19 } 1 impor org.apache.shiro.*; 2 public class DebiBankAccoun{ 3 4 public void ransfer(double am, BankAccoun acc) 5 hrows SecuriyExcepion{ 6 7 if(!securiyuils.gesubjec().hasrole("manager")){ 8 9 hrow new SecuriyExcepion("Access Denied"); 10 11 } 12 13 acc.wihdraw(am); 14 his.balance += am; 15 16 } 17 18 19 } (a) Spring Framework API. (b) Apache Shiro API. Fig. 2: Enforcing an RBAC Policy by Leveraging Heerogeneous Securiy Modules. in such a way i no only allows for he correc communicaion, enforcemen and verificaion of securiy-relaed funcionaliy, bu i also becomes independen of any supporing APIs used a he source-code level, hus poenially allowing for is deploymen over applicaions composed of several heerogeneous modules as shown in Fig. 3: an asserion-based securiy model is inended o be enforced over a arge applicaion ha is in urn composed of wo modules leveraging securiy APIs and wo modules whose securiy-relaed funcionaliy has been implemened from scrach. This way, he semanic differences exhibied by such modules, as shown in Secion III, can be effecively miigaed. Moreover, by leveraging sae-of-hear mehodologies based on asserions, effecive auomaed verificaion of securiy properies a he source-code level becomes feasible, hus providing a means for discovering and possibly correcing poenial securiy vulnerabiliies. To address he problem insance discussed in his paper, we leverage he JML modeling capabiliies, e.g. model classes [7], o describe he ANSI RBAC sandard described in Secion II. Laer on, hese model classes are used o creae asserionbased consrains, which are in urn incorporaed ino he DBC conracs devised for each module in an applicaion. This way, a high-level RBAC policy can be specified a he source-code level by ranslaing i ino asserion-based consrains included in DBC conracs. Following our running example, Fig. 4 shows an excerp of a model class JMLRBACRole, which depics he role componen and some of is relaed funcionaliies as devised in he ANSI RBAC sandard, e.g. role hierarchies. Such a model class is leveraged in Fig. 5 o augmen he JML-based conrac depiced in Fig. 1 wih securiy-relaed asserions resricing he execuion of he wihdraw mehod o users who acivae a role senior o eller. We sar by defining a model variable role, of ype JMLRBACRole (line 5), which is laer used for defining access conrol consrains in he wo specificaion cases depiced in Fig. 5: he firs specificaion case, depiced in lines 9-14, allows one o properly execue he wihdraw mehod, e.g. deducing from he balance of a given accoun, only if he objec sored in he role variable represens a role senior o eller 1. The second specificaion 1 Following he ANSI RBAC sandard, a given role is always senior o iself. Asserion-based Securiy Model Module 1 (API 1 ) Module 3 Module 2 (API 2 ) Own Code Sofware Applicaion Fig. 3: Deploying Asserion-based Securiy Models over a Muli-module Applicaion. 1 package edu.asu.sefcom.ac.rbac; 2 public class JMLRBACRole 3 exends JMLRBACAbsracRole{ 4 5 public boolean isseniorroleof( 6 JMLRBACAbsracRole role){ 7 8 if(his.equals(role)){ reurn rue; } 9 10 reurn gealljuniorroles().conains(role); 11 } 12 } Fig. 4: An Excerp of a JML Model Class Depicing an ANSI RBAC Role Componen. case, shown in lines 16-20, allows for he wihdraw mehod o hrow a runime excepion if he aforemenioned consrain is found o be false. In addiion, such a specificaion case also prevens any modificaion o he sae (e.g. privae fields) of a given objec of ype BankAccoun from aking place. Fig. 7 depics our approach: a high-level RBAC policy, which is encoded by means of he dedicaed RBAC profile provided by XACML [11], is ranslaed ino a series of DBC conracs. Laer on, such conracs, along wih he source code

1 //@ model impor edu.asu.sefcom.ac.rbac.*; 2 public inerface Accoun{ 3 4 //@ public insance model double balance; 5 //@ public insance model JMLRBACRole role; 6 7 //@ public invarian balance > 0.0; 8 9 /*@ public normal_behavior 10 @ requires am > 0.0; 11 @ assignable balance; 12 @ ensures role.isseniorroleof( 13 @ new JMLRBACRole("eller")) ==> 14 @ (balance == \old(balance) - am); 15 @ also 16 @ public excepional_behavior 17 @ requires!role.isseniorroleof( 18 @ new JMLRBACRole("eller")); 19 @ assignable \nohing; 20 @ signals_only SecuriyExcepion; 21 @*/ 22 public void wihdraw(double am) 23 hrows SecuriyExcepion; 24 25 } Fig. 5: Enhancing a DBC conrac wih Access Conrol Asserions. 1 impor org.springframework.securiy.core.*; 2 public class BankAccoun implemens Accoun{ 3 4 //@ public represens role <- maprole(); 5 6 /*@ public pure model JMLRBACRole maprole(){ 7 @ 8 @ JMLRBACRole newrole = new JMLRBACRole(""); 9 @ RBACMonior monior = new RBACMonior(); 10 @ 11 @ Ieraor ier = SecuriyConexHolder 12 @.geauhoriies().ieraor(); 13 @ 14 @ while(ier.hasnex()){ 15 @ GranedAuhoriy auh = ier.nex(); 16 @ if (auh.geauhoriy().equals("eller")){ 17 @ newrole = new JMLRBACRole("eller"); 18 @ } 19 @ } 20 @ 21 @ reurn newrole; 22 @ } 23 @*/ 24... 25 } Fig. 6: An Excerp Showing a JML Absracion Funcion. for a given sofware applicaion, are fed ino JML-based auomaed ools for verificaion purposes. Since such an applicaion may be in urn composed of heerogeneous modules and each of hem possibly represens a differen API for implemening securiy-relaed funcionaliy, e.g. enforcing an RBAC policy, he configuraion files for such APIs mus be also aken ino accoun when leveraging auomaed ools for verificaion, as described in Secion III. In order o auomae he creaion of DBC conracs such as he ones depiced in Fig. 5, we designed an auomaed ool ha ranslaes RBAC policies encoded in he RBAC XACML profile ino JML-based specificaions, hus relieving policy designers and sofware archiecs from crafing such conracs manually and eliminaing a poenial source for errors. <xml...> <...> <.../> RBAC XACML Policy Files DBC/JML Conracs + Java Source Code + API Config. Files JML-based Verificaion Tools Fig. 7: A Framework for Asserion-based Securiy Assurance. As described in Secion I, we aim o provide he verificaion of securiy properies by leveraging an approach based on auomaed uni esing [14] as well as he JML specificaions depicing he asserion-based models described above. For such a purpose, we adop JET [14], which is a dedicaed ool ailored for providing auomaed runime esing of Java modules wih JML-based asserions, e.g. classes. Using JET, esers can verify he correcness of a Java module by checking he implemenaion of each mehod agains heir corresponding JML specificaions. In addiion, we also aim o provide suppor for finding possible securiy vulnerabiliies by means of saic echniques. For such a purpose, we leverage he ESC/Java2 ool [6], which is based on a heorem prover and inernally builds verificaion condiions (VCs) from he source code being analyzed, and is corresponding JML-based specificaions, which he heorem prover hen aemps o prove, hus allowing for he auomaed analysis of whole code modules wihou running he applicaions. In paricular, ESC/Java2 uses modular reasoning [15], which is regarded as an effecive echnique when used in combinaion wih saic checking since code secions can be analyzed and heir JML-based specificaions can be proved by inspecing he specificaion conracs of he mehods hey call wihin heir mehod bodies. Laer, in Secion V, we presen our findings on leveraging boh echniques in a se of case sudies depicing mission-criical Java applicaions. In order o suppor he verificaion process jus described, proper consrucs are needed o map he modeling feaures included in DBC conracs (as depiced in Fig. 5) and he implemenaion source code of each heerogeneous module. For such a purpose, we leverage he feaures offered by he JML absracion funcions [7], which allow for JML model feaures o be properly mapped o source-code level consrucs, hus providing a way o verify ha each heerogeneous module implemens a given high-level policy correcly. As an example, Fig. 6 shows an excerp where a JML model mehod is used o map he source code implemening securiy feaures as provided by he Spring Framework API wih he model feaures depiced in Fig. 5. In general, he correc enforcemen of a securiy model may involve he following cases: firs, a high-level securiy policy, which is based on a well-defined securiy model definiion, should be correcly defined and all policy conflics mus have been resolved, e.g. evaluaing a given RBAC policy by using echniques such as he ones discussed in [16]. Second, access o all proeced resources wihin a given applicaion, e.g. he wihdraw operaion depiced in Fig. 5, is guarded by an

TABLE I: Disribuion of Responsibiliies for Enforcing an Asserion-based Securiy Model In a Collaboraive Seing. Acor Securiy Domain Expers Securiy Policy Adminisraors Sofware Archiecs Code Developers Code Tesers Descripion of Tasks Develop an asserion-based securiy model by using a precise definiion as a reference, e.g. using he ANSI RBAC sandard. (See Fig. 4). Insaniae he securiy model o be enforced, e.g. specificaion of an RBAC policy based on he ANSI RBAC sandard. Incorporae he securiy policy ino DBC consrucs by specifying asserion-based consrains (See Fig. 5). Correcly implemen he DBC specificaions defined by sofware archiecs (including securiy checks). Provide a mapping beween he securiy model and he securiy APIs used for implemenaion purposes (See Fig. 6). Verify boh he funcional and he securiy relaed aspecs of a given sofware applicaion based on heir DBC specificaions (See Secion V). auhorizaion check (adhering o he well-known principle of complee mediaion). Following our example, auhorizaion checks should depic he RBAC consrucs defined in he overall policy, e.g. checking for he correc roles and/or permissions before execuing any sensiive operaion. Third, supporing componens for he securiy model feaures is implemened correcly, e.g. RBAC role hierarchies. Finally, we also require ha he deecion of runime policy violaions is implemened properly, e.g. excepion handling and daa consisency. Wih his in mind, for he problem insance addressed in his paper, we make he following assumpions: firs, he ANSI RBAC model is well-undersood by all paricipans in he sofware developmen process, e.g. policy designers, sofware archiecs and developers. Second, he asserion-based specificaion of he securiy model is correc: in oher words, i has been verified beforehand. Third, any supporing RBAC modules, including securiy APIs and SDKs, have been implemened correcly, even hough heir semanics wih respec o RBAC may differ, as addressed in Secion III. Finally, our approach is inended o be carried ou by he differen paricipans in he sofware developmen process, in such a way ha he process of consrucing vulnerabiliyfree sofware becomes a collaboraive responsibiliy shared by all involved acors, obviously including he source-code level developers. Table I shows a summary of he asks devised for each paricipan. V. CASE STUDY In order o provide a proof-of-concep implemenaion of our approach, we developed a reference descripion of he securiy model under sudy by using a se of JML model classes based on he case illusraed in Fig. 4. Such a reference model conains 960 lines of code grouped in 17 Java classes, including 1,383 lines of JML specificaions depicing he funcionaliy desired for RBAC as described in he ANSI RBAC sandard. For our case sudy, we leveraged a pair of open-source Java applicaions: OSCAR EMR [17], which is a rich web-based sofware plaform ailored for handling elecronic healh records (EMR). I consiss of approximaely 35,000 lines of code organized ino 110 classes and 35 packages. In addiion, we also leveraged JMoney [18], a TABLE II: A Sample RBAC Policy for Evaluaion Purposes. Role Junior Roles Sample Allowed Operaions Employee - deposi Teller Employee wihdraw, deposi Agen Employee close, deposi Manager Teller, Agen ransfer, wihdraw, deposi, close financial applicaion consising of 7,500 lines of code grouped ino 45 classes. Finally, we developed a banking applicaion depicing he running examples shown in his paper. Such an applicaion leverages he Apache Shiro and Spring Framework Securiy APIs, as well as our own RBAC monior developed for implemening securiy-relaed funcionaliy. I consiss of 36 classes and conains 1,550 lines of code as well as 1,450 lines of JML specificaions, which uilize our JML model classes in DBC conracs, as shown in Fig. 5. In order o verify he effeciveness of our approach for deecing fauly implemenaions of he RBAC securiy model, we followed an approach inspired in muaion esing [19]: we insered variaions (also known as muans) in boh he source code and he API configuraion files of he applicaions considered in our sudy, in an effor o inroduce inconsisencies in he implemenaion of heir corresponding RBAC Policies. As an example, Fig. 8 shows differen muans inroduced o he RBAC policy shown in Table II: firs, he original policy is modified o add an uninended permission (ransfer, ()) o a role employee (Fig. 8 (a)). Such a modificaion creaes a poenial securiy vulnerabiliy as i allows employee, and all oher roles senior o i, e.g. agen and eller, o execue an operaion ha was originally inended only for a role manager. Similarly, Fig. 8 (b) shows a permission (deposi, (d)) being removed from he employee role. Such a modificaion produces an inconvenience o such a role and all oher roles ha happen o be senior o i, as execuion of he deposi operaion will be denied a runime. Fig. 8 (c) shows anoher example where he original role hierarchy of he RBAC policy is modified o inroduce an uninended role (supervisor, (S)). This way, he newly-inroduced role creaes a pair of securiy vulnerabiliies: firs, i inheris he permissions from all junior roles in he hierarchy, hus allowing for he execuion of uninended operaions. Second, i also allows for a senior role in he hierarchy o obain an exra permission (audi, (a)), hus possibly allowing hem o perform uninended operaions as well. Fig. 9 shows an excerp of an XML configuraion file depicing he role hierarchy modificaion shown in Fig. 8 (c) (lines 6-8). Finally, Fig. 8 (d) shows a case when a role is removed from a role hierarchy: eller is lef aside by removing he relaionships wih boh he manager (senior) and he employee (junior) roles. I expose an inappropriae permission revocaion o no only users holding he role eller, as such a role is prevened from geing he permissions of is junior roles (e.g. deposi, (d)), bu also senior roles since i prevened from geing he permissions assigned o eller (e.g., wihdraw, (w)) including all oher permissions ha could be obained from junior roles o eller.

A. Asserion-based Verificaion M M Following he auomaed esing approach described in Secion IV, we conduced a se of experimens o measure he effeciveness of our asserion-based models, along wih our enhanced DBC conracs, in deecing he muaions inroduced ino he applicaions esed in our case sudy. Such experimens were carried ou on a PC equipped wih an Inel Core Duo CPU running a 3.00 GHZ, wih 4 GB of RAM, running Microsof Windows 7 64-Bi Enerprise Ediion. Firs, we measured he impac of our approach in he average execuion ime of he applicaions. As described in [14], he JML-based specificaions depicing our model classes are ranslaed ino runime asserion checking (RAC) code, which is hen execued along wih he original applicaion code for verificaion purposes. In order o provide a mapping beween he modeling feaures included in JML conracs (as depiced in Fig. 5) and he implemenaion code of each heerogeneous module, we leveraged he feaures offered by he JML absracion funcions [7]: we enhanced our supporing ool described in Secion IV o also produce absracion funcions for he referred Spring Framework and Apache Shiro APIs. We hen execued a sample race of he Java mehods exposed by our hree applicaions and calculaed he average execuion ime over 1,000 repeiions. Such a race was creaed o conain represenaive operaions for each applicaion, e.g. he race creaed for he OSCAR EMR applicaion ha conains Java mehods used o updae paien s personal daa as well as informaion abou medical appoinmens and prescripions. As shown in Table III, he inroducion of RAC code has a moderae impac on he performance, which is mosly due o he overhead inroduced by he RAC code generaed o process boh he JML conracs as well as he absracion funcions. We hen recorded he resuls obained by our ool while aemping o deec (kill) he muans inroduced in boh he configuraion of he Securiy APIs as well as he auhorizaion checks guarding each of he Java mehods conained in our sample races, following he approach depiced in Fig. 8. Table III shows a repor on he number of generaed es cases, including he number of meaningful ones produced by he ool. 2 Our meaningful es cases were able o kill all he muans insered ino our case sudy applicaions. In an addiional experimen, we compared he ime aken by our JML model classes o deec each of he muan generaion echniques depiced in Fig. 8. Once again, we used a race of Java mehods depicing he main funcionaliy for each applicaion, and used he auomaed muan-generaion ool described before o generae differen variaions o an original RBAC policy. The resuls, as shown in Fig. 12, show ha adding/removing a role o a given hierarchy is he mos cosly muaion o be deeced by he RAC code hrough processing our asserion-based JML classes. This is mosly due o he way how role hierarchies are implemened in our JML classes, by using a series of java.uil.arraylis objecs o sore references o each senior/junior role in a given hierarchy, and allowing for such references o be inspeced recursively when deermining if here is a senioriy relaionship beween wo given roles. 2 In JET, a es case T for a given mehod M is said o be meaningful if he ool is able o randomly creae values for M s formal parameers in such a way M s precondiions involving such parameers are saisfied. Oherwise T is said o be meaningless. c A E T w (a) Adding a Permission. c A M S E T (c) Adding a Role. a w d d c A E T w (b) Removing a Permission. c M A E T d (d) Removing a Role. Fig. 8: Inroducing Muans in an RBAC Policy. 1 <?xml...> 2... 3 <beans:bean id="rolehierarchy"...> 4 <beans:propery name="hierarchy"> 5 <beans:value> 6 manager > supervisor 7 supervisor > eller 8 supervisor > agen 9 eller > employee 10 agen > employee 11 </beans:value> 12 </beans:propery> 13 </beans:bean> 14... Fig. 9: Inroducing Muans in Spring Framework. TABLE III: Experimenal Daa on Using JET and ESC/Java2. d w Banking JMoney OSCAR Toal mehods 46 136 125 JET Analysis ime per mehod /s 4.56 17.32 15.4 Toal analysis ime /s 209.76 2355 1925 Runime overhead /s 0.97 2.34 1.78 Generaed es cases 1000 1000 1000 Meaningful es cases 150 250 225 ESC/Java2 Analysis ime per mehod /s 0.43 2.07 0.5 Toal analysis ime /s 19.66 281.41 63.00 As menioned in previous secions, we also leverage he ESC/Java2 ool for providing verificaion guaranees based on saic analysis echniques and our proposed approach. However, despie he suppor provided for JML-based consrucs by such a ool, some challenges mus be addressed: firs, in order o prove he correcness of a cerain source code C agains is corresponding JML conracs, he ool addiionally requires ha he JML specificaions of each library called wihin C are available, including he specificaions of addiional libraries he original ones may evenually call laer on. In some cases, such a requiremen may nooriously increase he amoun of VCs

1 public class Subjec{ 2 3 /*@ public normal_behavior 4 @ requires rue; 5 @ ensures \resul == rue \resul == false; 6 @ also 7 @ public excepional_behavior 8 @ requires false; 9 @ assignable \nohing; 10 @*/ 11 public /*@ pure @*/ boolean hasrole(sring r){ 12 reurn rue; 13 } 14 } Fig. 10: Specificaions Subs for he Apache Shiro API. 1 public inerface Accoun{ 2 3 /*@ public normal_behavior 4 @ requires am > 0.0; 5 @ assignable balance; 6 @ ensures 7 @ (SecuriyUils.geSubjec() 8 @.hasrole("eller") 9 @ SecuriyUils.geSubjec() 10 @.hasrole("manager")) 11 @ ==> 12 @... 13 @*/ 14 public void wihdraw(double am) 15 hrows SecuriyExcepion; 16 } Processing Time (ms) 10 6 10 5 10 4 10 3 10 2 Fig. 11: Translaing Model JML Classes. Performance of JML Model CLasses agains Muaion Techniques ADD PERM REM PERM ADD ROLE REM ROLE Number of muans inroduced in RBAC Policy Fig. 12: Runime performance of a Dynamic Verificaion Approach. ha need o be proved by he ool, so he verificaion process becomes prohibiively expensive, resuling in he specificaion creep problem [15]. Second, an addiional problem arises from he lack of suppor offered by he curren ool for advanced JML conceps, such as he JML model classes inroduced in Secion IV and he JML absracion funcions also described before, as he inernally-produced VCs are oo complex for he ool o handle, which limis he applicabiliy of our asserionbased models. Subsequenly, we presen an approach ha addresses hese challenges while sill providing verificaion guaranees for our asserion-based approach. Firs, we addressed he specificaioncreep problem. In paricular, as described in Secion IV, we assumed he Securiy APIs leveraged wihin our case sudy have been implemened correcly and previously verified elsewhere. Therefore, here is no need o include heir corresponding source code in our verificaion process. Based on his observaion, we provided specificaion subs for he leveraged Securiy APIs whose JML-based annoaions are rivially saisfied. Fig. 10 shows he ranslaed JML specificaions for he mehod hasrole of class Subjec, which implemens an auhorizaion check in he Apache Shiro API, as shown in Fig. 2 (b). This process can be carried ou by securiy domain expers for he Securiy APIs and mus only be revised when new API versions are released. Second, as menioned before, he JML model classes, which are a core par of he approach shown in Secion IV, are beyond he curren capabiliies of ESC/Java2. To overcome his limiaion, we provided JML specificaions ha do no employ he JML model classes and use low-level JML conceps insead. For example, he role hierarchy depiced in Table II and Fig. 5, which checks ha he curren user is graned a role senior o eller (e.g. manager), can be ranslaed ino he JML conracs shown in Fig. 11 (lines 7-10): he references o he model class JMLRBACRole have been subsiued for he hasrole mehod of class Subjec provided by he Apache Shiro API, and are inegraed ogeher by using he operaor in JML, applied o all relevan senior roles (e.g., he manager role in line 10). Afer he preparaion seps, we applied our analysis echnique o he applicaions under our case sudy, by following he muaion-based approach described before. We used a convenional Lenovo Thinkpad T510 lapop (Inel Core i7-620m Processor, 2.66GHz, 8 GB RAM). All muans were auomaically deeced by ESC/Java2 even if hey were hidden wihin he many mehods of our case sudies. The runime of he hree applicaions under our case sudy is given in Table III. VI. DISCUSSION AND RELATED WORK The experimenal resuls depiced in Secion V-A suppor our claim ha our approach can effecively expose he se of securiy vulnerabiliies caused by he incorrec source-code level implemenaions of securiy models. In our approach, we have seleced Java for our proof-of-concep implemenaion due o is exensive use in pracice. Moreover, we have also chosen JML as he specificaion language for defining our asserionbased securiy models due o is enhanced ool suppor as well as is language design paradigm, which suppors rich behavioral specificaions. A he same ime i srives o handle he complexiy of using complex specificaion consrucs, in such a way i becomes suiable for average developers o use [6]. (see Table I). We believe our approach can be exended o oher programming languages/developmen plaforms. For insance, Spec# [20] provides rich DBC-based specificaions for he C# language, depicing an approach similar o JML. Moreover, our approach can be also applied o oher Javabased frameworks such as JEE [21] or Android [22], which may help implemen auhorizaion checks for guarding access o is core sysem services. Despie our success, some issues sill remain in he verificaion process. In paricular, ESC/Java2 may produce false posiives (in case he buil-in heorem prover canno prove a VC) and false negaives (e.g., resricions on loop unrolling). To deal wih his siuaion, a possible soluion may consider a runime esing approach, like he one we have

described using he JET ool, for all mehods raising warnings by ESC/Java2, hus showing a way in which boh echniques can be o provide sronger guaranees for he verificaion. Second, as shown in Table III, he number of meaningful es cases produced by he JET ool is considerably less han he number of es cases creaed, which may affec he es coverage provided by he ool and could allow for poenial securiy vulnerabiliies o remain hidden during he verificaion process. This is mosly due o he limiaions on he auomaed esing echnique [14]. A possible soluion would adop a saic approach for hose mehods whose es coverage is found o be below a given hreshold. Our work is relaed o oher effors in sofware securiy: Archiecural risk analysis [23] aemps o idenify securiy flaws on he level of he sofware archiecure and hence is unrelaed o he source-code level addressed in his approach. Language-based securiy approaches in he sense of Jif [24] allow sofware o be verified agains informaion flow policies raher han supporing specific securiy requiremens for differen Securiy APIs. Formal verificaion of RBAC properies has been already discussed in he lieraure [16]. These approaches are mosly focused on verifying he correcness of RBAC models wihou addressing heir corresponding verificaion agains an implemenaion a he source-code level. The work closely relaed o ours involves he use of DBC, which was explored by Dragoni, e al. [25]. In addiion, Belhaouari e al. inroduced an approach for he verificaion of RBAC properies based on DBC [26]. Boh approaches, while using DBC for checking RBAC properies, do no include he use of reference models o beer aid he specificaion of DBC consrains in he securiy conex. Moreover, no suppor is provided as APIindependen consrucs, such as he JML model capabiliies discussed in our approach. VII. CONCLUSIONS AND FUTURE WORK In his paper, we have addressed he problem originaed by he exisence of securiy vulnerabiliies in sofware applicaions. We have shown how such vulnerabiliies, which may exis due o he lack of proper specificaion and verificaion of securiy checks a he source-code level, can be ackled by using well-defined reference models wih he help of sofware asserions, hus providing a reference for he correc enforcemen of securiy properies over applicaions composed of heerogeneous modules such as APIs and SDKs. Fuure work would include he inroducion of asserion-based models o beer accommodae oher relevan securiy paradigms, e.g., he correc usage of crypography APIs. Also, we plan o refine our proposed RBAC model inroduced in Secion IV by inroducing an auomaed ranslaion from he specificaions depiced in he ANSI RBAC sandard, which are wrien in he Z specificaion language, o our supporing language JML. ACKNOWLEDGMENT This work was parially suppored by a gran from he US Deparmen of Energy (DE-SC0004308). REFERENCES [1] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V. Shmaikov, The mos dangerous code in he world: validaing SSL cerificaes in non-browser sofware, in Proc. of he ACM Conf. on Compuer and comm. securiy, 2012, pp. 38 49. [2] S. Fahl, M. Harbach, T. Muders, L. Baumgärner, B. Freisleben, and M. Smih, Why eve and mallory love Android: an analysis of Android SSL (in)securiy, in Proc. of he ACM Conf. on Compuer and communicaions securiy, 2012, pp. 50 61. [3] R. S. Sandhu, E. J. Coyne, H. L. Feinsein, and C. E. Youman, Role- Based Access Conrol Models, IEEE Compuer, vol. 29, no. 2, pp. 38 47, 1996. [4] D. S. Rosenblum, A pracical approach o programming wih asserions, IEEE Trans. Sofw. Eng., vol. 21, no. 1, pp. 19 31, Jan. 1995. [5] C. A. R. Hoare, An axiomaic basis for compuer programming, Communicaions of he ACM, vol. 12, no. 10, pp. 576 580, Oc 1969. [6] L. Burdy, Y. Cheon, D. Cok, M. Erns, J. Kiniry, G.-T. Leavens, K. Leino, and E. Poll, An overview of JML ools and applicaions, in Proc. 8h In l Workshop on Formal Mehods for Indusrial Criical Sysems (FMICS 03), 2003, pp. 73 89. [7] Y. Cheon, G. Leavens, M. Siaraman, and S. Edwards, Model variables: cleanly supporing absracion in design by conrac: Research aricles, Sofw. Prac. Exper., vol. 35, no. 6, pp. 583 599, May 2005. [8] American Naional Sandards Insiue Inc., Role Based Access Conrol, 2004, ANSI-INCITS 359-2004. [9] J. M. Spivey, The Z noaion: a reference manual. Upper Saddle River, USA: Prenice-Hall, Inc., 1989. [10] OASIS, exensible Access Conrol Markup Language (XACML) TC, 2014, hps://www.oasis-open.org/commiees/xacml/. [11] OASIS, XACML v3.0 Core and Hierarchical Role Based Access Conrol (RBAC) Profile Version 1.0, 2014, hp://docs.oasis-open.org/ xacml/3.0/xacml-3.0-rbac-v1-spec-cd-03-en.hml. [12] Pivoal, Inc., Spring securiy 3.1.2, 2013, hp://saic.springsource. org/spring-securiy/sie/index.hml. [13] The Apache Sofware Foundaion, Apache shiro 1.2.1, 2013, hp: //shiro.apache.org/. [14] Y. Cheon, Auomaed random esing o deec specificaion-code inconsisencies, in Proc. of he 2007 In l Conf. on Sofware Engineering Theory and Pracice, Orlando, Florida, U.S.A., 2007. [15] C. Flanagan, K. R. M. Leino, M. Lillibridge, G. Nelson, J. B. Saxe, and R. Saa, Exended saic checking for Java, in Proc. of he ACM SIGPLAN Conf. on Prog. language design and implemenaion, 2002, pp. 234 245. [16] H. Hu and G.-J. Ahn, Enabling verificaion and conformance esing for access conrol model, in Proc. of he 13h ACM Symp. on Access Conrol Models and Technologies, 2008, pp. 195 204. [17] OSCAR EMR, OSCAR Elecronic Medical Records Sysem, 2014, hp://oscar-emr.com/. [18] J. Gyger and N.l Wesbury, JMoney Financial Sysem, 2014, hp: //jmoney.sourceforge.ne/. [19] Y. Jia and M. Harman, An analysis and survey of he developmen of muaion esing, IEEE Transacions on Sofware Engineering, vol. 37, no. 5, pp. 649 678, 2011. [20] M. Barne, R. Leino, and W. Schule, The spec# programming sysem: An overview, in Proc. of he 2004 In l Conf. on Consrucion and Analysis of Safe, Secure, and Ineroperable Smar Devices. Berlin: Springer-Verlag, 2005, pp. 49 69. [21] Oracle Inc., Java Plaform Enerprise Ediion, 2014, urlhp://www.oracle.com/echnework/java/javaee/overview/index.hml. [22] Google Inc., Android, 2014, hp://www.android.com. [23] G. McGraw, Sofware Securiy: Building Securiy In. Addison-Wesley, 2006. [24] A. Sabelfeld and A. C. Myers, Language-based informaion-flow securiy, IEEE J. Seleced Areas in Communicaions, vol. 21, no. 1, pp. 5 19, Jan. 2003. [25] N. Dragoni, F. Massacci, K. Naliuka, and I. Siahaan, Securiy-byconrac: Toward a semanics for digial signaures on mobile code, in Public Key Infrasrucure, ser. LNCS. Springer Berlin, 2007, vol. 4582, pp. 297 312. [26] H. Belhaouari, P. Konopacki, R. Laleau, and M. Frappier, A design by conrac approach o verify access conrol policies, in 17h In l Conf. on Engineering of Complex Compuer Sysems (ICECCS), july 2012, pp. 263 272.