Java has a security model targeted at running applets and untrusted code, so you don’t need to worry about running your own code on your own servers, right? In fact, there are several vulnerability patterns that can affect server-side Java applications, and this presentation outlines some of the steps you should take to ensure that your server room is not compromised. It looks at the established techniques for enhancing your security and shows new technology from IBM that addresses several attack vectors.

1. JavaOne 2013
Securing Java in the Server Room
Tim Ellison, IBM United Kingdom Ltd.
CON 3636
© 2013 IBM Corporation

2. Important Disclaimers
THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY.
WHILST EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION
CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED.
ALL PERFORMANCE DATA INCLUDED IN THIS PRESENTATION HAVE BEEN GATHERED IN A CONTROLLED
ENVIRONMENT. YOUR OWN TEST RESULTS MAY VARY BASED ON HARDWARE, SOFTWARE OR INFRASTRUCTURE
DIFFERENCES.
ALL DATA INCLUDED IN THIS PRESENTATION ARE MEANT TO BE USED ONLY AS A GUIDE.
IN ADDITION, THE INFORMATION CONTAINED IN THIS PRESENTATION IS BASED ON IBM’S CURRENT PRODUCT
PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM, WITHOUT NOTICE.
IBM AND ITS AFFILIATED COMPANIES SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE
OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY OTHER DOCUMENTATION.
NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, OR SHALL HAVE THE EFFECT OF:
- CREATING ANY WARRANT OR REPRESENTATION FROM IBM, ITS AFFILIATED COMPANIES OR ITS OR THEIR
SUPPLIERS AND/OR LICENSORS
2
© 2013 IBM Corporation

3. About me
 Based in the Java Technology Centre, Hursley UK
 Working on various runtime technologies for >20 years
 Experience of open source communities
 Currently focused on class library design and delivery
 Overall technical lead for IBM Java 8 SE
tim_ellison@uk.ibm.com
3
© 2013 IBM Corporation

4. “The only secure computer is one that is unplugged, locked in a
safe, and buried 20 feet under ground in a secret location ...
and I am not even too sure about that one.”
attributed to Dennis Huges, F.B.I.
Flickr: buster19761976
© 2013 IBM Corporation

5. The nature of server-side security
© 2013 IBM Corporation

6. Client-side computing
 Clients perform multiple tasks for a single user
 Variety of devices, operating systems, and
applications
 Typically connect over untrusted networks
 Under control of individuals disassociated with
the services it uses
 May be compromised, or deliberately used to
challenge the security of the server
Flickr: NielsBD
© 2013 IBM Corporation

7. Server-side computing
 Servers typically perform a single task for multiple users
 Usually more powerful computing capacity than clients
 Running controlled applications
 Connecting to a wide variety of clients and back end
systems
 Servers are considered a higher value target to attackers
because:
– more valuable to the owning organization's business
– they provide a service to multiple users
– have access to data regarding multiple clients / services
© 2013 IBM Corporation

8. Server security
 Server side security is distributed across a number of systems and zones
 Requests must pass through multiple checks before reaching the server platform
Inner DMZ
filter
Outer DMZ
filter
Client
filter
 Specialized filters and applications run at each level to scrub the requests and check for
abnormal behaviors that indicate a security breach
Server platform
© 2013 IBM Corporation

9. Securing the computing platform
 Host intrusion detection and prevention system
–
–
–
–
Monitor the system activity to identify and block malicious activities
Identify the suspicious activity by comparing to known good signatures of activity
Block suspicious activities and raises operator alerts
Maintain the integrity of the server
 Firewall
– Interface between trusted and untrusted networks
– Ensure server's network connections are within policy
– Limited level of application knowledge security
 Antivirus software
– Identify and prevent spread of malware in the trusted network
– Often black-list or heuristics based
– Servers can have more restrictive white-list detection
© 2013 IBM Corporation

10. Securing the cloud computing platform
 Cloud service platforms
– Service provider must be trusted
– Outsourcing some security considerations (can be a good thing!)
– Ability to control details of server infrastructure is limited
– Sensitive data must leave the organization
 Virtualized servers
– Resources are shared, potentially with untrusted
tenants
– Applications may be migrated dynamically between
hosts
– Protection appliances and software should be
virtualization-aware
© 2013 IBM Corporation

11. Securing Java in the server room
 While Java may be used to implement the filters and zone software, we will focus on the
application service provider running on the server platform
Client
Outer
DMZ
Inner
DMZ
Risks
Server
platform
– Data-loss / exposure
– Denial of service
– Data and process integrity
– Bad actors
– Suppliers (code and services)
© 2013 IBM Corporation

12. Writing secure applications in Java
 Secure applications require a whole life-cycle approach
– Secure requirements, threat modelling, risk analysis,
secure coding, security testing, security documentation,
incident response policy
– Management of third-party dependencies
– Source code management
– Coding guidelines
– Compiler settings and analysis tools
– Explicit security testing
 Use Java's strengths appropriately
–
–
–
–
–
Java has strong typing, array bounds checking, bytecode verification, JAR signing, ...
Java also has a number of legacy/unsafe APIs and defaults that are inappropriate for secure coding
No strong model for data security
May have to call out to other languages
...this is where there are lessons to be learnt
© 2013 IBM Corporation

13. Sources of server-side Java security information
© 2013 IBM Corporation

14. Common Vulnerabilities and Exposures
 Standardized naming authority for known vulnerabilities and exposures
 A common name helps identify the same issue across multiple vendors, tools, releases, etc
 Contains brief information, such as status indicator, short description, and related issues
 No description of impact, fix information, or detailed technical information
 Contains approx. 57,000 CVEs
National Vulnerability Database
 US Government repository for vulnerability management data
 Indexed by CVE, gives assessment of impact, complexity of exploit, technical details, and
links to vendor information, etc
 Utilizes the “Common Vulnerability Scoring System (CVSS)” to assess
vulnerabilities
© 2013 IBM Corporation

15. Common Weakness Enumeration
 List of software weaknesses across various languages
–
–
–
–
Sponsored by Office of Cybersecurity and Communications, U.S. Department of Homeland Security
Contributions by a broad community including a wide variety of organizations
Shared resource for software developers, tools vendors, security researchers, educators, etc.
CWE Compatibility and Effectiveness Program for certifying products and services
 CWE version 2.5
– 940 vulnerabilities described, categorized into 187 different categories
– Complete with taxonomy, examples, consequences, relationships, etc.
– 73 are classified as weaknesses specific to software written in Java
 The “Top 25 CWEs” represent the most significant exploitable software constructs
 Utilizes the Common Weakness Scoring System, and
Common Weakness Risk Analysis Framework
– Gives a quantitative measurement of the unfixed weaknessis in an application
– Rates weaknesses in terms of impact to business
© 2013 IBM Corporation

16. Open Web Application Security Project
 Community driven open source materials related to software security
– Raising awareness about risks and specific coding vulnerabilitites
– Advocate risk management approach rather than find and patch
 Publish a Top 10 list of most critical web app security risks
 Vulnerabilities are classified to enable the likely impact to the business
© 2013 IBM Corporation

17. Vendor Security Bulletins
 Specific information about security vulnerabilities that may
affect vendor products are published on-line
Java Specific Notices
 e.g. IBM Product Security Incident Response
– https://www.ibm.com/blogs/PSIRT
 e.g. Oracle Critical Patch Updates, Security Alerts and
Third Party Bulletin
– http://www.oracle.com/technetwork/topics/security/alerts086861.html
© 2013 IBM Corporation

18. A closer look at server-side security
© 2013 IBM Corporation

19. Simplified Server Application Architecture
 Useful to consider the various weaknesses in the context of a simplified server architecture
User Sessions & Data
Application
Middleware
Java
filter
OS Platform
Client Interface
Database
data
data
© 2013 IBM Corporation

20. Computing Platform
User Sessions
Application
Potential issues attributed to the application's computing platform
 Risks from mis-configuration or manipulation of the computer
system hosting the application.
Middleware
Java
OS Platform
Client
Interface
Database
 Vulnerabilities affecting the safe and secure operation of the application and its data by
deliberate or inadvertent unauthorized manipulation of the system.
Examples
CWE-842: Placement of User into Incorrect Group
The software or the administrator places a user into an incorrect group.
CWE-605: Multiple Binds to the Same Port
When multiple sockets are allowed to bind to the same port, other services on that port
may be stolen or spoofed.
CWE-405: Asymmetric Resource Consumption (Amplification)
Software that does not appropriately monitor or control resource consumption can lead to
adverse system performance. Sometimes this is a factor in "flood" attacks, but other
types of amplification exist.

21. Java Platform
User Sessions
Application
Potential issues attributed to Java-specific weaknesses
 Using APIs as they are intended to be used, and adopting
mitigating actions for those with known high risk.
Middleware
Java
OS Platform
Client
Interface
Database
 Designing the application and using coding patterns that promote secure practices, while
avoiding those shown to be at risk of introducing vulnerabilities.
Examples
CWE-227: Improper Fulfillment of API Contract ('API Abuse')
The software uses an API in a manner contrary to its intended use, or makes assumptions
that are not assured by the API documentation.
CWE-487: Reliance on Package Level Scope
Java packages are not inherently closed; therefore, relying on them for code security is
not a good practice.
CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
The application uses external input with reflection to select which classes or code to
use, but it does not sufficiently prevent the input from selecting improper classes or
code.

22. Application and Middleware
User Sessions
Application
Potential issues attributed to concepts in the application middleware stack
 Ensuring correct usage of high-level concepts and their
semantics by developers.
Middleware
Java
OS Platform
Client
Interface
Database
 Potential risks by defining behavior and manipulating data at
Examples
different levels of application-defined authority.
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
The software receives input from an upstream component, but it does not neutralize or
incorrectly neutralizes code syntax before using the input in a dynamic evaluation call
(e.g. "eval").
CWE-579: J2EE Bad Practices: Non-serializable Object Stored in Session
The application stores a non-serializable object as an HttpSession attribute, which means
the session cannot be replicated across JVMs.
CWE-613: Insufficient Session Expiration
Insufficient Session Expiration is when a web site permits an attacker to reuse old
session credentials or session IDs for authorization.

23. User Sessions
User Sessions
Potential issues attributed to concepts in management of user level controls
Java
 Ensuring that the logical unit of work encapsulated as application
sessions are secure, robust, and do not lead to data exposure.
Application
Middleware
OS Platform
Client
Interface
Database
 Protecting the integrity of shared secrets and methods for establishing identity of users,
systems, applications, etc
Examples
CWE-268: Privilege Chaining
Privileges, roles, capabilities, or rights can be combined in a way that allows an entity
to perform unsafe actions that would not be allowed without that combination.
CWE-272: Least Privilege Violation
Elevated privilege levels required to perform operations should be dropped immediately
after the operation is performed.
CWE-784: Reliance on Cookies without Validation and Integrity Checking in a Security Decision
Attackers can easily modify cookies and can bypass protection mechanisms such as
authorization and authentication by modifying the cookie to contain an expected value.
CWE-732: Incorrect Permission Assignment for Critical Resource
Giving permissions to a wider range of actors than required, could lead to the exposure
of sensitive information, or the modification of that resource by unintended parties.

24. Client Interface
User Sessions
Risks for systems that depend upon secure communications
Application
Middleware
 Avoiding numerous risks that may diminish the assurances of
secrecy through the use of cryptographic techniques.
Java
OS Platform
Client
Interface
Database
 Protecting the integrity of secure data exchange and methods for establishing identity of the
participants.
Examples
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
The use of a broken or risky cryptographic algorithm is an unnecessary risk that may
result in the exposure of sensitive information.
CWE-337: Predictable Seed in PRNG
A PRNG is initialized from a predictable seed, e.g. using process ID or system time.
CWE-299: Improper Check for Certificate Revocation
The software does not check or incorrectly checks the revocation status of a certificate,
which may cause it to use a certificate that has been compromised.
CWE-297: Improper Validation of Certificate with Host Mismatch
The software communicates with a host that provides a certificate, but the software does
not properly ensure that the certificate is actually associated with that host.

25. Database
User Sessions
Risks in managing the data you use to achieve a business objective
Application
Middleware
 Risks associated with application data being modified by, or
exposed to, those with no business need for such access.
Java
OS Platform
Client
Interface
Database
 Increasing the security assurances around application data that is exposed to external storage,
either temporarily or permanently.
Examples
CWE-313: Cleartext Storage in a File or on Disk
The application stores sensitive information in cleartext in a file, or on disk that
could be read by attackers with access to the file, or with physical or administrator
access to the raw disk.
CWE-499: Serializable Class Containing Sensitive Data
The code contains a class with sensitive data, but the class does not explicitly deny
serialization. The data can be accessed by serializing the class through another class.
CWE-359: Privacy Violation
Mishandling private information, such as customer passwords or social security numbers,
can compromise user privacy and is often illegal..

26. System Data
User Sessions
Consideration of risks handling data associated with the computing
platform itself
 Risks associated with storing descriptive system history in
shared log locations.
Application
Middleware
Java
OS Platform
Client
Interface
Database
 Risks of inadvertently disclosing through system tools and behavior information that is
protected by the application.
Examples
CWE-532: Information Exposure Through Log Files
While logging all information may be helpful during development stages, it is important
that logging levels be set appropriately before a product ships so that sensitive user
data and system information are not accidentally exposed to potential attackers.
CWE-208: Information Exposure Through Timing Discrepancy
Two separate operations in a product require different amounts of time to complete, in a
way that is observable to an actor and reveals security-relevant information about the
state of the product, such as whether a particular operation was successful or not.
CWE-530: Exposure of Backup File to an Unauthorized Control Sphere
A backup file is stored in a directory that is accessible to actors outside of the
intended control sphere.

27. Summary – securing Java in the server room
 Planning
 risk assessment for type of application
 define integrity and confidentiality goals
 identify applicable policies
 assurances about the computing platform
 Development
 secure engineering practices
 mitigation and avoidance of known risks
 security testing and review
 user and administrator guidance
 Operations
 configuration management control and auditing
 intrusion detection and monitoring
 action plan for dealing with security incidents
 contingency planning