shmat_ndss13fixmeup

8/12/2019 shmat_ndss13fixmeup

1/16

Fix Me Up: Repairing Access-Control Bugs in Web Applications

Sooel Son

Kathryn S. McKinley

Vitaly Shmatikov

The University of Texas at Austin Microsoft Research

{samuel,mckinley,shmat }@cs.utexas.edu

Abstract

Access-control policies in Web applications ensure that only authorized users can perform security-sensitive oper-ations. These policies usually check user credentials before executing actions such as writing to the database or navigating to privileged pages. Typically, every Web ap-

plication uses its own, hand-crafted program logic to enforce access control. Within a single application, this logiccan vary between different user roles, e.g., administrator or regular user. Unfortunately, developers forget to include proper access-control checks, a lot .

This paper presents the design and implementation of FIX MEUP , a static analysis and transformation tool that nds access-control errors of omission and produces can-didate repairs. FIX MEUP starts with a high-level speci-cation that indicates the conditional statement of a correct access-control check and automatically computes an interprocedural access-control template (ACT), which includesall program statements involved in this instance of access-control logic. The ACT serves as both a low-level policyspecication and a program transformation template. FIX -MEUP uses the ACT to nd faulty access-control logic that misses some or all of these statements, inserts only the miss-ing statements, and ensures that unintended dependencesdid not change the meaning of the access-control policy.FIX MEUP then presents the transformed program to the de-veloper, who decides whether to accept the proposed repair.

Our evaluation on ten real-world PHP applicationsshows that FIX MEUP is capable of nding subtle access-control bugs and performing semantically correct repairs.

1 IntroductionModern Web-based software, such as e-commerce appli-cations, blogs, and wikis, typically consists of client-sidescripts running in a Web browser and a server-side programthat (1) converts clients requests into queries to a back-end database and (2) returns HTML content. Because anyInternet user can invoke the server, application developersmust ensure that unauthorized users cannot reach database

queries, administrator functionality, pages with condentialor paid content, and other privileged operations.

Developers usually program access-control logic fromscratch because there is no standard framework for imple-menting access control in Web applications. Access-controllogic is often fairly sophisticated, spread over multiple func-tions, with different checks performed for different userroles [32, 36]. The scripting language of choice for server-side applications is PHP [27, 28]. In PHP, a network usercan directly invoke any program le by providing its nameas part of a URL. This feature introduces unintended entrypoints into programs and permits forced browsing, wherea user navigates to pages without following the intendedpattern and therefore bypasses access-control checks. As aconsequence, incorrectly implemented access-control vul-nerabilities occur prominently in the OWASP Top 10 Ap-plication Security Risks [24]. For example, all but one of the ten real-world PHP applications analyzed in this papercontain access-control vulnerabilities.

Whereas nding bugs is now a mature area, repairingthem is a much harder problem and only recently has someprogress been made on semi-automated methods for soft-ware repair. Static repair techniques can now x viola-tions of simple local patterns that need only one- or two-line edits [14, 25], or nd one- or two-line changes thatpass unit tests [41], or perform user-specied transforma-tions within a single method [1, 19]. None of these tech-niques address interprocedural bugs. Several recent meth-ods nd access-control bugs using interprocedural analy-sis [32, 36] but how to repair them has been an open prob-lem. A key issue for repairing these bugs is that many, butnot all of the statements implementing the access-control

logic are often already present in the vulnerable code. Noneof the prior patch, transformation, refactoring, or repair al-gorithms check if the statements are already present in thetarget of transformation.

We design and implement a static analysis and programtransformation tool called F IX MEUP. FIX MEUP nds vi-olations of access-control policies, produces candidate re-pairs, eliminates repairs that incorrectly implement the pol-icy, and suggests the remaining repairs to developers.


2/16

As input, F IX MEUP takes an access-control check, i.e.,a conditional statement that determines whether or notsome security-sensitive operation executes. These checks,marked by the developer or inferred by static analysis [32],serve as the high-level specication of the access-controlpolicy. Our analysis computes interprocedural control and

data dependences of the check, extracting an interproce-dural slice containing all program statements that imple-ment the access-control logic. F IX MEUP creates an access-control template (ACT) from these statements. The ACTserves both as a low-level policy specication and a pro-gram transformation template. F IX MEUP then uses theACT to (1) nd security-sensitive operations not protectedby appropriate access-control logic; (2) transform the pro-gram by inserting only the missing logic into the vulner-able calling contexts, while preserving the statements anddependences already present; and (3) verify the transforma-tion did not accidentally introduce unwanted dependences,changing the semantics of the inserted policy.

We evaluate F IX MEUP on ten real-world Web appli-cations varying in size from 1,500 to 100,000+ lines of PHP code. We chose these benchmarks because (i) priorwork used them to specify and/or infer access-control poli-cies [32, 36]; (ii) they contain known access-control bugsthat F IX MEUP nds and repairs; and (iii) they demonstratethe scalability of F IX MEUP.

F IX MEUP found 38 access-control bugs and correctlyrepaired 30 of them. We conrmed all bugs and repairs byhand and with experimental testing on attack inputs. In par-ticular, F IX MEUP found and repaired 5 bugs in two bench-marks that prior analysis of the same code missed [36]. In

7 cases, the inserted access-control check was added to anexisting, alternative check. In one case, our repair vali-dation procedure automatically detected an unwanted con-trol dependence and issued a warning. In 28 cases, F IX -MEUP detected that vulnerable code already contained oneor more, but not all, of the statements prescribed by theaccess-control template and adjusted the repair accordingly.This result shows that detecting which parts of the access-control logic are already present and correct is critical to re-pairing access-control vulnerabilities. No prior program re-pair or transformation approach detects whether the desiredlogic is already present in the program [1, 14, 19, 25, 41].

F IX MEUP guarantees that the repaired code implementsthe same access-control policy as the template, but it cannotguarantee that the resulting program is correct. For ex-ample, F IX MEUP may apply the policy to a context wherethe developer did not intend to use it, or the repair may in-troduce an unwanted dependence into the program (addingan access-control check always changes the programs con-trol ow). Static analysis in F IX MEUP is neither sound,nor complete because it does not consider language featuressuch as dynamic class loading, some external side effects,

or eval . The developer should examine the errors found byFIX MEUP and the suggested repairs.

Using automated program analysis tools for vericationand bug nding is now a well-established approach thathelps programmers discover errors and improve code qual-ity in large software systems. No prior tool, however, can

repair access-control errors of omission. These errors mayappear relatively simple, but our analysis shows that theyare common in Web applications. F IX MEUP is a new toolthat can help Web developers repair common access-controlvulnerabilities in their applications.

2 Overview of our approachFIX MEUP starts with a high-level specication of theaccess-control policy . A policy prescribes one or moreaccess-control checks on execution paths leading to sensi-tive operations , such as database queries, links to privilegedpages, operations that rewrite cookies and delete les. Sen-sitive operations must be specied in advance. If the checksfail, the program does not execute the sensitive operations.Because access-control logic varies between different userroles and entry points within the same application [32, 36],different paths may require different checks or no checks atall. Access-control logic in Web applications is often inter-procedural and context-sensitive.

FIX MEUP is agnostic about the source of the policy andworks equally well with user-specied policies and withpolicies inferred by program analysis. Our focus in this pa-per is on program repair and not on the orthogonal problemof policy specication or inference.

For simplicity, assume that the high-level policy is speci-

ed explicitly by the developer who adds annotations to thePHP source code marking (1) access-control checks, (2) theprotected sensitive operation, and (3) a tag indicating theuser role to which the policy applies (e.g., root, admin, orblog poster). Section 3 presents examples of specicationsand policies. F IX MEUP assumes that each high-level pol-icy applies throughout the indicated user role.

FIX MEUP uses this specication to compute an access-control template (ACT). F IX MEUP starts with the con-ditional statement performing the correct access-controlcheck and computes all methods and statements in its back-ward, interprocedural slice. Given this slice, F IX MEUPbuilds an interprocedural, hierarchical representation of all

statements in the checks calling context on which the check depends. The ACT is both a low-level policy specicationand a program transformation template.

To nd missing access-control checks, F IX MEUP looksat every calling context in which a sensitive operation maybe executed and veries whether the access-control logicpresent in this context matches the ACT for the correspond-ing role. Of course, F IX MEUP cannot decide general se-mantic equivalence of arbitrary code fragments. In practice,


3/16

the access-control logic of Web applications is usually verystylized and located close to the program entry points. Theresulting templates are loop-free, consist of relatively fewstatements, and have simple control and data dependences(see Table 2). A few statements may have side effects on theglobal variables, such as opening database connections and

initializing session state. For example, a typical Web appli-cation may open the database once and then permit only theauthorized users to store into the database; these stores maybe sprinkled throughout the application.

F IX MEUP generates candidate repairs by replicating theaccess-control logic in program contexts where some or allof it is missing. If F IX MEUP nds a vulnerable contextthat permits execution of some sensitive operation with-out an access-control check, it transforms the context usingthe access-control template. This transformation nds andreuses statements already present in the vulnerable code andonly inserts the statements from the template that are miss-ing. The repair procedure uses and respects all control and

data dependences between statements.To ensure that the reused statements do not change the

meaning of the inserted policy, F IX MEUP computes a freshtemplate starting from the access-control check and matchesit against the original template. If the templates do notmatch, F IX MEUP issues a warning. If they match, F IX -MEUP provides the transformed code to the developer asthe suggested repair.

3 Access-Control PoliciesAccess control is the cornerstone of Web-application secu-rity. Several of the OWASP Top 10 Application SecurityRisks [24] are access-control bugs: broken authentication

and session management, insecure direct object references,and failure to restrict URL accesses. Access-control bugscan expose other types of vulnerabilities, too.

3.1 Examples of correct policies and bugs

In general, an access-control policy requires some checksprior to executing security-sensitive operations . Web appli-cations frequently implement multiple user roles. For ex-ample, an online store may have customers and administra-tors, while a blogging site may have blog owners, publish-ers, and commenters. Access-control policies are thus role-sensitive. Different calling contexts associated with differ-ent user roles often require different checks.

Figures 1 and 2 show examples of access-control checksin real-world PHP applications. Figure 1 shows a correctcheck (line 4) in Add.php from minibloggie. Add.php in-vokes a dedicated verifyuser function that queries the userdatabase with the username and password. If vericationfails, the application returns the user to the login page.Figure 2 shows a correct check (line 3) performed by Ac-ceptBid.php in the DNscript application. It reads the hashtable containing the session state and checks the member

Add.php1 < ? . . .2 s e s s i o n s t a r t ( ) ;3 dbConnect ( ) ;4 i f ( ! v e r i f y u s e r ( ) ) { / / a c c e s s c o n t r o l c h ec k 5 header ( L o c a t i o n : . / l o g i n . p hp ) ;6 }7 . . . / / s e c u r i t y s e n s i t i v e o p e r a t i on8 $ sq l = INSERT INTO b log da t a SET us e r i d = $ id ,

s u b j e c t = $ s u b j e c t , m e s sa g e = $ m e ss a ge , d a t e t i m e= $da t e t im e ;

9 $ q u e r y = mysql query ( $sql ) ;10 . . .11 f u n c t i o n v e r i f y u s e r ( ) {12 . . . .13 s e s s i o n s t a r t ( ) ;14 g l o b a l $ u s e r , $p wd ;15 i f ( i s s e t ($ SESSION[ use r ] ) && i s s e t ($ SESSION[

pwd ] ) ) {16 $use r = $ SESSION[ u se r ] ;17 $pwd = $ SESSION[ pwd ] ;18 $ r e s u l t = mysql query ( SELECT use r , pa s sword

FROM blo gus ern ame WHERE us er = $us er ANDBINARY pass word = $pwd ) ;

19 i f ( mysql num rows ( $ r e su l t ) == 1 )20 r e t u r n t r u e ;21 }22 r e t u r n f a l s e ;23 }24 ?>

Figure 1: minibloggie: Access-control check

ag. Both access-control policies protect the same oper-ationa mysql query call site that updates the back-enddatabasebut with very different logic.

The access-control checks are role-specic. For exam-ple, the DNscript application has two roles. Figure 2 showsthe check for the regular user role and Figure 3 shows thecheck for the administrator role.

DelCb.php in Figure 2 shows an access-control bug in

the DNscript application: the check on $ SESSION forthe regular user role is present in AcceptBid.php , butmissing in DelCb.php . The developer either forgot thecheck or did not realize that any network user can directlyinvoke DelCb.php . The bottom of Figure 2 shows how F IX -MEUP repairs DelCb.php by replicating the correct access-control logic from AcceptBid.php (associated with the reg-ular user role). Similarly, Figure 3 shows how F IX MEUPrepairs an access-control bug in AddCat2.php (associatedwith the administrator role) by replicating the access-control check from Del.php .

Invalid control ow distinguishes access-control vulner-abilities from data-ow vulnerabilities, such as cross-sitescripting and SQL injection studied in prior work [13, 15,17, 39, 42]. The access-control policy determines if the useris authorized to perform a particular operation, regardlessof whether or not there are tainted data ows into the argu-ments of the operation.

3.2 Design patterns for access control

There is no standard access-control library or framework forWeb applications, thus each application implements access-


4/16

AcceptBid.php1 < ?2 s e s s i o n s t a r t ( ) ;3 i f ( ! $ SESSION[ member ]) { / / a c c e s s c o n t r o l c h ec k 4 header ( Loca t i on : l og in . php ) ;5 e x i t ;6 }7 i n c l u d e inc / con f ig . php ;8 i n c l u d e inc / conn . php ;9 . . . / / s e c u r i t y s e n s i t i v e o p e r a t i on

10 $q5 = mysql query ( INSERT INTO cl os e bi d ( i tem name ,s e l l e r n a m e , b i dd e r n a me , c l o s e p r i c e ) . $ s q l 5 ) ;

11 . . .12 ?>

DelCb.php1 < ? / / No a c c e s s c o n t r o l c h ec k 2 i n c l u d e inc / con f ig . php ;3 i n c l u d e inc / conn . php ;4 / / s e c u r i t y s e n s i t i v e o p e r a t i on5 $ d e l e t e = mysql query ( DELETE FROM cl os e bi d where

i t em name = . $ i t em name . ) ;6 i f ( $ d e l e t e ) {7 mysq l c lo se ( $conn ) ;8 . . .9 }

10 ?>

DelCb.php repaired by F IX MEUP1 < ?2 s e s s i o n s t a r t ( ) ; / / [ F i xM eU p r e p a i r ]3 i f ( ! $ SESSION[ member ]) { / / [ F i xM eU p r e p a i r ]4 header ( Loca t i on : l og in . php ) ; / / [ F i xM eU p r e p a i r ]5 e x i t ; / / [ F i xM eU p r e p a i r ]6 }7 i n c l u d e inc / con f ig . php ;8 i n c l u d e inc / conn . php ;9 / / s e c u r i t y s e n s i t i v e o p e r a t i on

10 $ d e l e t e = mysql query ( DELETE FROM cl os e bi d wherei t em name = . $ i t em name . ) ;

11 i f ( $ d e l e t e ) {12 mysq l c lo se ( $conn ) ;13 . . .14 }15 ?>

Figure 2: DNscript: Correct access-control check in Ac-ceptBid.php for the regular user role, a missing check inDelCb.php, and the repair by F IX MEUP

control policies in its own, idiosyncratic way. The variablesthat hold users credentials and authorization information,as well as the semantics of access-control checks, vary sig-nicantly from application to application. Fortunately, theytend to follow a stylized code design pattern.

Access control is typically enforced near the programsentry point. First, the program collects relevant information.For example, the SELECT query returns the users record

from the administrative database in minibloggie in Figure 1,while the session state variable holds user data in DNscriptin Figure 2. Typically, only a few security-critical vari-ables hold access-control informationfor example, vari-ables $user , $ pwd , and $result in minibloggieand theyare updated in a very small number of places. The corre-sponding program slice is thus relatively small. All of ourbenchmark applications exhibit these features (see Table 2).

Second, the application executes one or more condi-

Del.php1 < ?php2 s e s s i o n s t a r t ( ) ;3 i f ($ SESSION[ admin ] != 1) { / / a c c e s s c o n t r o l

c h e c k 4 header ( Loca t i on : l og in . php ) ;5 e x i t ;6 }7 i n c l u d e inc / conf i g . php ;8 i n c l u d e inc / conn . php ;9 . . . / / s e c u r i t y s e n s i t i v e o pe r at i on

10 $ s q l = mysql query ( DELETE FROM do ma i n l i s t WHEREdn name = . $dn name . ) ;

11 . . .12 ?>

AddCat2.php1 < ? / / No a c c e s s c o n t r o l c h ec k 2 i n c l u d e inc / conf i g . php ;3 i n c l u d e inc / conn . php ;4 . . . / / s e c u r i t y s e n s i t i v e o pe r at i on5 $ i n s e r t = mysql query ( INSERT INTO gen ca t ( cat name )

. $ v a l u e s ) ;6 . . .7 ?>

AddCat2.php repaired by F IX MEUP

1 < ?2 s e s s i o n s t a r t ( ) ; / / [ F i xM eU p r e p a i r ]3 i f ($ SESSION[ admin ] != 1) { / / [ F i xM eU p r e p a i r ]4 header ( Loca t i on : l og in . php ) ; / / [ F i xM eU p r e p a i r ]5 e x i t ; / / [ F i xM eU p r e p a i r ]6 }7 i n c l u d e inc / conf i g . php ;8 i n c l u d e inc / conn . php ;9 . . .

10 / / s e c u r i t y s e n s i t i v e o p e r a t i on11 $ i n s e r t = mysql query ( INSERT INTO gen ca t ( cat name )

. $ v a l u e s ) ;12 . . .13 ?>

Figure 3: DNscript: Correct access-control check inDel.php for the administrator role, a missing check in Ad-

dCat2.php, and the repair by F IX MEUP

tional statements that evaluate a predicate over security-critical variables. These statements implement the actualaccess-control checks, e.g., line 4 of Figure 1 and line 3of acceptBid.php in Figure 2. If the check fails, the pro-gram terminates or returns to the login page. Otherwise, itcontinues execution, eventually reaching the sensitive oper-ation protected by the check. In many applications, thesesteps are distributed over multiple functions and les, e.g.,the verifyuser function in Figure 1.

3.3 Specifying access-control policies

FIX MEUP takes as input an explicitly specied or inferredaccess-control policy. An access-control policy is a setof role-specic mappings from program statements execut-ing security-sensitive operationssuch as SQL queries andle operationsto one or more conditional statements thatmust be executed prior to these operations. Because thispaper focuses on program repair and not on policy speci-cation or inference (see Section 7 for a discussion of policysources), we limit our attention to policies specied by ex-


5/16

plicit annotation.The developer marks the access-control checks and the

security-sensitive operations and assigns them a user-roletag. This high-level specication informs F IX MEUP thatthe marked check must be performed before the marked op-eration in all calling contexts associated with the indicated

user role. In Figure 4, line 8 of admin.php shows an anno-tation that marks the access-control check with the adminrole tag. Lines 22 and 26 show the annotations for security-sensitive operations. F IX MEUP does not currently supportdisjunctive policies where operations may be protected byeither check A or check B .

Unlike GuardRails [3], F IX MEUP does not requirean external specication of all statements involved inaccess-control enforcement. Instead, F IX MEUP automati-cally computes access-control policies from the annotationsmarking the checks and the protected operations.

4 Access-Control Templates

This section describes how F IX MEUP computes access-control templates . We implemented this analysis in PHC,an open-source PHP compiler [26], and analyze PHC-generated abstract syntax trees (AST). We started by addingstandard call graph, calling context, data dependence, andcontrol dependence analyses to PHC.

F IX MEUP takes as input an explicit mapping from sensi-tive operations to correct access-control checks. F IX MEUPthen performs interprocedural program slicing on the callgraph and on the data- and control-dependence graphs of each method to identify the program statements on whicheach access-control check is data- or control-dependent.FIX MEUP converts each slice into a template, which serves

as a low-level specication of the correct policy logic anda blueprint for repair. Informally, the template contains allstatements in the checks calling context that are relevantto the check: (1) statements on which the check is data- orcontrol-dependent, and (2) calls to methods that return be-fore the check is executed but contain some statements onwhich the check is dependent.

4.1 Computing access-control slices

Given a conditional access-control check , FIX MEUP picksan entry which has the shortest call depth to check . FIX -MEUP iteratively computes the transitive closure of thestatements on which check is control- or data-dependent.This analysis requires the call graph, control-ow graphs,intraprocedural aliases, and intraprocedural def-use chains.For each call site, F IX MEUP computes an interproceduralsummary of side effects, representing the def-use informa-tion for every parameter, member variable, and base vari-able at this site. These analyses are standard compiler fareand we do not describe them further.

In general, a slice may execute an arbitrary computa-tion, but as we pointed out in Section 3, slices that perform

admin.php1 < ?2 i n c l u d e ( con f i gu r a t i on . php ) ; / / s l i c e & ACT 3 i n c l u d e ( fu nc t ion s . php ) ;4 r e q u i r e ( lan g / $ lan guage . php ) ;5 $ s e c u r i t y = y e s ; / / s l i c e & ACT 6 $ i n c l u d e s c r i p t = y es ;7 i f ( $ s e c u r i t y == y e s ) { / / s l i c e & ACT 8 / /@ACC( adm in )9 i f ( ( ! i s s e t ( $PHP AUTH USER) ) / / s l i c e & ACT

10 | | ( ! i s s e t ($PHP AUTH PW) )11 | | ($PHP AUTH USER != UT )12 | | ($PHP AUTH PW != UTCS ) ) {13 header ( WWW A u t h e n t i c a t e : B a s ic r e al m =

n e w s a d m i n i s t r a t i o n ) ; / / s l i c e & ACT 14 header ( HTTP/1 .0 401 Unau tho r i zed ) ; / / s l i c e &

ACT 15 echo < html >< head >< t i t l e > Access Den ied ! < / t i t l e

>< /hea d>< body> A u t h o r i z a t i o n R e q ui r e d . < / body >< /h tm l> ; / / s l i c e & ACT

16 e x i t ; / / s l i c e & ACT 17 } } . . .18 s w i t c h ( $ a c t i o n ) {19 c a s e c h ec k : c h ec k ( ) ; break ;20 c a s e add : / / @SSO( admin )21 add ( ) ;22 break ;23 c a s e de l e t e : / / @SSO( admin )24 d e l e t e ( ) ;25 break ;26 . . . } ?>

conguration.php1 < ?php . . .2 $PHP AUTH PW = $ SERVER[ PHP AUTH PW ]; / / s l i c e3 $PHP AUTH USER = $ SERVER[ PHP AUTH USER ]; / / s l i c e4 . . . ?>

Access-control template for admin users(m0 = admin . php ( p rog ram en t ry ) ,S0 = {

i n c l u d e ( con f i gu r a t i on . php ) ;$ s e c u r i t y = y e s ;i f ( $ s e c u r i t y == y e s ) {

i f ( ( ! i s s e t ( $PHP AUTH USER) )| | ( ! i s s e t ($PHP AUTH PW) )| | ($PHP AUTH USER != UT )| | ($PHP AUTH PW != UTCS ) ) {header ( WWW A u t h e n t i c a t e : B a s ic r e a lm =

n e w s a d m i n i s t r a t i o n ) ;header ( HTTP/1 .0 401 Unau tho r i zed ) ;echo < html >< head >< t i t l e > A c c es s D e n ie d ! < /

t i t l e >< /hea d>< body> A u t h o r i z a t i o nRequ i r ed . < / body >< /h tm l> ;

e x i t ; } } )

Figure 4: Newsscript: Slice and access-control template

access-control enforcement are typically loop-free compu-tations that rst acquire or retrieve user credentials or ses-sion state, and then check them. All of our benchmarksfollow this pattern. Statements in these slices update only asmall set of dedicated variables which are used in the check but do not affect the rest of the program. The exceptions areglobal variables that hold database connections and sessionstate. These variables are typically initialized before per-forming access control and read throughout the program.When F IX MEUP inserts code to repair vulnerabilities, ittakes care not to duplicate statements with side effects.


6/16

4.2 Computing access-control templates

Statements in a slice may be spread across multiple meth-ods and thus do not directly yield an executable code se-quence for inserting elsewhere. Therefore, F IX MEUP con-verts slices into templates.

An access-control template (ACT) is a hierarchical datastructure whose hierarchy mirrors the calling context of theaccess-control check. Each level of the ACT correspondsto a method in the context. For each method, the ACTrecords the statements in that method that are part of theslice. These statements may include calls to methods thatreturn before the access-control check is executed, but onlyif the call subgraphs rooted in these methods contain state-ments that are part of the slice.

The last level of the ACT contains the access-controlcheck and the failed-authorization code that executes if thecheck fails (e.g., termination or redirection). The developeroptionally species the failed-authorization branch. With-out such specication, F IX MEUP uses the branch that con-tains a program exit call, such as die or exit . We labeleach ACT with the programmer-specied user role from thechecks annotation.

Formally, ACT role is an ordered list of ( m i , S i ) pairs,where m i are method names and S i m i are ordered listsof statements. Each m i is in the calling context of check ,i.e., it will be on the stack when check executes. Each state-ment s S i is part of the access-control logic because (1)the check is data- or control-dependent on s , or (2) s isa callto a method n that contains such a statement somewhere inits call graph, but n returns before the check executes, or (3)s is a statement in the failed-authorization branch of check .

Consider the following example:1 m ai n ( ) {2 a = b ;3 c = c r e d e n t i a l s ( a ) ;4 i f ( c ) the n f a i l ( . . . ) ;5 p e rf o r m s e c u r i t y s e n s i t i v e o p e ra t i on6 }

The conditional statement if (c) is the access-control check and its calling context is simply main .The computed template ACT role includes the call tocredentials , as well as fail(...) in the branch cor-responding to the failed check. We add the following pairto the ACT role : (main , { a=b , c=credentials(a) ,if (c) then fail(...) }).

Figure 5 shows the algorithm that, given a calling contextand a slice, builds an ACT. The algorithm also constructsdata- and control-dependence maps, DD ACT and CD ACT ,which represent all dependences between statements in theACT. F IX MEUP uses them to (1) preserve dependences be-tween statements when inserting repair code, and (2) matchtemplates to each other when validating repairs. Figure 4gives an example of an access-control slice and the corre-sponding ACT from Newsscript 1.3.

GetACT (CC, SLICE) {1 // INPUT2 CC = { (cs 1 , m 0 ) , (cs 2 , m 1 ) . . . (check, m n )} : calling context of the

check, where cs i +1 m i is the call site of m i +13 SLICE : statements on which the check is data or control dependent

and statements executed when authorization fails4 // OUTPUT5 ACT : template {(m i , s i )} , where s i is an ordered list of statements in

method m i6 DD ACT , CD ACT : data and control dependences in ACT7 8 ACT 9 ACT.CC src C C

10 BuildACT ( m 0 , CC , SLICE)11 DD ACT = { ( s k , s j ) s.t. s k,j ACT and s k is data dependent on s j }12 CD ACT = {( s k , s j ) s.t. s k,j ACT and s k is control dependent on s j }1314 return AC T 15 }

BuildACT ( m i , CC, SLICE) {1 S i 2 j 03 for (k = 0 to | m i | , s k m i ) { // | m i | is the number of statements in m i4 if (s k SLICE) {5 S i [j + +] = s k6 }7 if (s k is a callsite s. t . (s k , m i +1 ) CC ) {8 BuildACT ( m i +1 , CC , SLICE)9 }

10 }11 ACT { (m i , S i )} ACT 12 }

Figure 5: Computing an access-control template (ACT)

5 Finding and Repairing VulnerabilitiesWe rst give a high-level overview of how F IX MEUP ndsvulnerabilities, repairs them, and validates the repairs, andthen we describe each step in more detail.

FIX MEUP considers all security-sensitive operations inthe program. Recall that each sensitive operation is asso-ciated with a particular user role (see Section 3.3). Foreach operation, F IX MEUP computes all of its calling con-texts. For each context, it considers all candidate checks,computes the corresponding access-control template ACT ,and compares it with the roles access-control templateACT role . If some context C C tgt is missing the check, itsACT will not match ACT role . This context has an access-control vulnerability and F IX MEUP targets it for repair.

To repair CC tgt , FIX MEUP inserts the code fromACT role into the methods of CC tgt . ACT role containsthe calling context CC src of a correct access-control check

and F IX MEUP uses it to guide its interprocedural repairof CC tgt . FIX MEUP matches CC src method by methodagainst CC tgt . At the last matching method m inline , FIX -MEUP inlines all statements from the methods deeper inCC src than m inline into m inline . We call this adaptingthe ACT to a target context. Adaptation produces a methodmap indicating, for each m src ACT role , the methodm tgt CC tgt where to insert statements from m src .

For each statement in ACT role , FIX MEUP inserts state-


7/16

ments from m src into the corresponding m tgt only if theyare missing from m tgt . In the simplest case, if the vulner-able context has only the entry method and no code thatcorresponds to any code in ACT role , FIX MEUP inserts theentire template into the entry method.

A repair can potentially introduce two types of undesired

semantic changes to the target code. First, statements al-ready present in the target may affect statements insertedfrom the template. We call these unintended changes tothe inserted policy . Second, inserted statements may affectstatements already present in the target. We call these unin-tended changes to the program . Because our analysis keepstrack of all data and control dependences and because ourrepair procedure carefully renames all variables, we preventmost of these errors. As we show in Section 6, F IX MEUPdetects when template statements with side effects are al-ready present in the program and does not insert them.

To validate that there are no unintended changes to aninserted policy, F IX MEUP computes a fresh ACT from therepaired code and compares it with the adapted ACT . If they match, F IX MEUP gives the repaired code to the devel-oper; otherwise, it issues a warning.

5.1 Matching templates

To nd vulnerabilities and validate repairs, F IX MEUPmatches templates. In general, it is impossible to de-cide whether two arbitrary code sequences are semanticallyequivalent. Matching templates is tractable, however, be-cause ACTs of real-world applications are loop-free andconsist of a small number of assignments, method invoca-tions, and conditional statements. Furthermore, when de-

velopers implement the same access-control policy in mul-tiple places in the program, they tend to use structurallyidentical code which simplies the matching process.

Figure 6 shows our template matching algorithm and thestatement matching algorithm that it uses. The latter algo-rithm compares statements based on their data and controldependences, and therefore the syntactic order of statementsdoes not matter. Matching is conservative: two matchingtemplates are guaranteed to implement the same logic.

Let ACT x and ACT y be two templates. For everys x ACT x , FIX MEUP determines if there exists only onematching statement s y ACT y , and vice versa. The de-velopers may use different names for equivalent variablesin different contexts, thus syntactic equivalence is too strict.Given statements sx ACT x and sy ACT y , FIX MEUPrst checks whether the abstract syntax tree structures andoperations of sx and sy are equivalent. If so, sx and sy aresyntactically isomorphic, but can still compute different re-sults. F IX MEUP next considers the data dependences of sxand sy . If the dependences also match, F IX MEUP declaresthat the statements match. Table 1 shows the matching ruleswhen neither statement has any dependences.

isMatchingACT ( ACT x , ACT y ) {1 // INPUT: two ACTs to be compared2 // OUTPUT: true if ACT x and ACT y match, false otherwise34 if (| ACT x | = | ACT y | ) return false ;56 V arMap 7 StatementMap 8 for ( s x AC T x in order ) {9 if ( only one (s x , s y ) s.t. s y AC T y and isMatching (s x , s y ) ) {

10 StatementMap S tatementMap {( s x , s y )}11 } else {12 return false ;13 }14 }15 return true ;16 }

isMatching ( s src , s tgt ) {1 // INPUT: statements s src AC T , s tgt m tgt to be compared2 // OUTPUT: true if s src and s tgt match, false otherwise3 V arMap : updated variable mappings45 if ( ( s src , s tgt ) S tatementMap ) return true6 7 if (AST structures of s src and s tgt are equivalent) {8 m src method containing s src AC T 9 DD src { ( s src , d ) s.t. s src is data dependent on d m src }

10 DD tgt { ( s tgt , d ) s.t. s tgt is data dependent on d m tgt }11 if (DD src and DD tgt ) {12 // no data dependences13 if ( s src and s tgt are one of the types described in Table 1 ) {14 if (s src = vx = C x and s tgt = v y = C y and15 constants C x and C y are equal) {16 V arMap = V arMap {(v x , v y )}17 }18 return true19 } else return false20 } else if (| DD src | == | DD tgt | ) {21 if (( s src , d x ) DD src , ( s tgt , d y ) DD tgt and

(d x , d y ) S tatementMap ) {22 if (s src = vx = . . . and s tgt = vy = . . . ) {23 V arMap = V arMap {(v x , v y )}24 }25 return true26 } } }27 return false28 }

Figure 6: Matching access-control templates

5.2 Finding access-control vulnerabilities

For each security-sensitive operation ( sso ), FIX MEUPcomputes the tree of all calling contexts in which it mayexecute by (1) identifying all methods that may directly in-voke sso and (2) performing a backward, depth-rst passover the call graph from each such method to all possibleprogram entries. F IX MEUP adds each method to the call-ing context once, ignoring cyclic contexts, because it only

needs to verify that the access-control policy is enforcedonce before sso is executed.

For each calling context CC in which sso may beexecuted, F IX MEUP rst nds candidate access-controlchecks. A conditional statement b is a candidate check if it(1) controls whether sso executes or not, and (2) is syntacti-cally equivalent to the correct check given by the ACT role .For each such b, FIX MEUP computes its slice, converts itinto ACT b using the algorithms in Figure 5, and checks


8/16

method a (C 0 ,...,C i ) method b (C 0 , ...,C i ) Match if (1) method a = method b and (2) all constants C k = C klocalvar a = C method i localvar b = C method k Match if (1) method i = method k or both methods are entry methods

and (2) constants C = C globalvar a = C method i globalvar b = C method k Match if (1) globalvar a = globalvar b and (2) constants C = C

Table 1: Matching statements without dependences

whether ACT b matches ACT role . If so, this context al-ready implements correct access-control logic. Otherwise,if there are no candidate checks in the context or if none of the checks match the correct check, the context is vulnera-ble and F IX MEUP performs the repair.

DoRepair ( ACT , CC tgt ) {1 // INPUT2 ACT : access control template specication3 CC tgt = {(cs 1 , m 0 ) , (cs 2 , m 1 ) . . . ( sso, m n )} : calling context of the

vulnerable security sensitive operation sso

4 // OUTPUT5 RepairedAST : repaired program AST6 MatchCount : number of ACT statements already in the target7 8 MethodMap // Initialize maps between ACT and target context9 StatementMap

10 V arMap 1112 ACT adapted = AdaptACT ( ACT,CC tgt )13 (RepairedAST, InsertedCheck,M atchCount ) 14 ApplyACT ( ACT adapted , CC tgt )15 if ( ValidateRepair ( ACT adapted , InsertedCheck )) {16 return (RepairedAST, MatchCount )17 }18 return warning19 }

ValidateRepair ( ACT orig , I nsertedCheck ) {1 // INPUT2 ACT orig : applied access control template3 InsertedCheck : inserted access control check 4 // OUTPUT:5 true if extracted ACT from the repaired code matches AC T orig6 7 SEEDS { InsertedCheck, exit branch of I nsertedCheck }8 newSLICE doSlicing ( SEEDS )9 newCC calling context of I nsertedCheck

10 ACT repair GetACT ( newSLICE , newCC )11 return isMatchingACT ( ACT orig , ACT repair )12 }

Figure 7: Repairing vulnerable code and validating the re-pair

5.3 Applying the template

Formally, CC src = {(cs 1 , m 0) . . . (check, m n )}, CC tgt ={(cs 1 , m 0) . . . (sso,m l )}, where cs i +1 m i , cs i +1 m iare the call sites of m i +1 , m i +1 respectively. For simplicity,we omit the subscript from ACT role .

F IX MEUP uses DoRepair in Figure 7 to carry out a re-pair. It starts by adapting ACT to the vulnerable callingcontext CC tgt . If CC tgt already invokes some or all of the methods in ACT , we do not want to repeat these callsbecause the policy species that they should be invoked

only once in a particular order. After eliminating redun-dant method invocations, F IX MEUP essentially inlines theremaining logic from ACT into ACT adapted .

Formally, the algorithm nds common method invo-cations in CC src and CC tgt by computing the deepestm inline CC src such that for all i inline m i matchesm i . For i = 0 , m0 and m0 match if they are both entrymethods. For i 1, m i and m i match if they are invo-cations of exactly the same method. The rst for loop in AdaptACT from Figure 8 performs this process.

The algorithm then adapts ACT to CC tgt by inliningthe remaining statementsthose from the methods deeperthan m inline in ACT into m inline . The second for loopin AdaptACT from Figure 8 performs this process and pro-duces ACT adapted . While matching methods and inliningstatements, F IX MEUP records all matching method pairs(m i , m i ), including m inline , in MethodMap .

In the simplest case, the entry m 0 CC tgt is the onlymethod matching m inline = m 0 . In this case, F IX MEUPinlines every statement in ACT below m 0 and produces aattened ACT adapted .

Otherwise, consider the longest matching method se-

quence (m 0 . . . m inline ) and (m 0 . . . m inline ) in CC srcand CC tgt , respectively. For 1 i inline 1, m i and m iare exactly the same; only m 0 and m inline are distinct fromm 0 and m inline , respectively. AdaptACT stores the (m 0 ,m 0 ) and (m inline ,m inline ) mappings in MethodMap .

FIX MEUP uses the resulting template ACT adapted to re-pair the target context using the ApplyACT algorithm in Fig-ure 9. This algorithm respects the statement order, controldependences, and data dependences in the template. Fur-thermore, it avoids duplicating statements that are alreadypresent in the target methods.

The algorithm iterates m src over m 0 and m inline inACT adapted because, by construction, these are the only

methods that differ between the template and the target. Itrst initializes the insertion point ip tgt in m tgt correspond-ing to m src in MethodMap . The algorithm only insertsstatements between the beginning of m tgt and the sensi-tive operation sso , orif m tgt calls other methods to reachsso the call site of the next method in the calling contextof sso . Intuitively, the algorithm only considers potentialinsertion points and matching statements that precede sso .

Before F IX MEUP inserts a statement s , it checks if there


9/16

AdaptACT ( ACT src , CC tgt ) {1 // Adapt ACT src to the target context CC tgt23 ACT clone ACT src4 CC src = ACT.CC src5 l 06 7 for ( i = 0; i < | CC src | ; i++ ) {8 // iterate from the entry to the bottom method in CC src9 m i i th method in CC src

10 m tgt i th method in CC tgt11 if ( m i and m tgt are entries or m i == m tgt ) {12 MethodMap MethodMap {(m i , m tgt )}13 l i14 } else break ;15 }16 m inline l th method in CC tgt17 for ( k = l +1 ; k < | CC src | ; k++ ) {18 inline method m k from CC src into m inline in ACT 19 MethodMap MethodMap {(m k , m inline )}20 }21 return ACT 22 }

Figure 8: Adapting ACT to a particular calling context

already exists a matching statement s m tgt . If so, FIX -MEUP adds s and s to StatementMap , sets the currentinsertion point ip tgt to s , and moves on to the next state-ment. Otherwise, it inserts s as follows:

1. Transform s into s by renaming variables.2. If s is a conditional, insert empty statements on the true

and false branches of s .3. If ip tgt has not been set yet, insert s at the top of m tgt .4. Otherwise, if s is immediately control-dependent on

some conditional statement t , insert s as the last state-ment on the statement list of the matching branch of the corresponding conditional t m tgt .

5. Otherwise, insert s after ip tgt , i.e., as the next state-ment on the statement list containing ip tgt . For exam-ple, if ip tgt is an assignment, insert s as the next state-ment. If ip tgt is a conditional, insert s after the trueand false clauses, at the same nesting level as ip tgt .

6. Add (s, s ) to StatementMap and set ip tgt to s . ApplyACT returns the repaired AST, the inserted check,

and the number of reused statements.

Variable renaming. When F IX MEUP inserts statementsinto a method, it must create new variable names that do notconict with those that already exist in the target method.Furthermore, because F IX MEUP, when possible, reuses ex-isting statements that match statements from the ACT se-

mantically (rather than syntactically), it must rename vari-ables. Lastly, as the algorithm establishes new names andmatches, it must rewrite subsequent dependent statementsto use the new names. The isMatching function in Figure 6establishes a mapping between a variable name from thetemplate and a variable name from the target method whenit matches assignment statements.

As F IX MEUP inserts subsequent statements, it uses thevariable map to replace the names from the template. Be-

ApplyACT ( ACT,CC tgt ) {1 // Insert statements only in entry and/or last method of CC tgt that

matches a method from adapted ACT . Other methods match ACT exactly (see AdaptACT).

2 // INPUT3 ACT : access control template4 CC tgt = { (cs 1 , m 0 ) , (cs 2 , m 1 ) . . . ( sso, m n )} : calling context of the

vulnerable sensitive operation sso5 // OUTPUT6 RepairedAST : AST of the repaired code7 InsertedCheck : inserted access control check 8 MatchCount : number of ACT statements found in the target9

10 MatchCount 011 InsertedCheck null12 m 0 the entry of ACT 13 m inline the method containing check in ACT 14 for ( m src {m 0 , m inline } ) {15 ip tgt null16 m tgt MethodMap (m src )17 for ( s AC T (m src ) in order ) {18 // Is there a statement after ip tgt in m tgt that matches s ?19 s FindMatchingStmt ( s,ip tgt , m tgt )20 if (s = null ) { // target method already contains s21 ip tgt s22 MatchCount ++23 } else { // no match, insert s into target

24 (t, d ) a pair of statement t and direction d s.t. s is immediately control dependent on t in d25 s RenameVars( s, m tgt ) // rename variables in s for m tgt26 if (s is a conditional statement ) { // add two branches27 add true and false branches to s with empty statements28 if (s is the access control check)29 InsertedCheck s30 }31 if (ip tgt == null ) {32 insert s at the rst statement in m tgt33 } else if (t = null ) { // s is immediately control dependent on t34 // insert on the corresponding conditional branch35 t S tatementMap ( t )36 insert s at the last statement on branch d of t37 } else { insert s immediately after ip tgt in m tgt }38 ip tgt s39 StatementMap S tatementMap {( s, s )}40 } } }41 RepairedAST s all modied ASTs of m tgt MethodMap42 return (RepairedASTs , I nsertedCheck , M atchCount )43 }

RenameVars ( s, m tgt ) {1 // INPUT: s AC T , target method m tgt2 // OUTPUT: s with variables remapped, updated V arMap3 s clone s4 if (s = v ACT = . . . and vACT is local) {5 if ( t s.t. (vACT , t ) V arMap ) {6 V arMap V arMap {(v ACT , v new )}7 }}8 for (v s ) {9 if ((v, v new ) V arMap )

10 replace v with vnew in s11 }12 return s13 }

Figure 9: Applying an access-control template

fore ApplyACT inserts a statement, it calls RenameVars toremap all variable names to the names used by the targetmethod. For unmapped variables, RenameVars creates freshnames that do not conict with the existing names.

Dealing with multiple matching statements. In theory,there may exist multiple statements in m tgt that match s


10/16

FindMatchingStmt( s,ip tgt , m tgt ) {1 // INPUT:2 s: statement in ACT 3 ip tgt : last inserted statement in m tgt45 if (m tgt contains the sensitive operation sso )6 SL = { statements in m tgt after ip tgt that dominate sso }7 else8 SL = { statements in m tgt after ip tgt that dominate the callsite of next

method in CC tgt }9 for (t SL ) {

10 if (isMatching ( s, t ) ) {11 StatementMap S tatementMap {( s, t )}12 return t13 }14 // If multiple statements in SL match s , they are handled as described in

Section 5.315 }16 return null17 }

Figure 10: Matching statements

and thus multiple ways to insert AC T adapted into the tar-get context. Should this happen, F IX MEUP is designed

to exhaustively explore all possible matches, generate thecorresponding candidate repairs, and validate each candi-date. F IX MEUP picks the validated candidate that reusesthe most statements already present in the target and sug-gests it to the developer.

5.4 Validating repairs

As mentioned above, F IX MEUP can potentially introducetwo types of semantic errors into the repaired program: (1)unintended changes to the inserted policy , and (2) unin-tended changes to the program . Unintended changes to theinserted policy may occur when existing statements changethe semantics of the inserted code. Unintended changes to

the program may occur when the inserted code changes thesemantics of existing statements.To detect type (1) errors, F IX MEUP computes afresh an

ACT from the repaired code and compares itusing Vali-dateRepair from Figure 7with the ACT on which the re-pair was based. An ACT captures all control and data de-pendences. Any interference from the existing statementsthat affects the inserted code must change the dependencesof the inserted statements. For example, suppose the reusedstatement has dependent statements already in the programthat are not part of the ACT. In this case, the ACTs will notmatch and F IX MEUP will issue a warning. This validationprocedure guarantees that reusing an existing statement isalways safe. We examined all 38 repairs suggested by F IX -MEUP for our benchmarks (see Section 6) and in only onecase did the insertion of the repair code change the ACTsemantics. F IX MEUPs validation algorithm detected thisinconsistency and issued a warning.

With respect to type (2) errors, unintended changes to theprogram, observe that the actual purpose of the repair is tochange the programs semantics by adding access-controllogic. F IX MEUP therefore cannot guarantee that the re-

paired program is free from type (2) errors because it cannotknow the full intent of the programmer.

The purpose of repair is to introduce a new dependence:all statements after the inserted access-control check be-come control-dependent on the check, which is a desired se-mantic change. Because F IX MEUP inserts the check along

with the statements dening the values used in the check,the inserted access-control logic may change both controland data dependences of statements that appear after thecheck. Our repair procedure minimizes the risk of unin-tended dependences by reusing existing statements as muchas possible and by renaming all variables dened in thetemplate to fresh names, thus preventing unintended depen-dences with the variables already present in the program.In just one of the 38 repairs on our benchmarks (see Fig-ure 14 in Section 6) did an incorrectly annotated role causeFIX MEUP to repair a context that already implemented adifferent access-control policy and thus introduce unwantedchanges to the program.

5.5 Discussion and limitations

Good program analysis and transformation tools help de-velopers produce correct code. They are especially usefulfor subtle semantic bugs such as inconsistent enforcementof access-control policies, but developers must still be inti-mately involved in the process. The rest of this section dis-cusses the general limitations of any automated repair tooland the specic limitations of our implementation.

Programmer burden. Suggesting a repair, or any pro-gram change, to developers requires some specicationof correct behavior. We rely on developers to annotate

access-control checks and security-sensitive operations intheir applications and tag them with the corresponding userrole. We believe that this specication burden is relativelylight and, furthermore, it can be supported by policy in-ference tools [32]. We require that the specications beconsistent for all security-sensitive operations in a givenrole. If the programmer wants different checks in differ-ent contexts for the same operation, the specication wontbe consistent and our approach will attempt to conserva-tively over-protect the operation. For example, Figure 11shows that F IX MEUP inserts a credential check performedin one context into a different context that already performsa CAPTCHA check, in this case introducing an unwanted

duplicate check. Developers should always examine sug-gested repairs for correctness.

We believe that the consequences of access-control er-rors are sufciently dire to motivate the developers to bearthis burden in exchange for suggested code repairs, since itis easier to reject or manually x a suggested change than itis to nd the error and write the entire repair by hand. Thelatter requires systematic, tedious, error-prone examinationof the entire program and its call graph. Language features


11/16

of PHP, such as the absence of a proper module system, dy-namic typing, and eval , further complicate this process forPHP developers. The number of errors found by F IX MEUPin real-world PHP applications attests to the difculty of correctly programming access control in PHP.

Static analysis. FIX MEUP uses a standard static interpro-cedural data- and control-dependence analysis to extract theprogram slice representing the access-control logic. Be-cause this analysis is conservative, the slice could containextraneous statements and therefore would be hard to ap-ply as a transformation. Program slicing for more generaldebugging purposes often produces large slices [34]. Fortu-nately, access-control policies are typically self-containedand much more constrained. They consist of retrievingstored values into local variables, checks on these variables,and code that exits or restarts the program after the check fails. Consequently, access-control templates tend to beshort (see Table 2).

Our F IX MEUP prototype does not handle the dynamiclanguage features of PHP, nor does it precisely model allsystem calls with external side effects. In particular, theanalysis resolves dynamic types conservatively to build thecall graph, but does not model eval or dynamic classloading, which is unsound in general. In practice, onlymyBB uses eval and we manually veried that there areno call chains or def-use chains involving eval that lead tosecurity-sensitive operations, thus eval does not affect thecomputed ACTs.

Static analysis can only analyze code that is present atanalysis time. PHP supports dynamic class loading and thuspotentially loads classes our code does not analyze. How-

ever, our benchmarks use dynamic class loading in only afew cases, and we do analyze the classes they load. To han-dle these cases, we annotated 18 method invocations withthe corresponding dynamic methods to generate a soundcall graph that includes all possible call edges.

Our analysis models database connections such asopen, close, and write, le operations that return ledescriptors, etc., but it does not perform symbolicstring analysis on the arguments. This is a pos-sible source of imprecision. For example, considertwo statements: writeData("a.txt",$data) and$newdata = readData($b) . If $b is a.txt, the sec-ond statement is data-dependent on the rst. A more precise

algorithm would perform symbolic analysis to determine if the two statements may depend on each other and conserva-tively insert a dependence edge. Not doing this makes ouranalysis unsound in general, but in practice, we never ob-served these types of dependences. Therefore, even a moreconservative analysis would have produced the same resultson our benchmarks.

Statement matching is weaker than semantic equiva-lence. For example, our matching algorithm does not cap-

ture that statements a = b+ c and a = add (b, c) are equiva-lent. Another minor limitation of our matching algorithm isthe use of coarse-grained statement dependences instead of variable def-use chains on the remapped variable names. Amore precise algorithm would enforce consistency betweenthe def-use information for each variable name var x used in

sx and var y used in sy , even if the names are not the samegiven the variable mapping produced thus far. The currentalgorithm may yield a match with an inconsistent variablemapping in distinct statements and thus change the def-usedependences at the statement level. We never encounteredthis problem in practice and, in any case, our validation pro-cedure catches errors of this type.

6 EvaluationWe evaluate F IX MEUP on ten open-source interactive PHPWeb applications, listed in Table 2. We chose SCARF,YaPiG, AWCM, minibloggie, and DNscript because theywere analyzed in prior work on detecting access-controlvulnerabilities [32, 36]. Unlike F IX MEUP, none of the pre-vious techniques repair the bugs they nd. In addition torepairing known vulnerabilities, F IX MEUP found four newvulnerabilities in AWCM 2.2 and one new vulnerability inYaPiG that prior analysis [36] missed. We added Newss-cript and phpCommunityCal to our benchmarks becausethey have known access-control vulnerabilities, all of whichFIX MEUP repaired successfully. To test the scalability of FIX MEUP, we included two relatively large applications,GRBoard and myBB. Table 2 lists the lines of code (LoC)and total analysis time for each application, measured on aLinux workstation with Intel dual core 2.66GHz CPU with

2 GB of RAM. Analysis time scales well with the numberof lines in the program.Our benchmarks are typical of server-side PHP applica-

tions: they store information in a database or local le andmanage it based on requests from Web users. Table 2 showsthat four applications have a single access-control policythat applies throughout the program. The other six have twouser roles each and thus two role-specic policies. Policieswere specied by manual annotation. They are universal,i.e., they prescribe an access-control check that must be per-formed in all contexts associated with the given role.

FIX MEUP nds 38 access-control bugs, correctly re-pairs 30 instances, and issues one warning. Nine of the ten

benchmarks contained bugs. Seven bugs were previouslyunknown. As mentioned above, ve of the previously un-known bugs appeared in applications that had been analyzedin prior work which missed the bugs. Five of the ten appli-cations implement seven correct, but alternative policies insome of their contexts (i.e., these policies differ from thepolicy in the template).

The fourth and fth columns in Table 2 characterize theaccess-control templates; the third column lists the user role


12/16

Analysis Role ACT missing alternative inserted policies unwantedWeb applications LoC time (s) tag instances LoC checks policies partial full warn side effects

minibloggie 1.1 2,287 26 admin 2 6 1 0 0 0 1 0DNscript 3,150 22 admin 14 4 3 0 0 3 0 0

normal 8 4 1 1 1 1 0 0Events Lister 2.03 2,571 24 admin 9 4 2 1 0 3 0 0

Newsscript 1.3 2,635 65 admin 1 8 1 0 1 0 0 0SCARF (before patch) 1,490 40 admin 4 4 1 0 1 0 0 0normal 1 4 0 0 0 0 0 0

YaPiG 0.95 7,194 250 admin 3 5 0 0 0 0 0 0normal 3 11 1 1 2 0 0 1

phpCommunityCal 4.0.3 12,298 367 admin 5 8 12 0 12 0 0 0AWCM 2.2 11,877 1221 admin 38 8 0 0 0 0 0 0

normal 8 4 4 3 6 1 0 0GRBoard 1.8.6.5 50,491 1742 admin 14 4 2 0 1 1 0 0

normal 9 4 3 1 4 0 0 0myBB 1.6.7 107,515 5133 admin 38 2 0 0 0 0 0 0

normal 31 8 0 0 0 0 0 0

totals 31 7 28 9 1 1

Table 2: PHP benchmarks, analysis time in seconds, ACT characterization, and repair characterization

to which each policy applies. Six applications have twopolicies, admin or normal . The fourth column shows thetotal instances of the template in the code, showing that de-velopers often implement the same access-control logic inmultiple places in the program. For example, the DNscriptapplication has two roles and thus two role-specic access-control policies. Out of the 22 templates in DNscript, only2 are unique. The LoC column shows the size of eachtemplate (in AST statements). The templates are relatively

small, between 2 and 11 statements each.The missing checks and alternative policies columnsin Table 2 show that F IX MEUP nds a total of 38 miss-ing checks. The alternative policies column shows that inseven cases F IX MEUP inserts an access-control policy, butthat the target code already has a different check. Figure 11shows a code example of this case, where process.php isrepaired using the policy from AddDn.php . However, italready contained a different, CAPTCHA-based check.

The inserted polices columns shows that F IX MEUPmade 37 validated repairs with one warning, 30 of whichxed actual vulnerabilities. For the other 7, the pro-gram already contained alternative logic for the samerole (e.g., CAPTCHA vs. login). The case that gen-erated the warning is shown in Figure 12. F IX MEUPonly inserts statements that are missing from the tar-get. In minibloggie, the statements session start()and dbConnect() are both in the template and in Del.php , thus F IX MEUP does not insert them. It onlyinserts the missing statement if (!verifyuser()){header (Location: ./login.php); }. Theaccess-control check at line 10, however, now depends on

AddDn.php1 < ?2 s e s s i o n s t a r t ( ) ;3 i f ( ! $ SESSION[ member ]) {4 header ( Loca t i on : l og in . php ) ;5 e x i t ;6 } . . .7 ?>

Process.php1 < ?2 s e s s i o n s t a r t ( ) ; / / e x i s t i n g s t at e me n t 3 i f ( ! $ SESSION[ member ]) { / / [ F i xM eU p r e p a i r ]4 header ( Loca t i on : l og in . php ) ; / / [ F ix Me Up r e p a i r

]5 e x i t ; / / [ F i xM eU p r e p a i r ]6 }7 . . .8 $number = $ POST[ image ] ;9 i f ( md5 ( $number ) != $ SESSION[ imag e rando m value ] ) {

10 echo Ve r i f i c a t i o n d o es n o t m at ch . . Go b ac k a ndr e f r e s h y ou r b r o ws er a nd t h en r e t y p e y ou rv e r i f i c a t i o n ;

11 e x i t ( ) ;12 }13 \ ?>

Figure 11: DNscript: Different access-control checkswithin the same user role

the conditional at line 7. This dependence did not exist inthe original ACT and does not pass F IX MEUP validation.

The partial and full columns shows that, in 28 of 38 attempted repairs, F IX MEUP reused some of the exist-ing statements in the target when performing the repair, andonly in 9 cases did it insert the entire template. This reusedemonstrates that repairs performed by F IX MEUP are notsimple clone-and-patch insertions, and adapting the tem-


13/16

Attempted repair of Del.php1 < ? . . .2 s e s s i o n s t a r t ( ) ; / / e x i s t i n g s t at e m en t 3 . . .4 i f ( $conf i rm == ) {5 n o t i c e ( C o n f i r m a t i o n , Wa rn i ng : Do y o u w a nt t o

d e le t e t h i s p os t ? < a h r e f = d e l . p hp ? p o s t i d = .$po s t i d . &conf i rm=yes > Yes < /a> ) ;

6 }7 e l s e i f ( $con f i rm==yes ) {8 dbConnect ( ) ; / / e x i s t i n g s t at e m en t 9

10 i f ( ! v e r i f y u s e r ( ) ) / / [ F i xM eU p r e p a i r ]11 {12 header ( Loca t io n : . / lo gi n . php ) ; / / [F ixMeUp

r e p a i r ]13 }14

15 $sq l = DELETE FROM bl ogd ata WHERE p os t id =$ p o s t i d ;

16 $ q u e r y = mysql query ( $ s q l ) o r d i e ( Canno t que ryt h e d a t a ba s e . < br > . m y s q l e r r o r ( ) ) ;

17 $ c o n f i r m = ;18 n o t i c e ( D e l P o s t , D a t a D e l e t e d ) ;19 }20 ?>

Access-control template of minibloggie1 < ?2 1 . P r o g r am E n t r y3 i n c l u d e con f . php ;4 i n c l u d e o n c e i n c l u d e s . p hp ;5 s e s s i o n s t a r t ( ) ;6 dbConnect ( ) ;7 i f ( ! v e r i f y u s e r ( ) ) {8 header ( Loca t i on : . / l o g in . php ) ;9 }

10 ?>

Figure 12: minibloggie: Attempted repair

plate for each target is critical to successful repair.Figure 13 shows repairs to GRBoard in remove

multi file.php and swfupload ok.php . These two lesimplement different access-control logic to protect role-specic sensitive operations. Observe that $GR variable inswfupload ok.php is not renamed and the existing vari-able is used instead, i.e., $GR = new COMMON() at line4. On the other hand, in remove multi file.php , FIX -MEUP denes a new variable $GR newone to avoid un-wanted dependences when it inserts this statement.

Figure 11 also shows how F IX MEUP leaves line 2 in-tact in process.php when applying the template based onAddDn.php . This reuse is crucial for correctness. HadFIX MEUP naively inserted this statement from the templaterather than reuse the existing statement, the redundant, du-

plicated statement would have introduced an unwanted de-pendence because this function call has a side effect on the$ SESSION variable. Because of statement reuse, how-ever, this dependence remains exactly the same in the re-paired code as in the original.

The last column demonstrates that the inserted state-ments in 37 repair instances introduce no unwanted depen-dences that affect the rest of the program. Figure 14 showsone instance where a repair had a side effect because of an

Correct repair of remove multi le.php1 < ?2 i n c l u d e ( cl as s / common. php ) ; / / [ F i xM eU p r e p a i r ]3 $GR n ewone = new COMMON( ) ; / / [ F i xM eU p r e p a i r ]4 i f ( ( $ SESSION[ no ] != 1) ) { / / [ F i xM eU p r e p a i r ]5 $GR newone> e r r o r ( R e q ui r e a dm in p r i v i l e d g e , 1 ,

CLOSE ) ; / / [ F i xM eU p r e p a i r ]6 }7

8 i f ( ! $ POST[ id ] | | ! $ POST[ f i l e name ] ) e x i t ( ) ;9 $ POST [ i d ] = s t r r e p l a c e ( a r ray ( . . / , . php ) , ,

$ POST[ id ]) ;10 $ POST [ f i l e n a m e ] = s t r r e p l a c e ( a r ray ( . . / , . php )

, , $ POST[ f i l e name ] ) ;11 / / @SSO( admin )12 @unlink ( da ta / . $ POST[ id ] . / . $ POST[ fi le na me ]) ;13 . . .14 ?>

Correct repair of swfupload ok.php1 i f ( i s s e t ( $ POST[ PHPSESSID ]) ) s e s s i o n i d ($ POST[

PHPSESSID ]) ;2

3 i n c l u d e cla ss / common. php ; / / e x i s t i n g s t at e m en t 4 $GR = new COMMON( ) ; / / e x i s t i n g s t a te m en t 5 i f ( ! $ SESSION[ no ]) { / / [ F i xM eU p r e p a i r ]6 $GR> e r r o r ( R e q u i r e l o g i n p r o c e d u r e ) ; / / [F ixMeUp

r e p a i r ]7 }8 . . .9 i f ( t ime ( ) > 600+@fi lem time ( $ tmp ) ) $ tmpFS = @fopen(

$tmp , w ) ; e l s e $ tmpFS = @fopen($tmp , a ) ;10 / / @SSO( member )11 @fwr i t e ($ tmpFS , $ save Resu l t ) ;12 @fclose ($tmpFS) ;

Figure 13: GRBoard: Same ACT in different contexts

already present alternative policy. Line 13 shows an access-control check already present in slidesshow.php . Becausethe policy implemented by the existing check does notmatch the ACT that prescribes additional checks for the ad-

ministrator role, F IX MEUP inserts Line 3-11. However, thefunction call on Line 8 has a side effect on $ SESSION and $ COOKIE which are used in the function call at Line13. This side effect is easy to detect with standard depen-dence analysis, but the reason it occurred is a faulty anno-tation: the access-control policy represented by the ACTshould not have been applied to this context.

We reported the new vulnerabilities found by F IX MEUPand they were assigned CVE candidate numbers: CVE-2012-2443, 2444, 2445, 2437 and 2438. We conrmed thecorrectness of our repairs by testing each program and ver-ifying that it is no longer vulnerable. When an unautho-rized user invokes the repaired applications through either

an intended or unintended entry point and attempts to ex-ecute the sensitive operation, every repaired application re- jects the attempt and executes the code corresponding to thefailed check from the original ACT.

7 Related WorkRelated work includes techniques for nding access-controlbugs, since it is a necessary rst step to repairing them, gen-eral bug nding, program repair, and transformation tools.


14/16

slidesshow.php1 . . .2 $gid =$ GET[ g id ] ; / / e x i s t i n g s t a t e m e nt s3 $ fo rm pw newone = $ POST[ fo rm pw ] ; / / [F ixMeUp

r e p a i r ]4 . . . .5 i f ( ! c h e c k a d m i n l o g i n ( ) ) { / / [ Fix MeU p r e p a i r ]6 i f ( ( s t r l e n ( $ g i d i n f o [ g a l l e r y p a s s w o r d ] ) > 0 ) ) {

/ / [ Fix MeU p r e p a i r ]7 / / @ACC( gu es t )8 i f ( ! c h e c k g a l l e r y p a s s w o r d ( $ g i d i n f o [

g a l l e r y p a s s w o r d ] , $ f or m p w n e wo n e ) ) { / / [F ix Me Up r e p a i r ]

9 i n c l u d e ( $TEMPLATE DIR . fa ce be gi n . php . mphp ) ; / / [ Fi xMe Up r e p a i r ]

10 e r r o r ( y ( P a s s w or d i n c o r r e c t . ) ) ; / / [F ixMeUpr e p a i r ]

11 } } }12 . . . .13 i f ( ! c h ec k g a l l e r y p a s s w o r d ( $ g i d i n f o [

ga l l e r y pas swo rd ] , $ fo rm pw ) ) {14 i n c l u d e ( $TEMPLATE DIR . fa ce be gi n . php . mphp ) ;15 e r r o r ( y ( P a s s wo r d i n c o r r e c t . ) ) ;16 }

Figure 14: YaPiG: Attempted repair

Static detection of access-control bugs. Prior work sim-ply reports that certain statements are reachable without anaccess-control check. Sun et al. require the programmerto specify the intended check for each application role andthen automatically nd execution paths with unchecked ac-cess to the roles privileged pages [36]. Chlipala nds secu-rity violations by statically determining whether the appli-cations behavior is consistent with a policy specied as adatabase query [5].

One consequence of access-control bugs in Web appli-cations is that attackers may perform unintended page nav-igation. Several approaches nd these unintended naviga-tion ows [2, 10]. They generally rely on heuristics and/ordynamic analysis to learn the intended ows and are thusincomplete. Furthermore, they cannot detect ner-grainedaccess-control bugs. For example, a missing check on thesame page as the protected operation will not manifest as ananomalous page navigation.

Without a programmer-provided specication, staticanalysis may infer the applications access-control poli-cies. Son and Shmatikov use consistency analysis to ndvariables in access-control logic [33]. Son et al. devel-oped RoleCast, a tool that nds role-specic access-controlchecks without specication by exploiting software engi-

neering conventions common in Web applications [32].None of these approaches automatically repair the bugs

they nd, whereas F IX MEUP (1) computes code templatesthat implement access-control logic, (2) nds calling con-texts that implement this logic incorrectly, (3) transformsthe code by inserting the template into one or more methodsin the vulnerable contexts, and (4) validates that the trans-formed code implements the correct logic.

Code mining. A popular bug nding approach is to mine

the program for patterns and looks for bugs as deviations oranomalies. This approach typically nds frequently occur-ring local, intraprocedural patterns [9]. Tan et al. showedhow to nd access-control bugs in SELinux using similartechniques, but with interprocedural analysis [37]. Whenapplied to Web applications, heuristics based on nding de-

viations from common, program-wide patterns will likelygenerate an overwhelming number of false positives. Asshown in [36] and [32], access-control logic in Web appli-cations is signicantly more sophisticated than simple thischeck must always precede that operation patterns. Theyare role- and context-sensitive , with different policies en-forced on different execution paths. Simple pattern match-ing wont nd violations of such policies.

Verifying access control in Java libraries. Access-control checks are standardized in Java libraries and aresimply calls to the SecurityManager class. A rich bodyof work developed techniques for verifying access controlin Java class libraries [16, 29, 31, 35], but none of them

attempt to repair access-control bugs.Dynamic detection of access-control bugs. In the secu-rity domain, dynamic analysis nds security violations bytracking program execution [4, 7, 12, 43]. For example,Halle et al. dynamically ensure that page navigation withinthe application conforms to the state machine specied bythe programmer [12]. GuardRails requires the develop-ers to provide explicit access-control specications and en-forces them dynamically within its framework for Ruby [3].Alternatives to explicit specication include learning thestate machine by observing benign runs and then relyingon anomaly detection to nd violations [6], or using staticanalysis of the server code to create a conservative modelof legitimate request patterns and detecting deviations fromthese patterns at runtime [11]. Violations caused by missingaccess-control checks are an example of generic executionomission bugs. Zhang et al. presented a general dynamicapproach to detecting such bugs [44].

In addition to the usual challenges of dynamic analy-sis, such as incomplete coverage, dynamic enforcement of access-control policies is limited in what it can do onceit detects a violation. Typically, the runtime enforcementmechanism terminates the application since it does notknow what the programmer intended for the application todo when an access-control check fails.

By contrast, our objective is to repair the original pro-gram. In particular, for the program branch correspondingto a failed access-control check, we insert the exact codeused by the programmer as part of the correct checks (itmay generate an error message and return to the initial page,terminate the program, etc.). The repaired program thus be-haves as intended, does not require a special runtime envi-ronment, and can be executed anywhere.

Dynamic repair of software bugs. Dynamic program


15/16

repair xes the symptom, but not the cause of the er-ror [4, 7, 12, 22, 30, 43]. For example, dynamic repairallocates a new object on a null-pointer exception, or ig-nores out-of-bounds references instead of terminating theprogram. The dynamic xes, however, are not reected inthe source code and require a special runtime.

Static detection of injection vulnerabilities. Many tech-niques detect data-ow vulnerabilities, such as cross-sitescripting and SQL injection [13, 15, 17, 39, 42]. These bugsare characterized by tainted inputs owing into databasequeries and HTML content generation. Access-control bugsare control-ow vulnerabilities: they enable the attacker toexecute a sensitive operation, which may or may not be ac-companied by illegitimate data ows. For example, if a con-stant query deletes the database, there is no tainted data owinto the operation.

Automatic remediation of software bugs. Much prior

work nds code clones within the same application to helpprogrammers refactor, x bugs, and add features consis-tently [8, 18, 20, 23, 38]. These tools suggest where a bugx may be needed, but do not transform the program. F IX -MEUP solves the dual of this problem: it inserts similarcode where it is missing.

Several tools learn from a developer-provided x andhelp apply similar xes elsewhere. They perform the samesyntactic edit on two clones [21], or suggest changes forAPI migration [1], or do not perform the edit [23], or ask users where to apply the edit [19]. These approaches onlyapply local edits and none of them consider the interproce-

dural edits that are required to repair access-control logic.In the more limited domain of access-control bugs, we au-tomate both nding the missing logic and applying the x.

Generating program xes. A few approaches automati-cally generate a candidate patch and then check correctnesswith compilation and testing. For example, Perkins et al.generate patches to enforce invariants that are are observedin correct executions but violated in erroneous ones [25].They test several patched executions and select the mostsuccessful one. Weimer et al. [40, 41] generate candidatepatches by randomly replicating, mutating, or deleting codefrom the program. Jin et al. automatically x bugs by nd-ing violations of pre-dened patterns encoded as nite-statemachines, such as misplaced or missing lock and unlock pairs [14]. Their static analysis moves or inserts one ortwo lines of code to satisfy the correct pattern. All of theseapproaches focus on one- or two-line changes that satisfysome dynamic or static local predicate. By contrast, F IX -MEUP extracts and inserts multi-line code sequences re-sponsible for enforcing the applications context-sensitiveaccess-control policy.

8 ConclusionWe presented F IX MEUP, the rst static analysis and pro-gram transformation tool for nding and repairing access-control bugs in server-side Web applications. F IX MEUPstarts with an access-control policy that maps security-sensitive operationssuch as database queries and privi-

leged le operationsto access-control checks that protectthem from unauthorized execution. F IX MEUP then auto-matically extracts the code responsible for access-controlenforcement, uses it to create an access-control template,nds calling contexts where the check is missing or im-plemented incorrectly, repairs the vulnerability by applyingthe template, and validates the repair. The key to seman-tically correct repairs is the novel algorithm that nds andreuses existing statements that are part of the access-controllogic. In particular, reuse of existing statements helps F IX -MEUP avoid duplicating statements that have side effectson the rest of the program. F IX MEUP successfully repaired30 access-control bugs in 10 real-world PHP applications,demonstrating its practical utility.

Acknowledgments. This research was partially supportedby the NSF grants CNS-0746888, SHF-0910818, CCF-1018271, and CNS-1223396, a Google research award,the MURI program under AFOSR Grant No. FA9550-08-1-0352, and the Defense Advanced Research Agency(DARPA) and SPAWAR Systems Center Pacic, ContractNo. N66001-11-C-4018.

References[1] J. Andersen and J. Lawall. Generic patch inference. In ASE ,

pages 337346, 2008.[2] D. Balzarotti, M. Cova, V. Felmetsger, and G. Vigna. Multi-

module vulnerability analysis of Web-based applications. InCCS , pages 2535, 2007.

[3] J. Burket, P. Mutchler, M. Weaver, M. Zaveri, and D. Evans.GuardRails: A data-centric Web application security frame-work. In USENIX WebApps , 2011.

[4] W. Chang, B. Streiff, and C. Lin. Efcient and extensiblesecurity enforcement using dynamic data ow analysis. InCCS , pages 3950, 2008.

[5] A. Chlipala. Static checking of dynamically-varying se-curity policies in database-backed applications. In OSDI ,pages 105118, 2010.

[6] M. Cova, D. Balzarotti, V. Felmetsger, and G. Vigna. Swad-dler: An approach for the anomaly-based detection of stateviolations in Web applications. In RAID, pages 6386, 2007.

[7] M. Dalton, C. Kozyrakis, and N. Zeldovich. Nemesis: Pre-venting authentication and access control vulnerabilities inWeb applications. In USENIX Security , pages 267282,2009.

[8] E. Duala-Ekoko and M. Robillard. Tracking code clones inevolving software. In ICSE , pages 158167, 2007.

[9] D. Engler, D. Chen, S. Hallem, A. Chou, and B. Chelf. Bugsas deviant behavior: A general approach to inferring errorsin systems code. In SOSP , pages 5772, 2001.

[10] V. Felmetsger, L. Cavedon, C. Kruegel, and G. Vigna. To-


16/16

ward automated detection of logic vulnerabilities in Web ap-plications. In USENIX Security , pages 143160, 2010.

[11] A. Guha, S. Krishnamurthi, and T. Jim. Using static analy-sis for Ajax intrusion detection. In WWW , pages 561570,2009.

[12] S. Hall e, T. Ettema, C. Bunch, and T. Bultan. Eliminatingnavigation errors in Web applications via model checkingand runtime enforcement of navigation state machines. In ASE , pages 235244, 2010.

[13] Y. Huang, F. Yu, C. Hang, C. Tsai, D. Lee, and S. Kuo. Se-curing Web application code by static analysis and runtimeprotection. In WWW , pages 4052, 2004.

[14] G. Jin, L. Song, W. Zhang, S. Lu, and B. Liblit. Automatedatomicity-violation xing. In PLDI , pages 389400, 2011.

[15] N. Jovanovic, C. Kruegel, and E. Kirda. Pixy: A static anal-ysis tool for detecting Web application vulnerabilities. InS&P , pages 258263, 2006.

[16] L. Koved, M. Pistoia, and A. Kershenbaum. Access rightsanalysis for Java. In OOPSLA , pages 359372, 2002.

[17] B. Livshits, A. Nori, S. Rajamani, and A. Banerjee. Merlin:Specication inference for explicit information ow prob-

lems. In PLDI , pages 7586, 2009.[18] J. Mayrand, C. Leblanc, and E. Merlo. Experiment on theautomatic detection of function clones in a software systemusing metrics. In ICSM , 1996.

[19] N. Meng, M. Kim, and K. McKinley. Systematic editing:Generating program transformations from an example. InPLDI , pages 329342, 2011.

[20] R. Miller and B. Myers. Interactive simultaneous editingof multiple text regions. In USENIX ATC , pages 161174,2001.

[21] H. Nguyen, T. Nguyen, G. Wilson Jr., A. Nguyen, M. Kim,and T. Nguyen. A graph-based approach to API usage adap-tation. In OOPSLA , pages 302321, 2010.

[22] H. Nguyen and M. Rinard. Detecting and eliminating mem-ory leaks using cyclic memory allocation. In ISMM , pages1529, 2007.

[23] T. Nguyen, H. Nguyen, N. Pham, J. Al-Kofahi, andT. Nguyen. Recurring bug xes in object-oriented programs.In ICSE , pages 315324, 2010.

[24] OWASP top 10 application security risks. https://www.owasp.org/index.php/Top_10_2010-Main ,2010.

[25] J. Perkins, S. Kim, S. Larsen, S. Amarasinghe, J. Bachrach,M. Carbin, C. Pacheco, F. Sherwood, S. Sidiroglou, G. Sul-livan, W.-F. Wong, Y. Zibin, M. Ernst, and M. Rinard. Au-tomatically patching errors in deployed software. In SOSP ,pages 87102, 2009.

[26] PHC: the open source php compiler. http://www.phpcompiler.org .

[27] PHP. http://www.php.net .[28] PHP advent 2010: Usage statistics.

http://phpadvent.org/2010/usage-statistics-by-ilia-alshanetsky .

[29] M. Pistoia, R. Flynn, L. Koved, and V. Sreedhar. Interpro-cedural analysis for privileged code placement and taintedvariable detection. In ECOOP , pages 362386, 2005.

[30] M. Rinard, C. Cadar, D. Dumitran, D. Roy, T. Leu, andW. Beebee. Enhancing server availability and securitythrough failure-oblivious computing. In OSDI , pages 303316, 2004.

[31] A. Sistla, V. Venkatakrishnan, M. Zhou, and H. Branske.CMV: Automatic verication of complete mediation forJava Virtual Machines. In ASIACCS , pages 100111, 2008.

[32] S. Son, K. McKinley, and V. Shmatikov. RoleCast: Findingmissing security checks when you do not know what checksare. In OOPSLA , pages 10691084, 2011.

[33] S. Son and V. Shmatikov. SAFERPHP: Finding semanticvulnerabilities in PHP applications. In PLAS , 2011.

[34] M. Sridharan, S. Fink, and R. Bodik. Thin slicing. In PLDI ,pages 112122, 2007.

[35] V. Srivastava, M. Bond, K. McKinley, and V. Shmatikov. Asecurity policy oracle: Detecting security holes using multi-ple API implementations. In PLDI , pages 343354, 2011.

[36] F. Sun, L. Xu, and Z. Su. Static detection of access controlvulnerabilities in Web applications. In USENIX Security ,2011.

[37] L. Tan, X. Zhang, X. Ma, W. Xiong, and Y. Zhou. AutoISES:Automatically inferring security specications and detectingviolations. In USENIX Security , pages 379394, 2008.

[38] M. Toomim, A. Begel, and S. Graham. Managing duplicatedcode with linked editing. In VLHCC , pages 173180, 2004.

[39] G. Wasserman and Z. Su. Sound and precise analysis of Webapplications for injection vulnerabilities. In PLDI , pages 3241, 2007.

[40] W. Weimer, S. Forrest, C. Le Goues, and T. Nguyen. Auto-matic program repair with evolutionary computation. Com-mun. ACM , 53(5):109116, 2010.

[41] W. Weimer, T. Nguyen, C. Le Goues, and S. Forrest. Au-tomatically nding patches using genetic programming. In ICSE , pages 364374, 2009.

[42] Y. Xie and A. Aiken. Static detection of security vulnera-bilities in scripting languages. In USENIX Security , pages179192, 2006.

[43] A. Yip, X. Wang, N. Zeldovich, and F. Kaashoek. Improv-ing application security with data ow assertions. In SOSP ,pages 291304, 2009.

[44] X. Zhang, S. Tallam, N. Gupta, and R. Gupta. Towards lo-cating execution omission errors. In PLDI , pages 415424,2007.

Date post:	03-Jun-2018
Category:	Documents
Upload:	nadia-metoui
View:	215 times
Download:	0 times

shmat_ndss13fixmeup

Documents