model-based analysis of java ee web security configurations - mise 2016

Model-based Analysis of Java EE Web SecurityConfigurations

Salvador Martínez - AtlanMod team, Mines Nantes & Inria & Lina Valerio Cosentino - AtlanMod team, Mines Nantes & Inria & Lina

Jordi Cabot - SOM Research Lab, ICREA-UOC

Java EE WEB Applications:

● Widespread means to provide distributed information and services to clients.

● Work over Untrusted Networks.● Unauthorized disclosures and

manipulation of data may cause important losses

● Confidentiality and Integrity are strong requirements.

Access-control to the rescue

<security-constraint>

<display-name>

GET To Employees

</display-name>

<web-resource-collection>

<web-resource-name>

Restricted

</web-resource-name>

<url-pattern>

/restricted/employee/*

</url-pattern>

<http-method>GET</http-

method>

</web-resource-collection>

<auth-constraint>

<role-name>Employee</role-

name>

</auth-constraint>

</security-constraint>

$@WebServlet(name = "RestrictedServlet",

urlPatterns ={"/restricted/employee/*"})

$@ServletSecurity((httpMethodConstraints = {

$@HttpMethodConstraint(

value = "GET",

rolesAllowed = "Employee")

$transportGuarantee =

TransportGuarantee.None)})

public class RestrictedServlet extends HttpServlet {...}

Java EE declarative access-control mechanisms for WEB Applications:

PROBLEM? Low level technologies.

Dispersion of the policy.

Difficult to understand (implicit

combination rules)

OWASP: Security

Misconfigurations - 5th more

dangerous security error in Web

applications

OWASP Top 10 2013-A5-Security Misconfiguration

Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts

Application

Specific

Exploitability

EASY

Prevalence

COMMON

Detectability

EASY

Impact

MODERATE

Application /

Business Specific

Consider

anonymous

external attackers

as well as users

with their own

accounts that may

attempt to

compromise the

system. Also

consider insiders

wanting to disguise

their actions.

Attacker accesses

default accounts,

unused pages,

unpatched flaws,

unprotected files

and directories, etc.

to gain unauthorized

access to or

knowledge of the

system.

Security misconfiguration can happen at any level of

an application stack, including the platform, web

server, application server, database, framework, and

custom code. Developers and system administrators

need to work together to ensure that the entire stack is

configured properly. Automated scanners are useful

for detecting missing patches, misconfigurations, use

of default accounts, unnecessary services, etc.

The system could be

completely compromised

without you knowing it.

All of your data could be

stolen or modified slowly

over time.

Recovery costs could be

expensive

The system could be

completely

compromised without

you knowing it. All your

data could be stolen or

modified slowly over

time.

Recovery costs could

be expensive.

What do Java EE Web developers think?

Q: Do you normally define Access-control Policies

Q: How critical are security aspects?

Q: How difficult is the definition of AC policies?

Q: Would you find useful a tool for detecting

security problems?

Overview: General Approach For Solution

Representation:

-Text Files

-Annotations

…

Target?

- To modelware!

- STEPS?

Original

configuration

Policy

extraction

Policy

integrationAnalysis

Integration:

-Higher-level

-Integrated

-Contains all the

relevant info.

Analysis

-Anomalies

-Visualizations

-Metrics

-Translations…

Global Approach

Original

configuration Policy

extraction

Policy

integrationAnalysis

Global Approach: Extraction

Java Annotations Metamodel XML Metamodel

Global Approach: Integration - Servlet Security Metamodel

Global Approach: Analysis

Evaluation of SECURITY PROPERTIES as OCL Constraints:

- Completeness

- Redundancy

- Shadowing

- Syntactical

- Reachability

Completeness property

The 10 Most Important Security

Controls Missing in JavaEE:

5. Security Misconfiguration – beware the <http-method>

tag in a <security-constraint>. This indicates that the

security-constraint only applies to the listed methods,

allowing attackers to use other HTTP methods, like HEAD

and PUT, to bypass the entire security constraint.


<display-name>

GET To Employees

</display-name>


<url-pattern>

/restricted/employee/*

</url-pattern>

<http-method>GET</http-method>


<auth-constraint>

<role-name>Employee</role-name>

</auth-constraint>


Restricts GET

HTTP_Method

All other

Http_methods get

free access!

Redundancy Property



<url-pattern>/restricted/*</url-pattern>


<auth-constraint>


</auth-constraint>




<url-pattern>/restricted/employee/*</url-pattern>


<auth-constraint>


</auth-constraint>


Both constraints Permits

access only to the employee

Role.

/restricted/employee/* is

included in /restricted/*

The second constraint can be

removed from the policy

definition without modifying

the effective policy.

Shadowing Property





<auth-constraint>


</auth-constraint>






</auth-constraint>


Both rules constrain the

access to: /restricted/employee/*

An empty auth_constraint

precludes all access. It also

gives higher precedence to

the rule, so that the effects of

the first rule are overrided.

Syntactical Property



<url-pattern>/restricted/*</url-pattern>


<auth-constraint>


</auth-constraint>






<auth-constraint>

<role-name>*</role-name>

</auth-constraint>


The role Employee has not

been declared in the policy.

The policy works but relies in

implicit mappings

'*', when used in a security

constraint maps to the list of

all declared roles. Therefore,

using '*' without explicitly

declared roles will preclude

the access to the resource.

Reacheability Property






</auth-constraint>


An empty auth_constraint

precludes all access.

However, all paths named in

a web security policy should

allow at least one role to

access them.

Property evaluation: OCL Invariant (only for OCL Hardcore fans) that evaluates the property using a standard OCL interpreter

let HTTP_METHODS : Sequence(OclAny) = Sequence{'OPTIONS','GET','HEAD','POST','PUT','DELETE','TRACE','CONNECT'} in

let ALL_HTTP_METHODS : Sequence(PSM!HttpMethod) = PSM!HttpMethod.allInstances() in

let httpMethodsToCheck : Sequence(String) =

if self.omission then

HTTP_METHODS->select(m | m = self.name)

else

HTTP_METHODS->reject(m | m = self.name)

endif

in

let selfUrlPatterns : Sequence(PSM!UrlPattern) = self.refImmediateComposite().urlPattern in

selfUrlPatterns->iterate(sup; output : Boolean = true |

let declaredHttpMethods : Sequence(PSM!HttpMethod) = ALL_HTTP_METHODS->reject(hm | hm = self)

->select(hm | hm.refImmediateComposite().urlPattern->exists(up | sup.value = up.value)) in

if declaredHttpMethods->isEmpty() then

false

else

output and httpMethodsToCheck->forAll(m | declaredHttpMethods->exists(dhm | dhm.name = m))

endif

Report Model and Error Fixing

Reuse of our OCL security properties in

the context of model transformations:

- To produce anomaly reports

- To generate quick-fixes

- Traceability

Report Model and Error Fixing

helper context PSM!HttpMethod def : quickFix(source :

String) : String =

let unnamedMethods : Sequence(String) =

s.getUncompleteMethodsNames() in

if source = 'XML' then return

'<security-constraint>


<url-pattern>' + self.getUrlPattern() +

'<url-pattern>

<http-method>' + unnamedMethods +

'</http-method>


</auth-constraint>

<security-constraint>'

else return '@HttpMethodConstraint(value="'+

unnamedMethods +

'", emptyRoleSemantic = EmptyRoleSemantic.DENY))'

endif;

create OUT : Anomalies from IN : PSM;

helper def : HTTP_METHODS : Sequence(OclAny) = ...

helper def : ALL_HTTP_METHODS :Sequence(PSM!HttpMethod)

= ...

helper context PSM!HttpMethod def : isComplete :

Boolean = ...

rule HttpMethod2Completeness {

from s: PSM!HttpMethod (not s.isComplete)

to t: Anomalies!UnprotectedMethod (

description <- s.getUncompleteMethodsNames(),

t.trace <- Sequence{s};)

}

Quick-fix generation Report Model Element Creation

Analysis: Other Applications

query reachableResources =

PSM!SecurityConstraint.allInstances()

->select(sc|sc.authConstraint.oclIsUndefined())

->collect(sc|sc.webResourceCollection)

->collect(wrc|wrc.urlPattern)

->collect(up|up.value)->asSet()->size();

Metric: Open Access-resourcesPolicy Visualization

Analysis: Other Applications

InteroperabilityForward engineering

- Application re-generation

- Integration Test Generation

- Code Styles

+

- Translations towards other representations:

SecureUML

Evaluation

R.Q.1. Do the properties we have provided occur in existing

Java EE projects?

R.Q.2. Is our approach capable of automatically evaluate

these properties over existing projects in a correct and

efficient manner?

Evaluation: methodology

We sampled gitHub and obtained 60

non-trivial Java EE projects.

We analyzed them automatically

with our tool.

Finally, we manually analyze a

subset of the sample, looking for

false positives or negatives.

Evaluation: R.Q.1.

70% of projects present at least one anomaly

No project is affected by shadowing

Reachability problems are found in many projects due to Google container

semantics.

R.Q.1. Answer: We did find a relevant number of projects containing security

configurations anomalies.

Evaluation: R.Q.2.

We selected 20 projects out of the original sample of 60 and we analyzed

them by hand.

We did not find false negatives nor false positives.

The evaluation time per project ranges between 0.06 and 0.2 seconds

R.Q.2. Answer: Our approach does accurately detect security anomalies in

an efficient way.

Tool Support

Tool available in GitHub:

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

application-security

We have used MoDisco for the

injection of models from the

original configuration.

ATL has been used to implement

OCL properties, report generation

and quick-fixes.

Future Work

Programmatic Security Constraints

Other sources of information: Database back-ends, logs, etc.

More complex Frameworks: Spring?

model-based analysis of java ee web security configurations - mise 2016

Software