Download Java & J2EE Application Security

Document related concepts
no text concepts found
Transcript
Dr. Waitak Wong
Department of Information Management
Chung Hua University, Hsinchu, Taiwan
About Security
Application Security
Java Security from the Ground Up
Standalone Java Application Techniques
Hacking Java Client-Sever Application
Java Network Applications: RMI
2
Exploiting Java Web Tier Components
Web Services Security
Enterprise Java Beans Security
3
About Security
Common Security Threats
Three concepts of CIA security model
Definition of security
4
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)
5
Common Security Threats
Repudiation
Deny your/his completed transaction
Denial of Service
Terminate the service
6
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
7
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
8
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
9
Application Security
- Not just technology; it’s a process… -
System-level Security Vs.
Application-level Security
Application Level{
Application code
System Level {
JVM
Java/J2EE APIs
Operating System
10
System-level Security Vs.
Application-level Security
System-level
security
Application-level
Security
Enterprise
Data
Defeating System-level security may not
provide attackers with appropriate access
to the application-level data, logic, or
methods that they seek
Attacker
11
System-level Security Vs.
Application-level Security (cont.)
System-level
security
Application-level
Security
Enterprise
Data
Work together to build a secure
system/application combination
Attacker
Attacker
12
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 operatingsystem level
Application code
Java/J2EE APIs
Application code
Java/J2EE APIs
Application code
Java/J2EE APIs
JVM (MS Window)
OS (MS Window)
JVM (IBM AIX)
OS (IBM AIX)
JVM (Solaris)
OS (Solaris)
13
Java Security from the Ground Up
Java Language Safety Features
Java Security Model
Java Security Architecture
14
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
15
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
16
Java Security Enforcement
17
Java Security Enforcement
Enforcement happens at different times
Compile time enforcement
Class load time enforcement
Runtime enforcement
18
Compile Time Enforcement
Java Source
Java Compiler
Bytecode
Class Loader
Bytecode
Verifier
Java Virtual
Machine
Runtime
19
Compile Time Enforcement
Validate language syntax
Enforce method and variable access
rules
Enforce variable initialization
Enforce some casting operations
20
Class Load Time Enforcement
Java Source
Java Compiler
Bytecode
Class Loader
Bytecode
Verifier
Java Virtual
Machine
Runtime
21
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
22
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
23
Runtime Enforcement
Java Source
Java
Java Compiler
Compiler
Bytecode
Class Loader
Bytecode
Verifier
Java Virtual
Machine
Runtime
24
Runtime Enforcement
Array bounds checking
Throws
ArrayIndexOutOfBoundsException
Object casting
Throws ClassCastException
Security Manager
Throws SecurityException
Depends on the Access Controller
25
Java Security Model
26
Java Security Model
Sandbox – a strictly defined arena where they cannot affect other
system resources. It provides virtually no flexibility.
27
Java Security Model (cont.)
28
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
29
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.
30
Java Security Model (cont.)
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.)
Introduces the concept of a ProtectionDomain, which permits a highly
38
flexible security policy decoupled from its implementation
Java Security Model (cont.)
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 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
46
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
47
Java Security Architecture Road Map
1
5
7
6
4
2
3
48
Java Security Architecture
49
Java Cryptographic Architecture
50
Java Cryptographic Architecture (cont.)
51
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.
52
JCA & JCE
53
JCE v1.2.1
54
JCE v1.2.1
Unapproved providers cannot plug-in
Providers unusable without framework
Crypto strength is configured in
jurisdiction policy files
55
JCA & JCE
56
JCA & JCE (cont.)
57
JCA & JCE (cont.)
58
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
59
JAAS Architecture (cont.)
60
JAAS Architecture (cont.)
61
JAAS Architecture (cont.)
62
JAAS Architecture (cont.)
63
JAAS Architecture v1.0
64
JAAS Architecture v1.0 (cont.)
65
Java Secure Sockets Extension
Provides Secure Socket Layer (SSL)
connections over TCP/IP sockets.
66
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
67
JSSE v1.0.1
68
J2SE v1.4 "Merlin": Security
CertPath API
GSSAPI “Java Bindings”
Public Key Cryptography Standards (PKCS)
69
J2SE v1.4 "Merlin" : Cert Path
Validation of Certification Paths
Building of Certification Paths
Creation of Certification Paths
Retrieval of certs/CRLs
70
J2SE v1.4 "Merlin": Cert Path
71
J2SE v1.4 "Merlin": Cert Path
SPI (service provider interface) layer
72
J2SE v1.4 "Merlin": Kerberos
Network Authentication System
Internet Standard (RFC 1510)
Access via JAAS, JGSS, maybe JSSE
73
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
74
J2SE v1.4 "Merlin": Kerberos
75
J2SE v1.4 "Merlin": PKCS
De-facto standards widely used today
Evolved to cover technologies from
encryption to smartcards
Utilizes public key technology
76
J2SE v1.4 "Merlin": PKCS (cont.)
77
Road Map: Security
End-to-end security
Integrated Security Services
Evolve with standards
Further performance improvements
78
Standalone Java Application Security
Techniques
Encryption and secure digesting of
sensitive data using JCE
Logging and auditing using the Java
Logging API
79
Encryption and secure digesting of
sensitive data using JCE
- ,。、;:!?「『(【#%】)』」&*※○◎□㊣+-×÷<>=$¥€-
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
80
Encryption and secure digesting of
sensitive data using JCE (cont.)
Key
Encrypt
Locked
Salt
Digesting
Data
Encoding
Account
12345
54321
Balance
300.3
1000.52
Account
12345
54321
Encrypted Balance
R/cT9Xhe44QwZEo+5yruroGmJOLljQTI
RIerr4ua0qatf/TYzVVMHpzARJJ+vQL4
Message
Digest
Message Digest
vMY6nlyuZcFsdHWphVmPxAu1V3o=
Pc9XQrnv+tR7MD9I4KcsjN3xat0=
81
Logging and auditing using the Java
Logging API
Modification of data by an unauthorized
user with an authorized user’s credentials
Log security-related messages and direct
the log messages to a file, a database, a
network socket, or even the console
82
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
83
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
84
Attack the database server
Application-level Database credential
Using application userid and pwd
database credentials
No way to track the attacker
(semi-anonymous)
85
Attack the database server (cont.)
JDBC Data Sources with JNDI
authentication and embedded credential
Hiding the Database
Authenticate a particular user’s access to
the Data Source with that user’s
credentials.
86
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
87
Attack the data as it transits
Packet sniffing
Solution:
Secure the Database connection
88
Packet Sniffing – Mysql Login Packet
89
Packet Sniffing – Mysql Request Packet
90
Packet sniffing – Mysql Response Packet
91
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
92
Use JSSE to implement an SSL
Tunneling Client and Server
93
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.
Client codes that
need remote
class loading
Remote code
Remote code
94
Attack the client side (cont.)
Solution:
Securing JAR files
Specify the classpath on the command line
Protecting Applet-based client
95
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
96
Specify the classpath on the
command line
Don’t 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
application’s classpath on the command
line in a read only startup script.
97
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
object’s private instance variables) in the
bytecode verifiers embedded in particular
VMs.
98
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 browser’s built-in VM and invokes the
Java Plug-in, which uses Sun’s JRE
With Java Plug-in, applets will run with
the default Java Security manager.
99
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 wideranging system access.
100
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 J2EEClient attribute.
Including the JNLP files in the signed JAR
file
101
Java Network Applications: RMI
The Dangers of RMI
Unauthorized Use of Server Side
Functions
Loading class and jar files remotely
102
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
103
The Dangers of RMI (cont.)
Solution:
Selective encryption
Encrypting the Account number and
Balance
Encrypted communication channel
Using SSL connection between Client and
Server
104
Unauthorized Use of Server Side
Functions
Solution:
Alter the remote methods so that the
server can verify the user’s identity
Authenticated communication channel
Create an authenticated socket class
Create a socket factory so that RMI can
use the new socket
105
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 user’s identity
106
Exploiting Java Web Tier
Components
A Java web application utilizes several
technologies:
JSP and Servlets
Static HTML content
The Tomcat web container / web server
107
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
108
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
109
Exploiting Java Web Tier
Components (cont.)
110
Exploiting Java Web Tier
Components (cont.)
111
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
112
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.
113
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
114
Web Services Technologies (cont.)
Universal Description Discovery and
Integration (UDDI)
The naming service, where service
providers can advertise their services to
prospective clients
115
Quick Comparison to Related
Technologies
Function
Naming
Service
Interface
Description
Wire
Protocol
CORBA
JAVA RMI
COSNaming rmiregistry
IDL
IIOP
Web
Services
UDDI
extends
WSDL
java.rmi.Remote
JRMP or
JMI- SOAP
IIOP
116
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
117
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
118
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 workflowbased architecture
119
Watching SOAP Request and Response
with tcpmon
120
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
121
Securing Web Services Application
(cont.)
Confidentiality and integrity of payload
information
Propagation of credential information
122
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
123
124
125
126
127
XML Key Management Spec.
128
XML Key Management Spec.
129
XML Key Management Spec.
130
eXtensible Access Control
131
Security Assertion Markup Language
132
Security Assertion Markup Language
133
134
135
Enterprise Java Beans Security
136
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.
137
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.
138
139
140
141
142
143
144
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.
145
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
146
147
148
149
150
151
J2EE Protection Domain
152
153
154
155
Contact Details:
Dr. Waitak Wong
Email: [email protected]
Phone: 03-5186529
Department of Information Management
Chu Hua University
No. 707, Sec. 2, WuFu Rd.,
Hsinchu, Taiwan
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
157
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
158
The End of the Session
159