Salvador Martínez
email: salva.martinez@mines-nantes.fr

Valerio Cosentino

Jordi Cabot

Model-based Analysis of Java EE Web Security Misconfigurations

Keywords: Model-Driven Engineering, Security, Reverse-engineering

The Java EE framework, a popular technology of choice for the development of web applications, provides developers with the means to define access-control policies to protect application resources from unauthorized disclosures and manipulations. Unfortunately, the definition and manipulation of such security policies remains a complex and error prone task, requiring expert-level knowledge on the syntax and semantics of the Java EE access-control mechanisms. Thus, misconfigurations that may lead to unintentional security and/or availability problems can be easily introduced. In response to this problem, we present a (model-based) reverse engineering approach that automatically evaluates a set of security properties on reverse engineered Java EE security configurations, helping to detect the presence of anomalies. We evaluate the efficacy and pertinence of our approach by applying our prototype tool on a sample of real Java EE applications extracted from GitHub.

Introduction

Java EE is a popular technology of choice for the development of dynamic web applications (serving also as the basis for other less general purpose frameworks) that expose distributed information and services to remote users. In this scenario, security is a main concern [START_REF] Li | A survey on server-side approaches to securing web applications[END_REF], as the web resources that constitute the web application can be potentially accessed by many users over untrusted networks. As a consequence, the Java EE framework provides developers with the means to specify access-control policies in order to assure the confidentiality and integrity properties of the resources exposed by web applications.

Unfortunately, despite the availability of these security mechanisms, implementing security configurations remains a complex and error prone activity where high expertise is needed to avoid misconfiguration issues, that could inflict critical business damages. In fact, the Open Web Application Security Project (OWASP) document ranks web application misconfigurations in 5th position on the top ten of most critical security flaws [START_REF]OWASP top 10 -2013[END_REF], since they are easy to exploit and can have strong business impact.

For the concrete case of access-control and Java EE applications, and disregarding ad-hoc security implementation mechanisms tangled in the application code, rolebased access-control (RBAC) [START_REF] Sandhu | The NIST model for role-based access control: towards a unified standard[END_REF] policies are specified by writing constraints using a low-level rule-based language with two different textual concrete syntaxes and with relatively complex execution semantics. Concretely, the user can either write constraints in the XML web descriptor file by using a set of predefined tag elements, directly write annotations (with a different syntax and organization w.r.t. the XML tag elements) on the Java Servlet components or combine both mechanisms. Then, combination rules between constraints and the corresponding execution semantics must be taken into account in order to understand what policy is being effectively enforced.

This complexity may lead to the introduction of anomalies and misconfiguration problems (e.g., unexpected rule outcomes, unexpected interactions between accesscontrol rules, etc.) with effects varying from simply increasing unnecessarily the complexity of the specified policies to the introduction of unexpected behaviors such as granting access to resources to unauthorized parties or precluding it to the authorized ones, as confirmed as well by the participants in the online survey reported in Section 3.

In order to tackle this problem, we introduce a reverse engineering approach to automatically detect inconsistencies and misconfigurations in Java EE web applications. First, we define a list of properties a web application must satisfy in order to be free from important anomalies, such as redundancy (i.e., specification of unneeded constraints that overcomplicate the policy) and shadowing (i.e., specification of constraints that are never enforced). Secondly, we present an extraction method to parse the security configuration of a given web application (taking into account both, the web descriptor configuration and the Java annotations) and represent it as a Platform Specific security Model (PSM) specific to Java EE web access-control policies. Then, OCL queries and model transformation operations are implemented on top of that model in order to enable the automatic evaluation of the defined properties on any given Java EE web application. Additionally, our tool produces diagnosis reports that help to identify the source configuration elements responsible of the property violations, thus, helping developers to fix them.

We evaluate the efficacy of our approach by exercising our tool on a battery of publicly available Java EE web applications extracted from GitHub, a web-based Git repository hosting platform. This evaluation has shown that a relevant number of security configurations do violate our recommended properties and that our tool is able to successfully detect those violations.

The rest of the paper is organized as follows. Section 2 describes the access-control mechanisms of Java EE. Section 3 presents a motivation survey about the use of security in Java EE projects. Section 4 describes a number of security properties. Section 5 shows how to extract access-control models from Java EE web applications while Section 6 details our automatic approach to evaluate our properties on them. Section 7 presents a number of additional applications to our approach. Section 8 shows evaluation results and Section 9 gives details about the tool implementation. Related work is discussed in Section 10. Finally, we conclude the paper in Section 11 by presenting conclusions and future work.

Java EE Web Security

Roughly speaking, in the Java EE realm, when a web client makes a HTTP request, the web server translates the request into HTTP Servlet calls to web components (Servlets and Java Server Pages) to perform some business-logic operations.

In this schema, a very important requirement is to ensure the confidentiality and integrity of the resources managed by the web application as they can be accessed by many users and traverse unprotected networks. In that sense, the Java EE framework provides ready-to-use access-control facilities. In the following we will briefly describe the mechanism offered by Java EE for the implementation of access-control policies in web applications.

As introduced before, Java EE applications are typically constituted of JSPs and Servlets (JSPs are in turn translated to Servlet). The access-control mechanism in place in this tier is in charge of controlling the access to these elements along with any other accessible artifact (pure HTML pages, multimedia documents, etc.) 1 . These access-control policies can be specified using two different mechanisms: declarative security and programmatic security, the latter being provided for the cases where fine access-control, requiring user context evaluations, is needed. Nevertheless, the Java EE specification recommends a preferential use of declarative security whenever possible.

Regarding declarative access-control policies, two alternatives are available: 1) writing security constraints in a Portable Deployment Descriptor (web.xml) and 2) writing security annotations as part of the Servlets Java code (note however that not all security configurations can be specified by means of annotations).

Listing 1 shows a security constraint defined in a web.xml descriptor. It contains three main elements: a web-resource-collection specifying the path of the resources affected by the security constraint and the HTTP method used for that access (in this case the /restricted/employee/* path and the GET method); an auth-constraint declaring which roles, if any, are allowed to access the resources (only the role Employee in the example) and a user-data-constraint that determines how the user data must travel from and to the web application (set to None in the example, i.e., any kind of transport is accepted). Additionally, although it is not mandatory, the web descriptor may contain role declarations (see Listing 2). The equivalent security constraint, defined by means of annotations is shown in Listing 3. The @WebServlet annotation identifies the Servlet and the resource path in the web container. Then, the main security annotation is @ServletSecurity that has two attributes: value, that corresponds to a nested annotation @HttpConstraint and http-MethodConstraint that contains a list of nested @HttpMethodConstraint annotations. The @HttpConstraint is used to represent a security constraint to be applied to all HTTP methods while the second is used to define per-HTTP method constraints. Both, @HttpConstraint and @HttpMethodConstraint contain as attributes a list of allowed roles (allowedRoles), the data protection requirements (equivalent to the user-dataconstraint element in the web.xml) and the behavior when the list of allowed roles is empty. Finally, as in the web descriptor, security roles may be declared with annotations by using the annotation @DeclareRoles. E.g., @DeclareRoles("employee").

Listing 3: Annotated Servlet @WebServlet ( name = " R e s t r i c t e d S e r v l e t " , u r l P a t t e r n s ={ "/ r e s t r i c t e d / employee / * " } ) @ S e r v l e t S e c u r i t y ( ( h t t p M e t h o d C o n s t r a i n t s = { @ H t t p M e t h o d C o n s t r a i n t ( v a l u e = "GET" , r o l e s A l l o w e d = " Employee " ) t r a n s p o r t G u a r a n t e e = T r a n s p o r t G u a r a n t e e . None ) }) p u b l i c c l a s s RestrictedServlet e x t e n d s HttpServlet { . . . } Both alternatives can be used at the same time and the final security policy is the result of combining the security constraints specified with both mechanisms. When in conflict, the constraints specified in the web.xml file take precedence and moreover, constraints defined by using annotations may be completely ignored if so is established in the web.xml descriptor (the metadata-complete parameter set as true) which may clearly create confusing situations to non-experts.

Besides, access-control policies defined with the mechanisms described above may contain inconsistencies (rules stating different access actions for the same resource). These inconsistencies are resolved by execution semantics such as rule precedence and combination algorithms as defined in the Java EE Servlet specification. Unfortunately, while this process eliminates inconsistencies in the policy, it may introduce typical access-control anomalies such as shadowing and redundancy ( [START_REF] Alfaro | Complete analysis of configuration rules to guarantee reliable network security policies[END_REF][START_REF] Hu | Anomaly discovery and resolution in web access control policies[END_REF][START_REF] Shehab | Anomaly discovery and resolution in MySQL access control policies[END_REF]), along with other misconfigurations particular to the Java EE access-control (e.g., not declaring all HTTP methods in a given access constraint). As these anomalies may lead to unexpected security and/or availability problems, the automatic detection of their presence in a given web security policy appears as a critical requirement for the security assessment.

Note that, as mentioned above, fine-grained access-control constraints requiring context information may also be defined in the Java EE framework.These constraints cannot be declaratively defined and require the use of programmatic security. Examples would be constraints checking that a user holds two roles or that a connection may only be accepted in specific time slots. We leave the analysis of these fine-grained programmatic constraints as a future work.

Motivation

In order to assess the relevance of security concerns in Java EE web development, we have elaborated an online survey addressed to Java EE web developers. From the set of answers, we have identified a number of important security properties developers find critical. We describe the details of our online survey in the reminder of this section.

Survey settings

Our survey has been directly sent to a pool of Java EE developers. We have obtained this pool by 1) searching projects using the Java EE technology in GitHub, and, 2) looking for the contributors (owner, collaborators, reporters) involved with those projects. Additionally, we have also openly published it in programming discussion forums and blogs. From this process, we have obtained a total of 41 answers, 87% of them corresponding to developers with at least 2 years of experience in Java EE web development.

Survey results

In the following, we will present a summary of the survey contents and obtained answers. The complete set of questions and answers can be found online2 Q: In your opinion, how critical are security aspects in the development of web application(s)? Developers were asked to rate the importance of security properties between 0, unimportant and 10, very critical. 88% of developers consider security aspects critical during the development of web applications, rating its importance between 8 and 10 (see Figure 1). As can be seen in Figure 2, 78% of developers frequently (values between 7 and 10) define access-control policies as part of the creation of a web application.

How difficult do you find the definition of access-control policies in Java EE application(s)? Developers were asked about the degree of difficulty of defining access-control policies, 0 being easy and 10 extremely difficult. 75% of developers feel that defining access-control policies, while not extremely difficult, is a challenging activity with most answer grouped between 5 and 8.

Easy: 0 1 2.4%
From the previously presented set of questions we can conclude that security concerns are considered critical for the majority of participant Java EE developers. Moreover, defining an access-control policy for their projects is both, a difficult and common activity. After these generic questions, developers were asked to evaluate the prevalence and severity of some common security errors. We asked Java EE developers about the importance of having complete access-control policies, i.e., policies that completely cover the access space for a given resource. We also asked them to evaluate how likely it is to produce incomplete policies. From Figure 4 we can see that having complete policies is seen as important for almost all developers (most answer above 5). Moreover, 29 out of 41 consider that producing incomplete policies is very likely. W.r.t. redundancy in security policies (i.e., policy elements that can be removed without affecting the set of access decisions and that make the policy over-complex), from Q: In your view, how important is to make sure security policies are complete? It is not uncommon in security policies to rely on implicit or external information in their contained rules while also allowing for a formal declaration of these elements (e.g., roles may often be taken from the environment whereas they may be directly declared in the security policy as well). We have asked Java EE developers about the importance of declaring all the elements used in a security policy obtaining the results shown in Figure 6. As we can see, most developers consider explicitly declaring all used information a good practice.

Q: How dangerous is to have inconsistent rules? To conclude the questions related to common security anomalies related with accesscontrol configurations, we asked the survey participants about the danger of involuntarily leave private resources (i.e., resources not intended to be publicly available) exposed to unintended parties. Not surprisingly, and as it can be see in Figure 8, Java EE developers consider this as extremely dangerous (with most answer grouped around 9 and 10).

Finally, we asked the survey participants whether they would add other types of security errors to the ones listed above. More than 87% would not and the other 13% did not provide a new description.

We ended the survey by asking the participants about the usefulness of having a tool helping to detect and eventually correct the aforementioned security problems.

Q: Would you add other security problems to the ones discussed above? For the majority (29 out of 41 See Figure 10) of questioned developers, having an automatic tool for evaluating security properties related with access-control configurations would be useful (values between 6 and 10).

Survey evaluation

Based on these answers, we can conclude that, in general, security is a critical concern. Moreover, the relevance of each of the security problems associated with access-control configurations is evaluated as very high, with most answers grouped around the higher values.

Inspired by these results, in the following section we will propose a set of security properties tailored to the Java EE framework that allow the detection of the aforementioned security problems on declarative access-control policies.

Identification of Relevant Web Security Properties

Inspired by our survey, we propose a number of properties, that, when violated, lead to the introduction of policy anomalies regarding the semantics of Java EE accesscontrol. Before getting into the actual properties, we introduce some required definitions.

Definitions

The following definitions aim to characterize the semantics of the Java EE declarative access-control. Definition 1: Web application's security domain. Let R be the set of resources the application uses and makes available for remote access (e.g., web pages and stored documents), S the set of subjects intended to access those resources (subjects are roles in the Java EE access-control realm) and, A the set of actions (e.g., accesses to the resource by means of a given HTTP method) that can be performed on them, we define the domain of web application's security as the tuple < R, S, A >. Resources are identified by its URL pattern (or path), Subjects are identified by their name and Actions are identified by the name of the HTTP method.

A very simple example of domain is the tuple < R, S, A > where R={employee.jsp, private.jsp, index.html}, S={anonymous, manager, employee}, and A={GET, POST}.

Definition 2: Resource pattern. Resources can be grouped by using resource patterns instead of the concrete URL (or path). This way the notation .extension will denote all the files of a given extension, the * symbol will denote any resource and the symbol container name resources contained in container name. Note that a resource pattern could also be a concrete URL path corresponding to a single element.

As an example '.pdf' will denote all the files with pdf extension, '/foo/' will denote all elements contained in foo (such as '/foo/index.html') and '/*' will denote any resource pattern contained in the root of the web application (including, for example, '/foo/index.html'). Access to resources is by default allowed to any user. Security constraints restrict this access by mapping tuples composed of the power sets of Subject, Resource patterns and Action to the set {allow, deny} where allow means the access to a resource is granted and deny that it is precluded. As an example, see Listing 1 in Section 2 were a constraint restricting the access to the resources referred by '/restricted/employee/*' using the GET HTTP method to users holding the Employee role is presented. Definition 4: Security Policy. A security policy P for a given application domain < R, S, A > is a set of constraints and of declared subjects. We refer to this set of declared subjects as S d where S d ⊆ S.

As an example, see Section 2, Listing 2, where the role Employee is declared.

Definition 5: Rule combination. Given a security policy P , and two contained constraints c i and c j with identical URL pattern (c.R) and set of Actions (c.A), we define the function combine(c i , c j ) → c g that combines them in a global constraint c g . It works as follows:

• All named subjects (explicit or implicitly mentioned through the use of the wildcards *, implying all declared roles, or ** implying any authenticated user, as defined in the Java EE specification) become permitted subjects in the global constraint. Thus, the global set of subjects with access to the resource is:

c g .S = c i .S + c j .S.
• If a security constraint authorizes all possible subjects, unauthenticated access is allowed in the global constraint.

• A constraint c i that denies access to all subjects shall combine with any other constraint c j by overriding the effect of c j and cause the accesses to the resource to be precluded in the global constraint. Thus c g .S = ∅.

As an example, if a security constraint with an URL pattern equal to employees/private grants access to a set of subjects and another security constraint with identical URL pattern precludes access to every subject (e.g., by using an empty auth-constraint tag), the final global constraint will preclude all access to the given URL pattern (deny overrides allow). Note that the process works iteratively, combining pairs of constraints until no more combinations are possible.

Definition 6: Access Request. For a given application's security domain < R, S, A >, an access-request ar is a triple of the set formed by the cartesian product {R ×S ×A}.

We use ar.S, ar.R and ar.A to refer to the respective Subject, Action and Resource of the access-request.

Note that we do not use power set (nor resource patterns), as an access-request can only refer to one Subject, one Resource and one Action.

Definition 7: Best match. In an application's security domain < R, S, A >, given an access request ar with URL request path ar.R and Action ar.A and a policy P, the operation bestM atch(P, ar.R, ar.A) → c returns one and only one constraint c by first, applying in order the following rules for matching the URL path identifying ar.R with the Resource patterns c.R defined in the constraints:

1. Exact match of ar.R and one of the elements of c.R.

Longest prefix match between ar.R and one of the elements of c.R (e.g., the

resource pattern with the higher number of path segments in common with ar.R will match).

If ar.R contains a file extension (e.g., .pdf), a c.R containing the same file extension. 4. If no other constraint matches and a constraint is defined for the resource iden-

tified with '/*', this constraint is matched as default.

and second, in case of this resulting in several constraints c with the same c.R but different c.A, selecting the constraint containing ar.A.

The bestMatch algorithm is used to match access-request to 1) responding servlets and 2) security constraints. As an example, supposing we have a policy with three constraints having '/foo/bar/*', '.doc' and '/*' as respective URL patterns, a request for the URL pattern '/foo/bar/index.html' will match first with the constraint with '/foo/bar/*' as URL pattern. A request for '/foobar/list.doc' will match first with a constraint with URL pattern .doc. Finally, if there is no constraint with '.pdf' (or 'list.pdf'), a request for 'list.pdf' would match to a constraint defined for '/*' if it exist.

Properties

Once we have introduced the definitions characterizing the semantics of the Java EE declarative access-control mechanism, we can proceed to introduce a number of properties that, when violated, lead to the introduction of policy anomalies.

If an Action (HTTP method) is named in a security constraint c i , all other standard Actions (HTTP methods) must be specified in the same or other security constraint matching the same set of requests. Otherwise non-named Actions will be uncovered giving unconstrained access to them. This happens because, as per Definition 7, the Action is only used for disambiguation in the process of matching security constraints.

Property 1: Completeness. If a constraint c i .A contains an Action, it must contain all other available Actions (HTTP methods) or there should be at least another constraint c j where, c j .R = c i .R and c j .A contains the other Actions.

An example of a security constraint violating this property is shown in Listing 4 (reduced version of Listing 1). In the example, a constraint is defined for the GET method, stating that only users holding the Employee role are allowed. However, nothing is said about any other HTTP methods. In the absence of other constraints with identical URL pattern, from Definition 7 it follows that this constraint will be matched (but not applied), and thus, unconstrained access will be granted to any HTTP method different from GET. A security constraint is redundant when it can be removed from the security policy without modifying its set of accepted or denied requests (see [START_REF] Alfaro | Complete analysis of configuration rules to guarantee reliable network security policies[END_REF], [START_REF] Hamed | Taxonomy of conflicts in network security policies[END_REF] and [START_REF] Hu | Anomaly discovery and resolution in web access control policies[END_REF].

Property 2: Redundancy. There should not exist two different constraints c i , c j that for the same set of requests produce the same effect (i.e., the constraint function yields the same result). Otherwise one of the constraints is redundant. Summarizing, let c i , c j be two security constraints, c j is redundant if c j .R ⊂ c i .R, c j .S = c i .S, c j .A = c i .A and the result of applying c i is equal to the result of applying c j .

Listing 5 shows a policy containing a redundant constraint. Effectively, as the path of the second constraint is contained in the more general path defined for the first constraint (and being the rest equal), the second constraint, while still executable, can be removed from the policy without changing the global behaviour. Note that we only consider here fully overlapping constraints. A non declared subject must not be used in a security constraint. Not declaring the roles (subjects) used by the security constraints is not considered as an error in the Java EE framework (as roles are string-mapped from the environment). However, we consider that a policy declaring them is easier to understand and less prone to errors as the mappings between environment roles and application roles are centralized. Moreover, the framework provides the special role name '*' that, when used in a security constraint (in the web descriptor web.xml) maps to the list of all declared roles. Therefore, using '*' without explicitly declared roles will preclude the access to the resource. Property 3: Syntactical Let S d be the set of declared subjects and S u the set of used subjects in security constraints, for each subject in S u , there must exist a corresponding declared subject in S d . Summarizing, S u ⊆ S d must be true.

As an example, a policy containing the constraints showed in Listing 5 will only be correct if it also contains a declaration for the role Employee as showed in the Listing 2 in Section 2.

If all the requests that could be matched by a constraint are matched by another constraint with a different effect, one of them is shadowed (see again [START_REF] Alfaro | Complete analysis of configuration rules to guarantee reliable network security policies[END_REF][START_REF] Hamed | Taxonomy of conflicts in network security policies[END_REF] and [START_REF] Hu | Anomaly discovery and resolution in web access control policies[END_REF]). This may happen for instance when an authorization constraint names no subjects (existing a similar constraint naming specific subjects) or when a security constraint uses the special names '*' or '**' (existing again a similar constraint naming specific subjects). Note that this case is different from the redundancy case described in Property 2, as the shadowed constraints would change the global policy if they were enforceable.

Property 4: Shadowing let c i , c j be two security constraints, c i is shadowed by c j (c j having higher precedence as for the combination rules in Definition 5) if c j .R = c i .R, c j .A = c i .A and the intersection of their subjects is empty, c j ∩ c i = ∅. Listing 6 shows an example of a shadowed rule. While the first constraint restricts the access to the resource so that it can only be accessed by users holding the Employee role, the second, by using an empty authorization constraint, completely precludes any access. As from Definition 5 it follows that the second constraint takes precedence in the combination process and given that the set of roles that get granted access to the resource differ, the first rule is shadowed.

All resources named in the constraints of a web security policy should allow at least one role to access them. We adapt here the accessibility property defined in [START_REF] Preda | Model-Driven Security Policy Deployment: Property Oriented approach[END_REF] for the deployment of network policies. We consider any resource exposed by the web application is supposed to be accessible (although possibly constrained). Otherwise, the resources should not be deployed with the web application as 1) this increases the complexity of the security policy configuration 2) errors may cause the resources to end up being exposed. The violation of any of these security properties may cause a given Java EE web application to present security and/or availability problems. In order to prevent these problems to arise in newly developed applications or to correct them in already deployed ones, we describe in the next section a model-based approach that automatically evaluates Java EE web applications to assess the absence of security property violations.

Policy Extraction

Our approach for the analysis of Java EE security configurations is depicted in Figure 11. It is composed of four steps, an extraction process that collects the security information contained in the Java EE application and represents it as part of platformspecific software models, an integration process that combines the extracted models into a single global security model, a property evaluation process that performs model transformations and query operations over the generated PSM in order to evaluate security properties and produce diagnosis reports and a code generation step that generates code artifacts (e.g., test cases and quick fixes). The extraction process is based on textto-model techniques, the integration and property evaluation processes are based on OCL queries and model-to-model transformations and the code generation on modelto-text transformations. We choose model transformations for the sake of flexibility and reusability as they permit us to easily reuse the invariant evaluation in a wider range of operations.

In this section we will describe in detail the first two steps. The evaluation of properties is discussed in Section 6 whereas generation (among other applications) is presented in Section 7. An initial sketch of this process was discussed in [START_REF] Martínez | Model-based Analysis of Java EE Web Security Configurations[END_REF] where the extraction and integration processes along with some of the applications presented in Section 7 were discussed.

Extraction Process

The first step of our approach is the extraction process. It parses the Java source code and XML web descriptor to obtain corresponding model representations, namely, a Java model and an XML model (see Figure 12 where excerpts of the Java annotations and XML metamodels are depicted). By doing so we move from the technical space of source code annotations and XML files to that of the modelware realm. For this stem we rely in MoDisco [START_REF] Bruneliere | Modisco: A model driven reverse engineering framework[END_REF], a model discovery.

Integration

The models obtained in the previous step are manipulated and the security information they contain mixed in an integration process aimed to obtain a model (see Section 5.2) representing the global security policy configured in the Java EE application.

The integration process allows us to ease the manipulation operations required to analyze the policies in comparison with the effort of directly manipulating the constraints separately in the XML and source code annotations with more basic techniques (like text manipulation or XSLT transformations). Concretely, it will allow us to 1) use well-known model-driven tools and frameworks and 2) treat security information in an uniform way, disregarding whether it was specified by using XML or annotations. Moreover, as this global model lays at the same abstraction level with respect to the original configurations, no information-loss is produced in the extraction process.

Metamodel

The definition of metamodels able to accurately represent the information contained in the configuration source files is key to our approach and to this integration step. We define a Servlet Access-Control Security metamodel (hereinafter referred to as Servlet Security metamodel) for that purpose. It is depicted in Figure 13. Both annotations and XML security definitions share similar semantics and therefore can be mapped to this metamodel.

The Servlet Security metamodel allows to handle security roles (SecurityRole class) and security constraints (SecurityConstraint class) of a given web application. The former specifies the security roles defined by the security policy. The latter is used to represent access control constraints, coming from XML web descriptors or Java annotations (source attribute), on a collection of web resources (WebResourceCollection class). Each web resource collection identifies the resources (urlPattern attribute) and HTTP methods (HttpMethod class) to which a security constraint applies. It is important to note that if a HTTP method is defined as omitted (omission attribute), the security constraint applies to all methods except the omitted method. The set of roles participating in the security constraint for a collection of web resources are grouped under an authorization constraint (AuthConstraint class). The absence of an AuthConstraint element in a given constraint represents public access whereas total preclusion is represented by its presence with no role association. A security constraint can be also associated with a given data protection requirement (UserDataConstraint class). This data protection requirement can be defined as: NONE indicating that the container must accept requests when received on any connection, INTEGRAL establishing a requirement for content integrity and CONFIDENTIAL, establishing a requirement for communication confidentiality.

Integration transformation

Once we have a metamodel able to represent the access-control configurations of Java EE application ready, we can proceed to integrate the models obtained in the extraction step. For that purpose, we use the ATL [START_REF] Jouault | ATL: a model transformation tool[END_REF] model transformation language, but a similar approach would be followed when using other relational transformation languages.

ATL is a declarative transformation language that produces output models from input ones. Transformations written using this language are composed, basically, by two main elements: Transformation Helpers and Transformation (declarative) Rules. Helpers play a similar role as functions do in general purpose programming languages. They are used to factorize OCL [START_REF] Omg | OCL, version 2.0, Object Management Group[END_REF] queries in order to improve reusability and to simplify the transformation rules. Declarative rules use a pattern-based approach (similar to how graph transformation do) to match source input elements and produce and initialize target model elements with them.

The code of the full integration transformation is available on GitHub. It is composed of 32 helpers and 20 rules, in particular 6 helpers and 11 rules are used to extract security information from the XML web descriptor, while the remaining helpers and rules target the annotations embedded in the Java code.

Listing 7 shows an ATL rule, part of the transformation to combine the XML and Java Annotations models, that maps annotated Servlets to SecurityConstraint entities. It takes a Java Annotation model element (line 3) and creates a Security Constraint element in a model conform to our Servlet Security metamodel (line 8). Then, helpers are used to initialize this Security Constraint with the corresponding values from the Java Annotation values (e.g., URLPattern, etc.). Finally, an AuthConstraint element with the corresponding list of authorized roles is created (lines 14-15) and assigned to the Security Constraint (line 12).

Analysis of Security Properties

Once we have the security configuration as a model conforming to the Servlet Security metamodel presented before, we can start analyzing it in order to evaluate possible violations of the properties defined in Section 4. This evaluation is fully automated.

In particular, we have specified our properties as OCL queries. The execution of the OCL queries over the model (using any of the available OCL execution environments like USE [START_REF] Richters | Validating UML models and OCL constraints[END_REF] or the EMF OCL [START_REF] Framework | Emf: Ocl plugin for the eclipse modeling framework[END_REF]) returns the model elements that are violating a property, if any. These same OCL queries have been integrated in model transformations to convey the same information in the form of a Report model (see Section 6.1). Thus, we have implemented an ATL transformation for each of the security properties. The transformations are available on GitHub and in total they include 12 rules and 30 helpers.

In the following, we will give details about the calculation of each property over our Servlet Security metamodel. Note that for brevity, we only show the full formal specification in OCL of the Completeness and Syntactical properties, while we limit the specification of the rest of properties to a descriptive level. However, the full specification (in the form of ATL Helpers) of all the properties is available at the web site of the project.

Completeness query:

In Listing 8 we show the query that calculates the completeness property.

The OCL code defines two main variables, HTTP METHODS, listing all the standard HTTP methods and USED HTTP METHODS, that collects all the elements in the input model whose class is HttpMethod. These collections of elements are used then to check if each SecurityConstraint element, containing a given instance of HttpMethod, includes all the other standard HTTP methods or if they are listed in another Security-Constraint element with same URLpattern element value (directly or by the use of the method omission tag).

Redundancy query:

In order to detect redundant constraints we proceed as follows: for each security constraint, we look for other security constraints that, not having a contrary effect, match an equal or contained set of requests and subject authorizations. Concretely, for each SecurityConstraint c i in a given extracted model we look for other rules c j fulfilling the following requirements: 1) c j contains a WebResourceCollection with an UrlPattern element that is more general or equal to the one declared in c i . and 2) the set of RoleName elements named in c j is equal or contained in the set of RoleName elements contained in c i (this includes the case of empty sets of named roles with or without the

Syntactical query:

The syntactical query (see Listing 9) is calculated as follows. For each AuthConstraint containing RoleName elements, all named RoleName elements are retrieved. For each RoleName, we check if it is contained in a SecurityRole role definition.

Shadowing query:

Shadowed security constraints are detected as follows. For each SecurityConstraint c i in a given model, we look for SecurityConstraints c j that having the same set (or contained subset) of UrlPattern elements, declare contrary effects. In our model, contrary effects on two rules c i and c j matching the same access requests occur in two cases: 1) when the constraint c i contains an AuthConstraint element without RoleName and c j names roles or does not contain an AuthConstraint element (and viceversa) 2) when the c i constraint contains an AuthConstraint element naming a list of roles and the c j names the special role name '*' (meaning the set of all declared roles S d ) or the special name '**' (meaning all authenticated users). Note that we also check if the list of roles is equal to S d . In that case, we classify the faulty security constraint as redundant and not as shadowed.

Reachability query:

The reachability query is calculated by finding 1) all the Secu-rityConstraint elements using an empty AuthConstraint element, as this, in the JEE framework, precludes all access to the resource named in the constraint 2) if no roles are defined in the given security configuration, all SecurityConstraint elements in the web descriptor defining an AuthConstraint using the special '*' role name, as this special role name provides access only to declared roles. Note that, as our approach relies on the static analysis of the security policy, this property can only be partially checked (i.e., we can only check whether the declarative policy fully precludes access to a given resource or not. However, resources not constrained in the policy may be precluded by other mechanisms or misconfigurations). In order to fully check the reachability of web resources, dynamic analysis approaches, as the one proposed in [START_REF] Le | Automated inference of access control policies for web applications[END_REF], will be needed.

Security Report and Policy Repair

As mentioned in the previous section, the OCL queries used to evaluate our security properties can be integrated in a model transformation scenario in order to obtain a report model with the detected violations that could be used for feedback and further analysis. This model will conform to the Report metamodel depicted in Figure 14. The Report metamodel consists in an Anomaly metaclass extended by five metaclasses intended to represent each of our security properties. Semantically, these report models should be read in the following way: each instance of any of the subclasses of the anomaly metaclass is an anomaly present in the security configuration of the web application. Note that, in order to help in further analysis and manipulation tasks, each concrete anomaly metaclass contains a reference to the element(s) in our Servlet Security Metamodel responsible from the anomaly. Concretely, the Shadowing metaclass has a link to the shadowed constraint as well as a link to the shadowing constraint. Similarly, the Redundancy metaclass has links pointing to the constraint that is contained and thus redundant and a link to the constraint whose resource path contains the other one. The Completeness metaclass links to the collection of missed HTTP methods and to the original constraint whereas the Syntactical metaclass has links to the set of undeclared roles used in constraints. Finally, the Reachability metaclass has links to the web resources that are unreachable.

Model Transformations for Reporting

Once we have specified all our properties in the form of OCL queries, we can integrate them in the pattern-matching phase of model transformations to produce the property violation reports. Using our OCL queries in ATL basically implies wrapping the contents of let expressions into helper definitions and leaving the rest of the code body untouched (if it is not by modifying the call to the variable defined by the let expression). Then, the only thing left to be done is to create a transformation rule matching the corresponding element on which the OCL query works (context), call the helper in the guard (to just generate anomaly reports in faulty elements) and produce as a rule output element the corresponding Anomaly model element conforming to our Report metamodel.

Listing 10 shows an ATL rule integrating the OCL query for calculating the completeness property into ATL for the generation of a report model. As it can be seen, the Completeness query described above is integrated in the transformation module in the form of a helper (lines 6 to 12) to be called in the guard of a transformation rule matching elements of type HttpMethod (line 17). When the guard holds (i.e., a security constraint is not complete) an Completeness model element containing the list of missing HTTP methods and a link to the faulty constraint is generated (lines 19 to 22).

Model Transformations for Fixing Configurations

The report model generated in the previous step can also be used in order to provide quick-fixes to the developers, so that they can easily correct some of the anomalies present in their configurations. For simplicity, we will limit ourselves here to the demonstration of the generation of fixes (in a textual form) that the developer would have to manually include in the access-control configuration in a semi-automatic workflow.

Table 1 shows for each of the security problems described in Section 4 a possible solution. Note however that in some cases several solutions may fit and thus, human interaction would be needed in order to decide which solution to apply.

As en example, in order to generate a fix for the completeness anomaly we would have to create an ATL helper able to produce a textual representation of a new security Error Solution

Completeness

Generate a security constraint that: 1) has the same URL pattern 2) explicitly uses the missed HTTP methods 3) provides an empty set of roles so that all access is precluded.

Redundancy

Given two security constraints that are mutually redundant, eliminate the less general of them i.e., the one with the more concrete URL pattern (see Definition 4 in Section 4) and/or set of subjects.

Syntactical

Add an explicit declaration for a non-declared role used in a security constraint.

Shadowing

Given two security constraints that are mutually inconsistent (i.e., they have contradictory effects), one of them needs to be eliminated. User input is required in this case to determine which of the two constraints should be eliminated as this depends of the desired behaviour.

Reachability

The non-accessible resources should be removed from the web application exposed directories and the security constraint removed from the policy.

Table 1: Security error fixes constraint (by using the XML or the annotations concrete syntax, depending on the original location of the faulty security constraint). This security constraint must contain the same URL pattern of the original security constraint where an HTTP method was named and name all the unnamed methods. As an access decision, the new security constraint will preclude access to the now included, previously unnamed methods (alternatively, unconstrained access to unnamed methods could be granted). Listing 11 shows the code of a Helper implementing the aforementioned completeness quick-fix. It takes as context a HTTP method and generates a security constraint that, for the same URL pattern, precludes all access for all the previously unnamed HTTP meth- ods. Note that it produces a different textual output depending on the source of the original security constraint (XML or Java annotation).

Other Applications of the MDE Extraction and Property Analysis processes

Having all the access-control information of a Java EE web application in a single model facilitates the development and reusability of a wide range of model-driven tools and techniques to derive additional interesting analysis applications. In this section we discuss a few of them.

Queries & Metrics

One of the most immediate applications is, as seen with the evaluation of properties, to use query languages such as OCL to perform queries and calculate security metrics via the information in our model. The range of possible queries and metrics that can be performed goes beyond the properties we have previously discussed. From simple queries such as listing all the resources reachable by a given subject to more complex operations as detecting equivalent roles (a bad smell for a possible break in the least privilege strategy), our model representation reduces the complexity of performing any analysis or metric calculation. Instead, working with the original (scattered) policy representation would require the developer to use different tools for each concrete mechanism and a further integration step.

As an example, we show the definition of a query that counts the freely accessible resources. Resources in Java EE applications can be either visible to a reduced set of users having certain roles or being freely accessible to everybody, no matter their roles. A manual inspection of the application to discover the open-access resources can be a tedious task, however leveraging on the Servlet Security metamodel, we can easily define a query to detect and count this kind of resources.

Listing 12 shows a possible OCL query able to detect open-access resources. All the security constraints that do not define an authorization constraint (authConstraint) are selected, since they do not enforce any access restriction on the resources declared within the constraint (see lines 2-3). Then, the URLs within each resource contained in the selected constraints are collected (see lines 4-6) and finally counted (see line 7).

Visualization

Graphical information is often easier to grasp at a glance than textual one. In this sense model-driven workbench creation tools such as Sirius3 allow the definition of different viewpoints for a given domain-specific language. Different graphical representations can be obtained without the need of manipulating the source model to create the view.

This way, we can predefine several visualizations for our security data. We could provide a general representation, summarizing the access-control policy of a given application, or more detailed representations showing, for example, the detailed security information related to a given resource or role. As an example, Figure 15 shows the visualization obtained for a simple web application where web resources, roles and the defined constraints are visible (note that, for readability, some relations are omitted).

Interoperability

Our metamodel and extraction process can be also used as a pivot interoperability mechanism in order to build bridges towards other (model-based) representations. (Partial) translations from our metamodel to more generic access-control languages like SecureUML or XACML [START_REF] Lockhart | OASIS XACML TC[END_REF] would enable the reuse of the vast amount of research performed in the general field of access-control analysis while keeping the specificities of Java EE when required.

Notably, formal validation and verification techniques [START_REF] Ledru | Validation of security policies by the animation of z specifications[END_REF], along with change impact analysis [START_REF] Fisler | Verification and change-impact analysis of access-control policies[END_REF] for access-control policies would become available. [ module generate ( ' h t t p : / / www. x t e x t . org / s e r v l e t S e c u r i t y / S e r v l e t S e c u r i t y ' ) ]

[ template p u b l i c generateElement ( s : SecurityConstraint ) ] [ comment @main / ] [ f o r ( it : DisplayName | s . displayName ) ]
[ file ( it . value . concat ( ' . j a v a ' ) , f a l s e , 'UTF-8 ' ) ] i m p o r t org . openqa . selenium . WebDriver ; i m p o r t org . openqa . selenium . firefox . Assert . assertTrue ( " NoLoginFormPresent " , isPresent ) ;

[ / i f ] } } [ / file ] [ / f o r ] [ / template ]

Forward Engineering: Test Generation

As part of the forward engineering of web applications, our Servlet security models could also be used in order to generate integration tests aimed to verify the function and reliability of the web application w.r.t. a given security policy. In this sense we can generate tests evaluating if the access to certain resources is as established in the declarative policy. This would ease performing regressions testing in case modifications are added to the policy and would also help to detect possible inconsistencies between the declarative rules and other access rules that may have been added programmatically.

As an example, an Acceleo [START_REF] Musset | Acceleo user guide[END_REF] model-to-text transformation that generates tests using Selenium4 , a web testing tool, can be integrated so that analysis and verification of the security policy becomes a part in the application testing workflow.

Listing 14 shows a JUnit test that verifies if the access to a resource that is constrained in the security policy configuration actually requires the remote users to authenticate by prompting a login and password form (note that we could also use Selenium to actually log into the application and thus, simulate the navigation with different roles). It is automatically generated by using the Acceleo template excerpt shown in Listing 13. The template uses as input a model conforming to our Servlet security Metamodel to generate a JUnit test for each Security Constraint.

R.Q.1 Analysis

We have used the GitHub Search API 5 to collect a random sample consisting in 500 GitHub repositories of Java Web EE projects using declarative security. Concretely, we looked for repositories containing the string javax.servlet.annotation.ServletSecurity in Java files (required when using servlet security annotations) or the string <webresource-collection> in XML files (the string web-resource-collection is used in security constraints to identify the protected resources).

Due to the limitations of the GitHub Search API, this initial sample may include a high number of meaningless and toy example projects. Thus, we have developed a semi-automatic refinement process aimed to obtain a subset of projects fulfilling two more sophisticated filtering rules:

• A project must not include in either its path or name the following words or variations of them: test, sample, demo, example, tutorial, training, exercise, lesson, helloWorld, practice, template, solution, gettingStarted.

• A project must contain at least five security constraints6 defined either in the web descriptor (identified by the XML element <web-resource-collection>) or through the annotations (identified by the annotation @ServletSecurity).

We applied this process to the initial sample of 500 projects and we obtained 60 projects satisfying the aforementioned constraints 7 . We have then proceeded to analyse these selected projects with our tool (see Appendix A for more information). The results of the analysis are shown in Fig. 16 and commented below: • Around 26% of projects do not present any anomaly, while the remaining projects contain no more than than 3 anomalies (see (a) in the figure). In particular, 15% of the projects contain one anomaly, 50% two and around 8% three. Moreover, the anomalies concerning undeclared roles (Property 3) and resource reachability (Property 5) appear to be the most common ones in our sample (see (b) in the figure). They happened respectively on 56,7% and 48,4% of the projects in the sample.

• None of the projects is affected by shadowing. Shadowing being a very severe but normally quick to notice anomaly (as it modifies the accessibility of a given resource) our intuitions is that this anomaly is one frequently corrected in the initial testing phases. Nevertheless, due to the important consequence of this anomaly, even if it is unlikely to introduce such an anomaly without noticing it, we consider its detection important and thus, keep it in our approach.

• 20% of the projects present a violation of the completeness property (Property 1 in the table) while 10% present redundancy in rules (Property 2).

• Reachability problems are detected in many projects of the sample, however the manual analysis allowed us to discover that the anomaly was actually not taking place in some of the projects. Effectively, those projects were meant to be deployed in the Google cloud services container, where the semantics of the symbol '*' are redefined so that it implies all authenticated users. Nevertheless the detection of this anomaly by our tool remains useful as it provide a hint for possible portability issues.

From these results we can conclude that the answer to our first research question is yes, as indeed, we found a relevant number of anomalies in Java EE projects.

R.Q.2. Analysis

We have manually inspected 20 of the projects' security configurations (randomly selected from the sample) in order to verify the absence of false positive or negatives.

Table 2 shows, for each of the 20 Java EE projects, the number of rules composing its security configuration, and for each security property, if an anomaly (i.e., property violation) is detected manually and/or automatically. As it can be seen no discrepancies between the automatic and manual analysis are detected and thus we can positively answer to R.Q.2 w.r.t. the accuracy of our automatic approach.

R.Q.3. Analysis

Table 2 (and Appendix A) also shows the time taken by our tool to extract models out of the corresponding Java EE web projects (gen.) and to evaluate (eval.) our properties over them. The time for model-extraction depends linearly on the number of Java files whereas the time for calculating the properties, that is much lower does not seem to present a great variability. Table 3 presents some descriptive statistics concerning the extraction and evaluation times, calculated over the 60 projects composing our sample. As can be seen, both times are arguably low for an offline analysis and concretely, the sum of the maximum values for extracting and evaluating the security properties is below one minute (see Max. column in the table). Thus, we can positively answer to R.Q.3.

Threats to Validity

Internal validity: The validity of the conclusions obtained by our experiments may be affected by 1) the degree of relevance of the tested projects and 2) a bias in the selection of the projects. We tackle the first point by establishing a set of conditions to be fulfilled by the projects in order to become part of the experiments. Although this set of conditions may not be complete or may leave out relevant projects, by reducing the number of toy examples, it augments the relevance of the obtained random set. Then, the possible bias in the selection of the projects is avoided by using an automatic tool to obtain the random samples from GitHub.

External validity: Our evaluation evidences that security anomalies do occur in existing Java EE projects. However, as our study uses only projects extracted from GitHub, a threat to the external validity of our results may have been introduced. Although GitHub is currently the most popular coding platform, we can not directly extend our results to the full domain of Java EE web applications, as we can not assure that the subset of projects stored in GitHub is representative of it. In the same sense, there is no guarantee that the selected Github projects have ever been deployed in industrial scenarios.

Tool Support

Our tool support covers two different aspects of the work. On the one hand, we have created a tool to randomly sample GitHub projects (to be then analyzed for security issues). On the other hand, a tool has been developed as plugin under the Eclipse [START_REF] Steinberg | EMF: Eclipse Modeling Framework 2.0[END_REF] platform with the purpose of automatically evaluate the security properties described in Section 4. Both tools are available on GitHub8 .

Sampling GitHub Projects

The component that creates random samples of projects in GitHub is written in Java and relies on the GitHub Search API [START_REF]GitHub Search API[END_REF] to retrieve relevant projects. The tool first parametrizes (based on file size, extension and text string to search) the search operation to retrieve Java EE projects. In a second step, a random sample is derived from the former result set. Repositories of the projects in the sample are automatically downloaded. A manual filtering (according to the set of rules discussed in Section 8) finishes the preparation for the subsequent analysis.

Evaluating Security Properties

The main building blocks of the tool that can be used to evaluate the security properties of a given Java EE application are depicted in Figure 17 as an instantiation with Figure 18: Screenshot of the tool concrete technologies of our general approach initially presented in Figure 11. It relies on MoDisco [START_REF] Bruneliere | Modisco: A model driven reverse engineering framework[END_REF] (for the model extraction), EMF and ATL (the transformation language used to implement all model manipulation operations required by our approach). The tool comes with a GUI that allows the user to select the Java EE project, its web descriptor and the security properties to check. In Figure 18, the GUI of the tool and the corresponding diagnosis report are shown.

Related Work

Policy Analysis

Analysis of security policies is a research subject widely addressed in different research communities. To give a few examples, [START_REF] Hamed | Taxonomy of conflicts in network security policies[END_REF] presents a general taxonomy of potential anomalies for the domain of network security. These anomalies are formalized for network packet-filtering rules in [START_REF] Alfaro | Complete analysis of configuration rules to guarantee reliable network security policies[END_REF]. [START_REF] Shehab | Anomaly discovery and resolution in MySQL access control policies[END_REF] tackles security anomalies in database access control policies, concretely, for MySQL grant tables. Similar approaches, specially tailored to the analysis of anomalies in environments where several policies coexist and interact have also been contributed. Concretely, in [START_REF] Mazzoleni | XACML Policy Integration Algorithms[END_REF] an approach is presented for policies belonging to different authorization parties, in [START_REF] Davy | The Policy Continuum-Policy Authoring and Conflict Analysis[END_REF] for policies in different abstractions levels and [START_REF] Martínez | Model-driven integration and analysis of access-control policies in multi-layer information systems[END_REF] for policies in different architecture layers. Closer to our web domain, [START_REF] Hu | Conformance checking of access control policies specified in XACML[END_REF] and [START_REF] Hu | Anomaly discovery and resolution in web access control policies[END_REF] provide algorithms to detect anomalies in XACML [START_REF] Lockhart | OASIS XACML TC[END_REF] web services policies.

Nevertheless, none of these works can be directly used to validate Java EE security configurations since they would need to be refined to accurately match the execution semantics and combination algorithms required for conflict resolution in Java EE security specifications. Moreover, our approach includes other properties related with the implicit semantics of the Java EE Servlet security or with syntactical misconfigurations (e.g., the absence of declared roles), not part of previous works.

Policy Modeling

Regarding the modeling of the policies themselves, several mechanisms have been used: internal logical representations, BDDs, XACML (and extensions) and, as our own approach, different kinds of models. Among this last group we have EMF-based platform-specific metamodels [START_REF] Basin | Model driven security: From uml models to access control infrastructures[END_REF], SecureUML [START_REF] Lodderstedt | Secureuml: A uml-based modeling language for model-driven security[END_REF] to model Java EE security policies for code generations purposes and UmlSEC [START_REF] Jürjens | UMLsec: Extending UML for secure systems development[END_REF] , extension of the UML language to integrate security concepts which is used for instance in [START_REF] Jürjens | Model-based security analysis for mobile communications[END_REF] to model high-level security properties (requirements) for mobile communication. While some of those languages could have been reused in our approach, we believe that coming up with a Java EE specific metamodel significantly simplifies the manipulation and understanding of the extracted policy. Moreover, being a direct representation of the original configuration policies, forward engineering tasks (i.e. to regenerate code once anomalies are corrected) are also simpler.

Policy Reverse Engineering

W.r.t. the extraction of access-control policies from deployed components, no specific method is proposed in the previously mentioned works. The few approaches devoted to the extraction of security policies employ dynamic techniques to infer the security policy. In [START_REF] Alalfi | Recovering role-based access control security models from dynamic web applications[END_REF] authors use dynamic analysis techniques to extract SecureUML models from PHP web applications. Also for PHP applications, in [START_REF] Letarte | Extraction of inter-procedural simple role privilege models from php code[END_REF] inter-procedural privilege violations are detected by analyzing automatas extracted from the source code. In [START_REF] Gauthier | Extraction and comprehension of moodle's access control model: A case study[END_REF] a similar approach is applied to the Moodle Web Learning Platform. More recently, in [START_REF] Le | Automated inference of access control policies for web applications[END_REF], the authors use dynamic analysis and machine learning techniques in order to infer access rules for a given set of users and roles and to test the reachability of web resources (other security properties are not analyzed but left to human expert validation). Finally, not focused in web applications but on Java code, there is an approach to perform interprocedural privilege analysis for Java applications [START_REF] Koved | Access rights analysis for java[END_REF]. Instead, we extract the policies using static analysis. In a different line of work, we could combine our approach with some of these other approaches as a way to detect deviations between the running system and the specified security configuration.

Conclusion

We have presented an approach to automatically detect security misconfiguration in reverse-engineered Java EE web applications. Our approach is based in the automatic modeling of the declarative security configurations of Java EE web applications and in the definition of a number of security properties whose violation are evidence of the presence of anomalies. We have evaluated the feasibility and pertinence of our approach by using our proof of concept tool on a set of projects retrieved from GitHub. This evaluation has shown that a relevant number of security configurations in actual projects do violate the properties we defined.

We believe that our approach and tool can be useful for the Java EE development community. Besides, as it is fully automated it could be easily adopted and integrated in both, the development phase of Java EE applications, to incrementally asses that security rules are integrated correctly and in a testing phase to assure that already developed applications are free from anomalies.

As future work, we envisage several possible extensions. We would like to extend our framework to include:

1. Programmatic security constraints. We plan to leverage on previous work that focus on extracting business logic embedded in Java code [START_REF] Cosentino | A model driven reverse engineering framework for extracting business rules out of a Java application[END_REF]. In particular, we plan to extract Java models using Model-driven reverse engineering techniques and then apply static slicing techniques [START_REF] Weiser | Program slicing[END_REF] to identify the security rules in the Java model. 2. Other sources of security information, beyond the Java code itself (e.g. security access constraints from an underlying database system) to provide a more complete analysis of the security of the software system as a whole. We intend to integrate to the present approach database reverse engineering results [START_REF] Martinez | Reverse engineering of database security policies[END_REF][START_REF] Cosentino | Extracting UML/OCL integrity constraints and derived types from relational databases[END_REF] that explore the extraction of security constraints from working database systems.

Finally, we also plan to adapt our approach to more complex Java frameworks built on top of Java EE, as the Spring framework. These frameworks typically provide their own security mechanisms and therefore may require additional support and/or the extension of several of the artifacts presented here (e.g., the Servlet Security Metamodel may need to be extended to be able to represent constraints with a higher level of granularity).

Regarding the applications, we would like to enhance the semi-automatic integration test generation application we have discussed here. We intend to investigate the possibility of incorporating reasoning mechanisms able to automatically generate a more comprehensive battery of integration test for web applications.

Appendix

Listing 1 :

 1 Security constraint in web.xml <s e c u r i t y -c o n s t r a i n t> <d i s p l a y -name>GET To Employees</ d i s p l a y -name> <web-r e s o u r c e -c o l l e c t i o n> <web-r e s o u r c e -name> R e s t r i c t e d</ web-r e s o u r c e -name> <u r l -p a t t e r n>/ r e s t r i c t e d / employee / * </ u r l -p a t t e r n> <h t t p -method>GET</ h t t p -method> </ web-r e s o u r c e -c o l l e c t i o n> <a u t h -c o n s t r a i n t> <r o l e -name>Employee</ r o l e -name> </ a u t h -c o n s t r a i n t> <u s e r -d a t a -c o n s t r a i n t> <t r a n s p o r t -g u a r a n t e e>NONE</ t r a n s p o r t -g u a r a n t e e> </ u s e r -d a t a -c o n s t r a i n t> </ s e c u r i t y -c o n s t r a i n t> Listing 2: Role Declaration in web.xml <s e c u r i t y -r o l e> <r o l e -name>Employee</ r o l e -name> </ s e c u r i t y -r o l e>

Figure 1 :

 1 Figure 1: how critical are security aspects in the development of web application(s)?

Figure 2 :

 2 Figure 2: Definition of access-control policies

Figure 3 :

 3 Figure 3: Difficulty of defining access-control policies

Definition 3 :

 3 Security constraint. For a given application's security domain < R, S, A >, and being R pattern the set of all the resource patterns, a security constraint c is an ordered pair (d, t) of the function f : D → T where D = {P(R pattern ) × P(S) × P(A)} and T = {allow, deny}. We use c.S, c.R and c.A to refer to the respective sets of Subject, Resource and Action of the constraint.

Listing 4 :

 4 uncovered methods <s e c u r i t y -c o n s t r a i n t> <web-r e s o u r c e -c o l l e c t i o n> <u r l -p a t t e r n>/ r e s t r i c t e d / employee / * </ u r l -p a t t e r n> <h t t p -method>GET</ h t t p -method> </ web-r e s o u r c e -c o l l e c t i o n> <a u t h -c o n s t r a i n t> <r o l e -name>Employee</ r o l e -name> </ a u t h -c o n s t r a i n t> </ s e c u r i t y -c o n s t r a i n t>

Listing 5 :

 5 Redundant constraints <s e c u r i t y -c o n s t r a i n t> <web-r e s o u r c e -c o l l e c t i o n> <u r l -p a t t e r n>/ r e s t r i c t e d / * </ u r l -p a t t e r n> </ web-r e s o u r c e -c o l l e c t i o n> <a u t h -c o n s t r a i n t> <r o l e -name>Employee</ r o l e -name> </ a u t h -c o n s t r a i n t> </ s e c u r i t y -c o n s t r a i n t> <s e c u r i t y -c o n s t r a i n t> <web-r e s o u r c e -c o l l e c t i o n> <u r l -p a t t e r n>/ r e s t r i c t e d / employee / * </ u r l -p a t t e r n> </ web-r e s o u r c e -c o l l e c t i o n> <a u t h -c o n s t r a i n t> <r o l e -name>Employee</ r o l e -name> </ a u t h -c o n s t r a i n t> </ s e c u r i t y -c o n s t r a i n t>

Listing 6 :

 6 Shadowed constraints <s e c u r i t y -c o n s t r a i n t> <web-r e s o u r c e -c o l l e c t i o n> <u r l -p a t t e r n>/ r e s t r i c t e d / employee / * </ u r l -p a t t e r n> </ web-r e s o u r c e -c o l l e c t i o n> <a u t h -c o n s t r a i n t> <r o l e -name>Employee</ r o l e -name> </ a u t h -c o n s t r a i n t> </ s e c u r i t y -c o n s t r a i n t> <s e c u r i t y -c o n s t r a i n t> <web-r e s o u r c e -c o l l e c t i o n> <u r l -p a t t e r n>/ r e s t r i c t e d / employee / * </ u r l -p a t t e r n> </ web-r e s o u r c e -c o l l e c t i o n> </ a u t h -c o n s t r a i n t> </ s e c u r i t y -c o n s t r a i n t>

Property 5 :

 5 Reachability. All resources named in the constraints of a web security policy should allow at least one role to access them. Summarizing, c.R = ∅ =⇒ c.S = ∅ should hold.

Figure 11 :Figure 12 :

 1112 Figure 11: Java EE web application analysis approach

Figure 13 :

 13 Figure 13: Servlet Security metamodel

Listing 7 :

 7 ATL rule to map security annotated servlets to security-constraints l a z y r u l e createSecurityConstraint { from s : JAVA ! Annotation u s i n g { servletAnnotation : JAVA ! Annotation = s . getContainerAnnotation ( 'ServletSecurity' ) ;} t o t : SEC ! SecurityConstraint ( webResourceCollection <-thisModule . createWebResourceCollection ( servletAnnotation . getWebServlet , s ) , authConstraint <ac , source <-#CODE ) ac : SEC ! AuthConstraint roleName <s . getRolesAllowed }

Listing 8 :

 8 OCL query to calculate the completeness property c o n t e x t HttpMethod inv : l e t HTTP_METHODS : Sequence ( OclAny ) = Sequence {'OPTIONS' , 'GET' , 'HEAD' , 'POST' , 'PUT' , 'DELETE' , 'TRACE' , 'CONNECT'} i n l e t USED_HTTP_METHODS : Sequence ( PSM ! HttpMethod ) = PSM ! HttpMethod . allInstances ( ) i n l e t httpMethodsToCheck : Sequence ( S t r i n g ) = i f self . omission then USED_METHODS->select ( m | m = self . name ) e l s e USED_METHODS->reject ( m | m = self . name ) e n d i f i n l e t selfUrlPatterns : Sequence ( PSM ! UrlPattern ) = self . refImmediateComposite ( ) . urlPattern i n selfUrlPatterns->iterate ( sup ; output : Boolean = true | l e t declaredHttpMethods : Sequence ( PSM ! HttpMethod ) = USED_HTTP_METHODS->reject ( hm | hm = self ) ->select ( hm | hm . refImmediateComposite ( ) . urlPattern ->exists ( up | sup . value = up . value ) ) i n i f declaredHttpMethods->isEmpty ( ) then false e l s e output and httpMethodsToCheck ->forAll ( m | declaredHttpMethods ->exists ( dhm | dhm . name = m ) ) e n d i f use of an AuthConstraint element).

Listing 9 :

 9 OCL query to calculate the Syntactical property l e t ALL_CONSTRAINTS : Sequence ( PSM ! SecurityConstraint ) = PSM ! SecurityConstraint . allInstances ( ) i n ALL_CONSTRAINTS->iterate ( it ; Undeclared : Sequence ( S t r i n g ) = Sequence {} | i f self . authConstraint . oclIsUndefined ( ) then Undeclared e l s e Undeclared->including ( self . authConstraint . roleNameTxt ->iterate ( name ; output : Sequence ( S t r i n g ) = Sequence {} | i f self . authConstraint . roleName ->exists ( ref | ref . name = name ) then output e l s e i f name <> ' * ' then output->including ( name ) e l s e output e n d i f e n d i f ) ) e n d i f )->flatten ( )->asSet ( )->asSequence ( )

1 Figure 14 :

 114 Figure 14: Report metamodel

Listing 10 :

 10 ATL rule to calculate completeness property --@path ANO=anomalies.ecore --@path PSM=ServletSecurity.ecore module checkingCompleteness ; c r e a t e OUT : ANO from IN : PSM ; h e l p e r d e f : HTTP_METHODS : Sequence ( OclAny ) = . . . h e l p e r d e f : ALL_HTTP_METHODS : Sequence ( PSM ! HttpMethod ) = . . . h e l p e r c o n t e x t PSM ! HttpMethod d e f : isComplete : Boolean = . . . r u l e HttpMethod2Completeness { from s : PSM ! HttpMethod ( not s . isComplete ) t o t : ANO ! Completeness ( description <-'constraint does not name all HTTP methods' , t . httpMethod <s . getUncompleteMethods ( ) , t . constraint <s . refImmediateCompisite ( ) . refImmediateComposite ( ) ) }

Listing 11 :

 11 ATL Helper to generate completeness quick-fix for XML h e l p e r c o n t e x t PSM ! HttpMethod d e f : quickFix ( source : S t r i n g ) : S t r i n g = l e t unnamedMethods : Sequence ( S t r i n g ) = s . getUncompleteMethodsNames ( ) i n i f source = 'XML' then return '<security-constraint> <web-resource-collection> <url-pattern>' + self . getUrlPattern ( ) + '<url-pattern> <http-method>' + unnamedMethods + '</http-method> </web-resource-collection> </auth-constraint> <security-constraint>' e l s e return '@HttpMethodConstraint(value="'+ unnamedMethods +'", emptyRoleSemantic = EmptyRoleSemantic.DENY))' e n d i f ;

Listing 12 :

 12 metric query to count the open-access resources query reachableResources = SEC ! SecurityConstraint . allInstances ( ) ->select ( sc | sc . authConstraint . oclIsUndefined ( ) ) ->collect ( sc | sc . webResourceCollection )->flatten ( ) ->collect ( wrc | wrc . urlPattern )->flatten ( ) ->collect ( up | up . value )->flatten ( ) ->asSet ( )->asSequence ( )->size ( ) ;

Figure 15 :

 15 Figure 15: Sirius Policy Visualization Viewpoint

Listing 13 :

 13 Acceleo template for test generation [ comment encoding = UTF-8 / ]

  FirefoxDriver ; p u b l i c Class IntegrationTests { @Test p u b l i c v o i d testAccessTo [ it . value / ] { / / C r e a t e a new i n s t a n c e o f F i r e f o x Browser WebDriver driver = new FirefoxDriver ( ) ; / / Open t h e URL i n f i r e f o x b r o w s e r driver . get ( " [ s . w e b R e s o u r c e C o l l e c t i o n . u r l P a t t e r n . v a l u e / ] " ) ; / / Check w h e t h e r t h e WebElement c o n t a i n i n g t h e l o g i n form i s p r e s e n t b o o l e a n isPresent = driver . findElements ( By . id ( " id-of-t h e-form " ) ) > 0 ; [ i f ( s . authConstraint . oclIsUndefined ( ) ) ] Assert . assertFalse ( " NoLoginFormPresent " , isPresent ) ; [ e l s e ]

Figure 16 :

 16 Figure16: Analysis of the security properties for the selected projects. Subfigure (a) shows the percentage of projects violating properties, from 0 (no property violated) to 3. Subfigure (b) shows the number of projects that violate a given property.

Figure 17 :

 17 Figure 17: Architecture of our Java EE web application analysis approach

Table 2 :

 2 Evaluation Results

	Project Name	Rules	1	2	Property 3 4	5	Time (seconds) gen. eval.
	reviewer	8					7.56 0.06
	dar	11					4.91 0.14
	shop	8					2.18 0.06
	Itrust	13					14.64 0.06
	jersey	6					0.54 0.1
	FanTalk	5					2.7	0.06
	wellmia	5					0.12 0.14
	adware	8					5.85 0.1
	avicena	8					3.08 0.06
	BridgeMonitoring	8					1.63 0.09
	SkillMaps	7					2.18 0.1
	pki	11					0.11 0.08
	IrssiNotifierWP7S	11					0.3	0.06
	smsr	10					13.98 0.05
	tims	7					1.92 0.06
	TeBES-war	11					0.48 0.06
	KMS	5					0.7	0.08
	libreria-project	7					0.03 0.09
	planets-suite	5					4.03 0.06
	plucial-blog	6					1.63 0.11
	automatic evaluation
	manual evaluation

Table 3 :

 3 Summary for the extraction and evaluation times (in seconds). Min 1 st Qu. Median Mean 3 rd Qu. Max. SD (σ)

	Time
	Extraction 0.01	0.58	1.45	4.15	3.11 35.04	7.30
	Evaluation 0.05	0.06	0.1	0.99	0.62 14.78	2.45
	Application			Model Level
		public int { int a = ...				Analysis with
		}	return ...				ATL & OCL
	application Java EE	<.../> <xml> Java source code	Modisco Model Discoverer	EMF source code model	ATL Transformation & Integration	model EMF web security Traceability public int { model EMF report } int a = ... return ...
			<.../>
		</xml>
		XML web descriptor	Modisco Model Discoverer	EMF web descriptor model

  A. Automatically analysed projects

	GitHub Owner/Repository	Project	Constraints	1	2	Property 3	4	5	Time (sec.) gen. eval.
	sinaptico/reviewer	reviewer	8						7.56	0.06
	servetechgit/ZCoreDar	dar	11						4.91	0.14
	memo1012/shop	shop	8						2.18	0.06
	ekirkilevics/itrust	Itrust	13						14.64	0.06
	richeso/jersey	jersey	6						0.54	0.1
	cndoublehero/FanTalk	FanTalk	5						2.7	0.06
	rilkeanheart/wellmia	wellmia	5						0.12	0.14
	mfaqir/adware	adware	8						5.85	0.1
	mfaqir/avicena	avicena	8						3.08	0.06
	andrea-bottoli/DSD	BridgeMonitoring	8						1.63	0.09
	YusukeKokubo/SkillMaps	SkillMaps	7						2.18	0.1
	tiran/pki	pki	11						0.11	0.08
	Tol1/IrssiNotifierWP7	IrssiNotifierWP7Server	11						0.3	0.06
	chromial/Echo	smsr	10						13.98	0.05
	batbold0514/OnlinePos	tims	7						1.92	0.062
	cristianonovelli/tebes3	TeBES-war	11						0.48	0.06
	AbeHaruhiko/KMS	KMS	5						0.7	0.08
	adricouci/libreria-project	libreria-project	7						0.03	0.09
	opf-labs/planets-suite	planets-suite	5						4.03	0.06
	PluCial/plucial-blog	plucial-blog	6						1.63	0.11
	gilsonsilvati/cid	cid	8						1.27	1.91
	sachdeva-vivek/grouper-i2	grouper-i2	5						0.01	0.09
	gpanic/rest-shop	rest-shop	16						0.67	0.08
	matheusbersot/siga-uff	siga-uff	8						0.03	0.05
	ualerts-org/ualerts-server	ualerts-server	5						0.42	0.17
	abhishekmunie/btech-project-lms	btech-project-lms	5						3.22	1.91
	lukewen427/DeploymentTool	api-server	7						0.66	0.06
	AurionProject/Aurion 4.1	AurionAdapterWeb	28						1.7	0.07
	AurionProject/Aurion 4.1	AurionGatewayWeb	21						1.38	0.07
	AurionProject/Aurion 4.1	AurionNhinServicesWeb	18						0.77	0.84
	batbold0514/OnlinePos	callcenter	5						2.15	0.06
	Hellek1/viaja-facil	Colectivos GBA	5						3	0.06
	tristanrichard/OOAD-Database	GameWorld	7						1.13	0.06
	wiraqutra/my-doctor	my-doctor	5						0.59	0.08
	CCATObservatory/alma-ot	ProjectRepository	8						2.73	0.08
	sborpo/sborpoandsolegr7	sborpoandsolegr7	24						1.56	0.16
	appbas/openshif-sgfpweb	sgfpweb	6						2.08	0.05
	carlosthe19916/sistema-financiero	sistema-financiero	13						0.03	0.06
	skiley22/Telegenda	Telegenda	7						0.26	0.06
	rodericj/TopDish	TopDish	5						1.84	0.05
	sysdocearth/MoguMoguRecipe	MoguMoguRecipe	5						1.14	0.79
	fikriauliya/car-rental-management	car-rental-management	9						1.06	0.66
	TEAMMATES/teammates	teammates	6						21.57	7.15
	ClausPolanka/GAE-Projets	connectr	9						0.97	0.35
	lrkirven/docked gae	docked gae	9						1.2	0.47
	jameswhite/dogtag-pki	dogtag-pki	9						0.16	0.94
	LauraMJ/mscEricsson	group-project	32						0.69	0.4
	louipark/class	MP2	13						10.32	2.83
	google-code-export/partychapp	partychapp	8						1.52	0.59
	aurelios/questionario	questionario	6						0.2	0.13
	BillyZafack/repo1	repo1	6						15.47	4.58
	bwgz/safetysim	SafetySim-AppEngine	35						1.06	0.61
	awadTeam/smacrs	smacrs	5						11.25	2.1
	kamdjouduplex/tech-biz	tech-biz	16						0.09	0.11
	getse/vgatisiaccmxproject	vinculacion	8						4.66	1.78
	smhoekstra/iaf	iaf	5						12.48	3.11
	renatodanielss/projetoredesocialilto	PrjRedeSocial	11						35.04	14.78
	douglasmen/ge	ge	5						1.17	0.81
	camptocamp/secureOWS	secureOWS	7						34.55	9.13
	e-admin/allocalgis	LOCALGIS-SERVER-Geopista	5						0.42	0.14

http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-oth-JSpec/

https://docs.google.com/forms/d/1K3hK4rY5yMkI3HbXOxRNfTHAQqR_ tvLbf1s5RbvwaIA/viewanalytics

http://eclipse.org/sirius/

http://www.seleniumhq.org/

https://developer.github.com/v3/search/

We believe that five security constraints is a fair trade-off between the number of security configurations found and their complexity

The dataset of the collected projects is available at https://drive.google.com/file/d/0B_ 5Zf1cHxMFXR3hrWXdJa1BlYkE/view

https://github.com/atlanmod/web-application-security

Code Generation Extraction Code Generation Analysis Integration Code Level Test code Quick xes Others... Code Generation Extraction Code Generation Analysis Integration Code Level Test code Quick xes Others...

Java EE application

Assert . assertTrue ( " NoLoginFormPresent " , isPresent ) ;

Other similar tests can be generated to validate other properties, e.g., tests verifying HTTP methods, etc. Moreover, by directly manipulating our Servlet Security model we can create an objective access control policy and test if the deployed access-control policy conforms to the rules in the model by providing the same set of access to web resources.

Evaluation

In order to evaluate the efficacy and relevance of our approach we have addressed three research questions:

• R.Q.1. Do the anomalies described in Section 4 occur in existing Java EE projects?

• R.Q.2. Is our approach capable of automatically evaluating these properties over existing projects in a correct manner?

• R.Q.3. Is our approach efficient w.r.t. time?

To answer them we have conducted an evaluation based in the analysis of a set of projects embedding Java EE web security information randomly sampled from GitHub.