Model-based Analysis of Java EE Web Security Configurations - Mise 2016

Model-based Analysis of
Java EE Web Security
Configurations
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
integration
Analysis
Integration:
-Higher-level
-Integrated
-Contains all the
relevant info.
Analysis
-Anomalies
-Visualizations
-Metrics
-Translations…

Global Approach
Original
configuration Policy
extraction
Policy
integration
Analysis

Global Approach: Extraction
Java Annotations Metamodel XML Metamodel

Global Approach: Integration - Servlet
Security Metamodel

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>
</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:
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

More Related Content

Viewers also liked (20)

Similar to Model-based Analysis of Java EE Web Security Configurations - Mise 2016 (20)

More from Jordi Cabot (20)

Recently uploaded (20)

Model-based Analysis of Java EE Web Security Configurations - Mise 2016

Editor's Notes