Dr. Waitak Wong

1
Java J2EE Application Security

• Dr. Waitak Wong
• Department of Information Management
• Chung Hua University, Hsinchu, Taiwan

2
Today's Agenda

• About Security
• Application Security
• Java Security from the Ground Up
• Standalone Java Application Techniques
• Hacking Java Client-Sever Application
• Java Network Applications RMI

3
Today's Agenda (cont.)

• Exploiting Java Web Tier Components
• Web Services Security
• Enterprise Java Beans Security

4
About Security

• Common Security Threats
• Three concepts of CIA security model
• Definition of security

5
Common Security Threats

• Identity interception
• Steal your identity and use it as their own
• Masquerading
• Grab your identity and use it elsewhere with the
  intention of perpetrating fraud
• Replay attack
• Capture your request and replay that request
• Data interception and manipulation
• Read your data (such as credit card info)

6
Common Security Threats

• Repudiation
• Deny your/his completed transaction
• Denial of Service
• Terminate the service

7
Three concepts of CIA security model

• Confidentiality
• information must not be disclosed to any
  unauthorized person
• Integrity
• authorized actions (unauthorized data changes)
• separation and protection for resources
• error detection and correction (data corruption)
• Availability
• presence of objects or service in a usable form
• capacity to meet service needs
• adequate timeliness of a service

8
Definition of security

• Deter
• Generate a feasible and believable deterrence
• Detect
• Detect how, when and where intrusion has taken
  place
• Protect
• Manage people and the Information System in an
  effective manner so as to protect against
  unauthorized usage

9
Definition of security

• React
• react to an intrusion
• ensure that penetration does not happen again.
• vulnerability is eliminated
• Recover
• recover all data and programs from a breach in
  security

10
Application Security - Not just technology
its a process -

• System-level Security Vs.
• Application-level Security

11
System-level Security Vs. Application-level
Security

• Defeating System-level security may not provide
  attackers with appropriate access to the
  application-level data, logic, or methods that
  they seek

Application-level Security
System-level security
Enterprise Data
Attacker
12
System-level Security Vs. Application-level
Security (cont.)

• Work together to build a secure
  system/application combination

System-level security
Application-level Security
Enterprise Data
Attacker
Attacker
13
System-level Security Vs. Application-level
Security (cont.)

• It is more efficient to push some security
  responsibilities up to the application level
  instead of handling them at the operating-system
  level

14
Java Security from the Ground Up

• Java Language Safety Features
• Java Security Model
• Java Security Architecture

15
Java Language Safety Features

• Objects have access levels
• private Accessible by defining class
• package (default) Accessible by classes in the
  same package
• protected Same as package, with addition of
  access by any subclass
• public Accessible by any class

16
Java Language Safety Features

• Access methods are strictly adhered to
• No pointers (no access to arbitrary memory and
  automatic garbage collection)
• final methods or variables cannot be changed
• Variables MUST be initialized before use
• Array bounds are enforced
• Strict object casting rules

17
Java Security Enforcement
18
Java Security Enforcement

• Enforcement happens at different times
• Compile time enforcement
• Class load time enforcement
• Runtime enforcement

19
Compile Time Enforcement
20
Compile Time Enforcement

• Validate language syntax
• Enforce method and variable access rules
• Enforce variable initialization
• Enforce some casting operations

21
Class Load Time Enforcement
22
Class Load Time Enforcement

• Bytecode verification
• Verifies class file format
• Accesses objects as correct type
• Final classes are not subclassed
• Final methods are not overridden
• Every class has a single superclass Verify that
  casting legality checks are in place

23
Class Load Time Enforcement

• No operand stack overflows or underflows
• All field and method accesses are legal
• Method calls use correct number types of
  arguments

24
Runtime Enforcement
25
Runtime Enforcement

• Array bounds checking
• Throws ArrayIndexOutOfBoundsException
• Object casting
• Throws ClassCastException
• Security Manager
• Throws SecurityException
• Depends on the Access Controller

26
Java Security Model
27
Java Security Model
Sandbox a strictly defined arena where they
cannot affect other system resources. It
provides virtually no flexibility.
28
Java Security Model (cont.)
29
Components work with Sandbox

• Class loader
• first link in the security chain
• enforces the name space hierarchy
• Byte code verification
• checks that there are violations like stack
  overflows, name space violations, illegal data
  type casts, etc.
• Security manager
• It enforces the boundary of the sandbox

30
Java Security Model (cont.)
JDK 1.1 security model
Applets either received unlimited access or were
confined to the sandbox there was no option for
selective access to resources.
31
Java Security Model (cont.)
32
Java Security Model (cont.)
33
Java Security Model (cont.)
34
Java Security Model (cont.)
35
Java Security Model (cont.)
36
Java Security Model (cont.)
37
Java Security Model (cont.)
38
Java Security Model (cont.)
Introduces the concept of a ProtectionDomain,
which permits a highly flexible security policy
decoupled from its implementation
39
Java Security Model (cont.)
40
Java Security Model (cont.)
41
Java Security Model (cont.)
42
Java Security Model (cont.)
43
Java Security Model (cont.)
44
Java Security Model (cont.)
45
Java Security Model (cont.)
46
Java Security Architecture

• The J2SE 1.3 introduced
• policy-based access control
• X.509 v3 implementation of certificate interfaces
• tools for creating and managing security keys and
  certificates

47
Java Security Architecture

• J2SE 1.4 continued by adding
• Java Authentication and Authorization Service
  (JAAS)
• Java Cryptography Extension (JCE)
• Java Secure Socket Extension (JSSE)
• Features for Kerberos communication

48
Java Security Architecture Road Map
1
5
7
4
6
2
3
49
Java Security Architecture
50
Java Cryptographic Architecture
51
Java Cryptographic Architecture (cont.)
52
JCE Architecture

• Extension to JCA
• Framework for multiple CSPs
• Sun distributes a JCE provider
• Designed for export
• Provide a framework for encryption and
  decryption, key generation, key agreement, and
  Message Authentication Code (MAC).
• Encryption allows symmetric, asymmetric, block,
  and stream ciphers, with addition support for
  secure streams and sealed objects.

53
JCA JCE
54
JCE v1.2.1
55
JCE v1.2.1

• Unapproved providers cannot plug-in
• Providers unusable without framework
• Crypto strength is configured in jurisdiction
  policy files

56
JCA JCE
57
JCA JCE (cont.)
58
JCA JCE (cont.)
59
JAAS Architecture

• Provides a Java security API to perform
  authentication and authorization security service
  for Java application
• JAAS is designed to be pluggable.
• Pluggable authentication
• User-based authorization
• Fine-grained access control capabilities
• Framework for single sign-on

60
JAAS Architecture (cont.)
61
JAAS Architecture (cont.)
62
JAAS Architecture (cont.)
63
JAAS Architecture (cont.)
64
JAAS Architecture v1.0
65
JAAS Architecture v1.0 (cont.)
66
Java Secure Sockets Extension

• Provides Secure Socket Layer (SSL) connections
  over TCP/IP sockets.

67
Java Secure Sockets Extension (cont.)

• JSSE is a set of Java packages that enables
  secure Internet communications.
• Standard socket APIs for SSL and TLS
• Transport level Authentication, Integrity, and
  Privacy
• Supports standard cipher suites
• Includes https URL handler

68
JSSE v1.0.1
69
J2SE v1.4 "Merlin" Security

• CertPath API
• GSSAPI Java Bindings
• Public Key Cryptography Standards (PKCS)

70
J2SE v1.4 "Merlin" Cert Path

• Validation of Certification Paths
• Building of Certification Paths
• Creation of Certification Paths
• Retrieval of certs/CRLs

71
J2SE v1.4 "Merlin" Cert Path
72
J2SE v1.4 "Merlin" Cert Path
SPI (service provider interface) layer
73
J2SE v1.4 "Merlin" Kerberos

• Network Authentication System
• Internet Standard (RFC 1510)
• Access via JAAS, JGSS, maybe JSSE

74
J2SE v1.4 "Merlin" Kerberos Features

• Single Sign-on in a Kerberized environment
• Credential cache integrates with platform
  Kerberos
• Interoperate with Solaris 8 software, Windows
  2000, and MIT distributions

75
J2SE v1.4 "Merlin" Kerberos
76
J2SE v1.4 "Merlin" PKCS

• De-facto standards widely used today
• Evolved to cover technologies from encryption to
  smartcards
• Utilizes public key technology

77
J2SE v1.4 "Merlin" PKCS (cont.)
78
Road Map Security

• End-to-end security
• Integrated Security Services
• Evolve with standards
• Further performance improvements

79
Standalone Java Application SecurityTechniques

• Encryption and secure digesting of sensitive data
  using JCE
• Logging and auditing using the Java Logging API

80
Encryption and secure digesting of sensitive
data using JCE
- ,??!???(??)???????-ltgt?-

• Defeat a casual unauthorized read or write
  attempt
• Adding salt to the data
• Generating a secret key
• Encrypt the data
• Data verification with message digests

81
Encryption and secure digesting of sensitive
data using JCE (cont.)
Encrypt
Digesting
Data
Encoding
Account Balance 12345 300.3 54321
1000.52
Account Encrypted Balance Message
Digest 12345 R/cT9Xhe44QwZEo5yruroGmJOLlj
QTI vMY6nlyuZcFsdHWphVmPxAu1V3o 54321
RIerr4ua0qatf/TYzVVMHpzARJJvQL4
Pc9XQrnvtR7MD9I4KcsjN3xat0
82
Logging and auditing using the Java Logging API

• Modification of data by an unauthorized user with
  an authorized users credentials
• Log security-related messages and direct the log
  messages to a file, a database, a network socket,
  or even the console

83
Logging and auditing using the Java Logging API
(cont.)

• Decide what to log
• Successful and unsuccessful login attempt
• Logouts and application shutdowns
• Successfully accessing functionality
• Unsuccessfully attempting to access any
  functionality
• Severe application exceptions that could affect
  the integrity of application data or functionality

84
Hacking Java Client/Server Application

• Attacking a client-server application (network)
  is easier than attacking a standalone application
  (physical access)
• A two-tier application can be attacked
• Outside of the application Attack the database
  server
• The network Attack the data as it transits
• Application itself Attack the client side

85
Attack the database server

• Application-level Database credential
• Using application userid and pwd database
  credentials
• No way to track the attacker (semi-anonymous)

86
Attack the database server (cont.)

• JDBC Data Sources with JNDI authentication and
  embedded credential
• Hiding the Database
• Authenticate a particular users access to the
  Data Source with that users credentials.

87
Attack the database server (cont.)

• User-level Database passwords and JCE for
  encryption
• Encrypt sensitive data, write it to database, and
  generate a message digest for each data record.
• User-level database passwords and Stored
  Procedures or callable statements for access
  control
• No users or application can directly access the
  application tables

88
Attack the data as it transits

• Packet sniffing
• Solution
• Secure the Database connection

89
Packet Sniffing Mysql Login Packet
90
Packet Sniffing Mysql Request Packet
91
Packet sniffing Mysql Response Packet
92
Secure the Database connection

• Use a secure JDBC driver
• Use a secure SSL tunnel
• Use JSSE to implement an SSL Tunneling Client and
  Server
• Use JCE to encrypt the data at the Application
  Level

93
Use JSSE to implement an SSL Tunneling Client and
Server
94
Attack the client side

• Applets and WebStart applications, where remote
  class loading is a necessity
• Attackers might succeed in placing unwanted or
  dangerous files on our client.

Remote code
Client codes that need remote class loading
Remote code
95
Attack the client side (cont.)

• Solution
• Securing JAR files
• Specify the classpath on the command line
• Protecting Applet-based client

96
Securing JAR files

• JAR file a mechanism for distributing
  application code in an encapsulated form
• Jar signer To associate a digital signature
  with a JAR file, and to later verify the
  signature vs. an entry in keystore
• Sealing package within a JAR file
• Notify JVM that the packages contained in the JAR
  file are atomic.

Remark keystore a physical repository for the
digital certificates that are used to verify that
a file was sent by the entity you expected
97
Specify the classpath on the command line

• Dont rely on the CLASSPATH environment variable,
  because that opens a door for attackers to insert
  their own classes
• A good practice to always specify your
  applications classpath on the command line in a
  read only startup script.

98
Protecting Applet-based client

• Type confusion attack attacker would develop
  bycode that could confuse as to the type of the
  object at a particular memory location
• Took advantage of flaws (failure to stop illegal
  class casting or accessing an objects private
  instance variables) in the bytecode verifiers
  embedded in particular VMs.

99
Protecting Applet-based client (cont.)

• Problem flaws in an underlying VM
• Solution Use the Java Plug-in
• When the browser sees a special tag embedded in
  an HTML page indicating that a Java applet is
  presented, it ignores the browsers built-in VM
  and invokes the Java Plug-in, which uses Suns
  JRE
• With Java Plug-in, applets will run with the
  default Java Security manager.

100
Protecting WebStart-based Client

• Java WebStart ?? Java Network Launching Protocol
  (JNLP) and API
• Combine the benefits of applet-based deployment
  with the benefits of standalone applications (no
  need for a web browser or applet container)
• WebStart code is loaded remotely ? it is
  vulnerable to well known hacking technique such
  as Server spoofing, class replacement, and
  tricking unknowledgable users into granting
  wide-ranging system access.

101
Protecting WebStart-based Client (cont.)

• Solution
• Regulated via the SignedBy attribute in
  javaws.policy file or the system policy file
• Two additional security settings defined in the
  JNLP file for the application AllPermissions
  attribute and the J2EE-Client attribute.
• Including the JNLP files in the signed JAR file

102
Java Network Applications RMI

• The Dangers of RMI
• Unauthorized Use of Server Side Functions
• Loading class and jar files remotely

103
The Dangers of RMI

• RMI makes all method calls across network in
  plain text without any authentication.
• Information could be read in transit by a packet
  sniffer

104
The Dangers of RMI (cont.)

• Solution
• Selective encryption
• Encrypting the Account number and Balance
• Encrypted communication channel
• Using SSL connection between Client and Server

105
Unauthorized Use of Server Side Functions

• Solution
• Alter the remote methods so that the server can
  verify the users identity
• Authenticated communication channel
• Create an authenticated socket class
• Create a socket factory so that RMI can use the
  new socket

106
Loading class and jar files remotely

• RMI allows the class and JAR files to be loaded
  from a remote location for application
  distribution
• Hackers could modify the JAR code and convince
  the users to run it. Then they could control the
  system.
• Solution
• Alter the remote methods so that the server can
  verify the users identity

107
Exploiting Java Web Tier Components

• A Java web application utilizes several
  technologies
• JSP and Servlets
• Static HTML content
• The Tomcat web container / web server

108
Exploiting Java Web Tier Components (cont.)

• System-level security is extremely important for
  any web application
• You can apply the following security measures to
  the web application
• Passing servlet parameters in the URL instead of
  in the HTTP header
• Configuring certain servlets to deny HTTP GET
  request

109
Exploiting Java Web Tier Components (cont.)

• Implementing a solid web application exception
  handling
• Overriding container defaults for directory
  listing and servlet invocation
• Implementing a form-based authentication scheme
• Resist session stealing attacks
• Implementing and requiring HTTPS via SSL to be
  used for all browsers to container connection

110
Exploiting Java Web Tier Components (cont.)
111
Exploiting Java Web Tier Components (cont.)
112
Web Services Security

• Web Services
• Web Service Technologies
• Quick Comparison Related Technologies
• The Java Web Services Developer Pack
• Web Services Application Vulnerabilities
• Securing Web Services Application
• Web Services Security Scheme

113
Web Services

• The ability to publish, discover, or invoke a set
  of services in a platform-independent manner,
  using XML and standard, web-based protocols for
  transport.

114
Web Services Technologies

• Simple Object Access Protocol (SOAP)
• Provide a platform neutral, XML-based mechanism
  to request services
• Web Services Description Language (WSDL)
• The interface description of the service

115
Web Services Technologies (cont.)

• Universal Description Discovery and Integration
  (UDDI)
• The naming service, where service providers can
  advertise their services to prospective clients

116
Quick Comparison to Related Technologies
Function CORBA JAVA RMI Web Services
Naming Service COSNaming rmiregistry UDDI
Interface Description IDL extends java.rmi.Remote WSDL
Wire Protocol IIOP JRMP or JMI-IIOP SOAP
117
The Java Web Services Developer Pack

• Java technologies for web services
• JAXM
• A Java Interface to generate SOAP messages
• JAX-RPC
• An interface on top of JAXM provides RMI-like
  interface to web services

118
The Java Web Services Developer Pack (cont.)

• JAXR
• Java access to UDDI-based registries
• A Host for Web Services Endpoints
• A reference implementation using servlets running
  on Jakarta Tomcat

119
Web Services Application Vulnerabilities

• The transport data is viewable or changeable with
  a common text editor
• The WSDL metadata to invoke the service is
  usually available to the general public
• Propagation of security identity or credentials
  between the client and service is not standard
  and can be quite problematic, especially in a
  workflow-based architecture

120
Watching SOAP Request and Response with tcpmon
121
Securing Web Services Application

• Securing the client/server connection
• Connecting web services via secure tunneling over
  SSL
• Authentication with web services
• Implementing declarative authorization for web
  services
• Implementing programmatic authorization for web
  services

122
Securing Web Services Application (cont.)

• Confidentiality and integrity of payload
  information
• Propagation of credential information

123
Securing the client/server connection

• Use SSL/TLS for All Non-public Web Service Ports
• J2EE provides an option for all communication
  with the application to use SSL/TLS or not

124
(No Transcript)
125
(No Transcript)
126
(No Transcript)
127
(No Transcript)
128
XML Key Management Spec.
129
XML Key Management Spec.
130
XML Key Management Spec.
131
eXtensible Access Control
132
Security Assertion Markup Language
133
Security Assertion Markup Language
134
(No Transcript)
135
(No Transcript)
136
Enterprise Java Beans Security
137
J2EE Security Architecture

• Covers both web-tier and EJB-tiers.
• At Web-tier, the access control is performed
  against each web resource which is represented in
  the form of an URL
• At EJB-tier, the access control can be applied
  against each business method of a bean.
• The container can enforce access control based on
  roles defined in the web-tier and EJB-tier.

138
J2EE Security Architecture

• A security role represents a grouping of
  principals and is associated with permissions, or
  authorization within the application.
• A principal is assigned a role, and a role is
  granted permission to execute specific methods.
• User credentials are represented in the form of
  Principal objects. The Principal objects are
  created from the actual user identity information
  that was entered by user.

139
(No Transcript)
140
(No Transcript)
141
(No Transcript)
142
(No Transcript)
143
(No Transcript)
144
(No Transcript)
145
EJB Security Architecture

• EJBs have two options for managing security
• Declarative security
• Declarations made in the deployment descriptor
  dictate the security of the components.
• Security boundaries are based on the beans and
  the methods provided by the beans
• Security is based on which roles are allowed to
  use which beans and which methods they are
  allowed to execute within the beans.

146
EJB Security Architecture

• Programmatic security
• The EJB API provides several methods that
  indicate the role of the caller and the principal
  of the caller to control the execution of
  application security

147
(No Transcript)
148
(No Transcript)
149
(No Transcript)
150
(No Transcript)
151
(No Transcript)
152
J2EE Protection Domain
153
(No Transcript)
154
(No Transcript)
155
(No Transcript)
156
Contact Details
Dr. Waitak Wong Email wtwong_at_mi.chu.edu.tw
Phone [phone] Department of Information
Management Chu Hua University No. 707, Sec. 2,
WuFu Rd., Hsinchu, Taiwan
157
Grossary

• CSP Cryptographic Service Provider
• EJB Enterprise Java Bean
• IDL Interface Description Language
• IIOP Internet Inter-ORB Protocol
• JAAS Java Authentication and Authorization
  Service
• JCE Java Cryptography Extension
• JDBC Java Database Connectivity
• JNLP Java Network Launching Protocol

158
Grossary (cont.)

• JRMP Java Remote Method Protocol
• JSSE Java Secure Socket Extension
• JWSDP Java Web Services Developer Pack
• MAC Message Authentication Code
• PKCS Public Key Cryptography System
• RMI Remote method Invocation
• SSL Secure Socket Layer
• TLS Transport Layer Security

159
The End of the Session