Java Programming

Advanced Features

SecurityVolume II - Chapter 9

About Security Application Security Java Security from the Ground Up Standalone Java Application Techniques

Agenda

Common Security ThreatsThree concepts of CIA security modelDefinition of security

About Security

Identity interceptionSteal your identity and use it as their own

MasqueradingGrab your identity and use it elsewhere with the intention of perpetrating fraud

Replay attackCapture your request and replay that request

Data interception and manipulationRead your data (such as credit card info)

Common Security Threats

RepudiationDeny your/his completed transaction

Denial of ServiceTerminate the service

Common Security Threats

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

Definition of security

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

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

Application Security - Not just technology; it’s a process… -

System-level Security Vs.

Application-level Security

Operating System

JVM

Java/J2EE APIs

Application code Application

Level｛

System Level｛

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

Attacker

Sy

ste

m-

lev

el

s

ecu

rity

Ap

plic

ati

on

-le

ve

l

Se

curi

ty

E

nte

rpri

se

Da

ta

System-level Security Vs. Application-level Security

(cont.) Work together to build a secure system/application

combination

Attacker

Sy

ste

m-

lev

el

s

ecu

rity

Ap

plic

ati

on

-le

ve

l

Se

curi

ty

E

nte

rpri

se

Da

ta

Attacker

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

OS (Solaris)

JVM (Solaris)

Java/J2EE APIs

Application code

OS (IBM AIX)

JVM (IBM AIX)

Java/J2EE APIs

Application code

OS (MS Window)

JVM (MS Window)

Java/J2EE APIs

Application code

Java Security from the Ground Up

Java Language Safety Features Java Security Model Java Security Architecture

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

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

Java Security Enforcement

Java Security Enforcement

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

Compile Time Enforcement

Java Source

Java Compiler Bytecode

Class Loader Bytecode

Verifier

Java Virtual Machine

Runtime

Compile Time Enforcement

Validate language syntaxEnforce method and variable access rulesEnforce variable initializationEnforce some casting operations

Class Load Time Enforcement Java Source

Java Compiler Bytecode

Class Loader Bytecode

Verifier

Java Virtual Machine

Runtime

Class Load Time Enforcement

Bytecode verificationVerifies class file formatAccesses objects as correct typeFinal classes are not subclassedFinal methods are not overriddenEvery class has a single superclass Verify that casting legality checks are in place

Class Load Time Enforcement

No operand stack overflowsAll field and method accesses are legalMethod calls use correct number & types of arguments

Runtime Enforcement

Java Compiler

Java Source

BytecodeClass Loader Bytecode

Verifier

Java Virtual Machine

Runtime

Java Compiler

Runtime Enforcement

Array bounds checkingThrows ArrayIndexOutOfBoundsException

Object castingThrows ClassCastException

Security ManagerThrows SecurityExceptionDepends on the Access Controller

Java Security Model

Java Security Model

Sandbox – a strictly defined arena where they cannot affect other system resources. It provides virtually no flexibility.

Java Security Model (cont.)

What does this code do?

Using java security mechanisms

Applets are restricted to the sandbox by default: Can only phone home and create pop-up window

with warning Cannot read/write/delete local files, run another

program, connecting to a server other than its home server, …

More permissions can be granted with Security policy file Code signing

What happens when executing ? Use caution when executing Applets as Applications

public class BadApplet extends Applet{ public void init(){ try { Runtime.getRuntime().exec(“rmdir

foo”); } catch (Exception e) { System.out.println(e); } } public static void main(String args[]) { BadApplet a = new BadApplet(); a.init(); } }

1. Exception thrown if run in an Applet container

2. Exception thrown if run as an application using Applet security

Java –Djava.security.manager BadApplet

3. OK if run as an application Java BadApplet

Security Policy Files Consist of a sequence of grant entries.

Each gives some specific permissions to applets from a specific location and/or signed by a specific person

A grant entry has the following general form:grant signedBy “name”, codeBase “file source”{ permission1; permission2; …}

signedBy part omitted if signatures not required for this entry. codeBase part omitted if the entry applies to code from all sources

Security Policy Files codeBase examples:

grant codeBase “http://www.cs.ust.hk/~liao/comp201/”{ } //premission entry for all classes under the directory grant codeBase “http://www.cs.ust.hk/~liao/comp201/tmp.jar”{ }

// permission entry for tmp.jar

grant codeBase “file:C:/dir/tmp” { }grant codeBase “file:/C:/dir/tmp” { }grant codeBase “file://C:/dir/tmp” { }/* permission entry for tmp on local machine */

Note: Forward slash even for the Windows OSCode signing will be discussed later.

Security Policy Files General form for permissions:

permission className tagetName, actionList;className must be fully qualified.

Examples: permission java.io.FilePermission "D:\\-","read, write"; // permission to read and write all files in D drive

permission java.awt.AWTPermission "showWindowWithoutWarningBanner";

// permission to create pop-up window without warning

permission java.net.SocketPermission “*:8000-8999", “connect";

//permission to connect to any host via port 8000 - 8999.

Security Policy Files Permission classes:

java.io.FilePermission java.awt.AWTPermission java.net.SocketPermissionjava.net.NetPermissionjava.util.PropertyPermissionjava.lang.RuntimePermissionjava.security.AllPermission….

See page 712 for details

Security Policy Files java.io.FilePermission

Targets:File a fileDirectory a directoryDirectory/* all files in the directory* all files in current directoryDirectory/- all files in this and all its subdirectories- all files in current directory and all its subs<<ALL FILES>> all files in the file system

In Windows OS, use \\ as file separator Actions

read, write, delete, execute

Security Policy Files java.net.SocketPermission

Targets: (hostRange:portRange)HostName or IPAddreses a single hostlocalhost or empty local host*.domainSuffix all hosts whose domain names end

with the suffix . E.g. *.com* all hosts

:n single port:n1-n2 all ports in the range

Actions:accept, connect, listen

Security Policy Files An example policy filegrant codeBase

"http://www.cs.ust.hk/~liao/comp201/codes/secu/awt/" { permission java.awt.AWTPermission

"showWindowWithoutWarningBanner";};

grant codeBase "http://www.cs.ust.hk/~liao/comp201/codes/secu/file/" {

permission java.awt.AWTPermission "showWindowWithoutWarningBanner";

permission java.io.FilePermission "<<ALL FILES>>", "read, write";

};

grant codeBase "http://www.cs.ust.hk/~liao/comp201/codes/secu/socket/" {

permission java.net.SocketPermission "*", "connect";};

Security Policy Files policytool: a utility for creating policy files

Security Policy FilesLocation of policy file: On client machine Method 1:

${user.home}/.java.policy

On XP: C:\Documents and Settings\liao\.java.policy${java.home}/lib/security/java.policy on my machine: C:\Program Files\j2sdk1.4.0\jre\lib\security

Method 2: place a policy file on the internet or on local machine, add to the master security properties file: ${java.home}/jre/lib/security/java.security

the a link to the policy file. E.g.: policy.url.3=http://www.cs.ust.hk/~liao/comp201/codes/secu/applet.policy

Manage the policy file at a single location. Good for intranet.

Permission Granting Examples AWT Permission example: (check code page)

Normally, pop-up windows created by applets come with warning banners.

However, the pop-up window created by the applet from

http://www.cs.ust.hk/~liao/comp201/codes/secu/awt/

has no warning banner if one includes the following entry into thepolicy filegrant codeBase "http://www.cs.ust.hk/~liao/comp201/codes/secu/awt/" { permission java.awt.AWTPermission

"showWindowWithoutWarningBanner"; };

Permission Granting Examples File Permission example:

Normally, applets cannot read and write local files. However, FileIOApplet from

http://www.cs.ust.hk/~liao/comp201/codes/secu/file/ can read and write local files if one includes the following grant entry

in the policy file: grant codeBase "http://www.cs.ust.hk/~liao/comp201/codes/secu/file/" { permission java.io.FilePermission “<<ALL FILES>> ",

"read,write"; permission java.awt.AWTPermission

"showWindowWithoutWarningBanner"; };

Permission Granting Examples Socket Permission example:

Normally, applets cannot connect to a server other than its home server.

However, SocketApplet from

http://www.cs.ust.hk/~liao/comp201/codes/secu/socket/

can connect to other http servers if one includes the following grant entry in the policy file:

grant codeBase “http://www.cs.ust.hk/~liao/comp201/codes/secu/socket/” { permission java.net.SocketPermission "*", "connect"; };

In your paper try to explain the contents following permission policy file

Outline Using java security mechanisms

Security policy files Code signing

Code Signing Developer

Generates a certificate, which contains a pair of keys, a public key and a private key.

Send the public key to its users. Sign applets with the private key.

Client Gets public key from the developer Adds the public key to his/her own public key collection Modify its own security policy file to give more permissions to

applets signed by THE developer.

Code Signing /Developer

Java comes with the keytool program for managing keystore – database of certificates.

To generate a keystore liao.store and generate a pair of keys with alias liao use the command:keytool –genkey –keystore liao.store –alias liao

A dialog follows and liao.store created.

Keep liao.store at a safe location!

Enter keystore password: 123456 What is your first and last name? [Unknown]: Renlan LiaoWhat is the name of your organizational unit? [Unknown]: Computer ScienceWhat is the name of your organization? [Unknown]: Hong Kong University of Science and TechnologyWhat is the name of your City or Locality? [Unknown]: Hong KongWhat is the name of your State or Province? [Unknown]: Hong KongWhat is the two-letter country code for this unit? [Unknown]: CNIs <CN=Renlan Liao, OU=Computer Science, O=Hong Kong University of

Science and Technology, L=Hong Kong, ST=Hong Kong, C=CN> correct? [no]: yes

Enter key password for <Renlan>

(RETURN if same as keystore password):

Code Signing /Developer

Export the public key to a certificate file and sent it to user.keytool –export –keystore liao.store –alias liao –file liao.cert

What is inside?D:\Users\public_html\COMP201\codes\secu>keytool -printcert -

file liao.certOwner: CN=Renlan Liao, OU=Computer Science, O=Hong Kong University of

Science and Technology, L=Hong Kong, ST=Hong Kong, C=cnIssuer: CN=Renlan Liao, OU=Computer Science, O=Hong Kong University

of Science and Technology, L=Hong Kong, ST=Hong Kong, C=cnSerial number: 40a08a25Valid from: Tue May 11 16:09:09 GMT+08:00 2004 until: Mon Aug 09

16:09:09 GMT+08:00 2004Certificate fingerprints: MD5: A0:60:35:22:28:42:3B:18:77:12:EB:43:13:B1:D7:C6 SHA1: 9:34:84:4C:F0:32:B5:B1:17:55:3B:0C:03:FC:87:FE:EC:69:A0:6F

Code Signing /Developer

Sign applets

Create a jar filejar cvf MyApplet.jar *.class

Run the jarsigner tooljarsigner –keystore Liao.store MyApplet.jar Liao

Keystore containing private key

Alias of private key

Code Signing /Developer

Add public key received to his/her store of public keyskeytool –import –keystore certs.store –alias liao –file liao.cert

Include location of public key store to policy fileKeystore “keystoreURL”, “keystoreType”;

Ex: keystore “file:C:\Windows\cert.store”, "JKS";

keystore "http://www.cs.ust.hk/~liao/comp201/codes/secu/certs.store", "JKS";

JKS: type of keystore generated by keytool

Code Signing /Client

Add signedBy “alias” to grant clauses in policy file

grant signedBy “liao" { permission java.awt.AWTPermission "showWindowWithoutWarningBanner"; };

What if client’s policy file does not grant permissions to signed applets Browser will ask for permissions when loading the applets Example: http://www.cs.ust.hk/~liao/comp201/codes/secu/sign2/

Code Signing /User

Effective Java:Creating and Destroying Objects

Agenda Material From Joshua Bloch

Effective Java: Programming Language Guide

Cover Items 1-7

Bottom Line: Understand Java Construction First C++ Creation/Destruction More Complex

Item 1: Consider Static Factory Methods Instead of Constructors

Constructor Calls vs Static Factory Method Alternate way to get an object Sometimes replaces constructors Sometimes augments constructors

// Simple example from Boolean classpublic static Boolean valueOf (boolean b) { return b ? Boolean.TRUE : Boolean.FALSE;}

Item 1: Advantages Unlike constructors, static factory

methods Can have meaningful names Need not create new instances – Can return any subtype of return type

–Reduces client dependency on specific class Can reduce verbosity of creating parameterized type

instances

Advantage 1: Meaningful Names Consider the constructor/factory pair:// Constructs a randomly generated positive BigInteger // that is probably prime, with the specified bitLength BigInteger (int bitLength, int certainty, Random rnd)

vs.

// Returns a positive BigInteger that is probably prime,// with the specified bitLength.

BigInteger.probablePrime (int bitLength, Random rnd)

– Note: The extra constructor argument avoids a clash with another constructor

– Unique parameter lists on constructors are really restrictive

Advantage 2: Not Required To Create New Object

Instance-controlled classes can be useful Can avoid creating unnecessary duplicate objects

–Boolean.valueOf(boolean) is an example

Can guarantee a “singleton” or “noninstatiable” object

Can allow for very fast “equals” test

Advantage 3: Can Return Subtype of Return Type

Consider the java.util.Collections class 32 Convenience implementations of Collection interfaces

– All are static factory methods Interface return type vs. actual classes

Static factory methods can hide multiple implementations

Advantage 4: Reduce Verbosity of Parameterized Type Instances

// Parameterized type instancesMap<String, List<String>> m = new HashMap<String,

List<String>>();

vs.

// Static factory alternative

public static <K, V> HashMap<K, V> newInstance() { return new HashMap<K, V>();}

// Now, client code looks like this// Compiler does type inference!

Map<String, List<String>> m = HashMap.newInstance();

Item 1: Disadvantages of Static Factory Methods

Subclassing impossible without constructors

Naming conventions necessary– valueOf – effectively a type converter (also just of)– getInstance – return instance described by parameters– newInstance – like getInstance, but guarantees distinct

object– getType – like getInstance, but converts type– newType – like newInstance, but converts type

Item 2: Consider a Builder vs. Many Constructor Parameters

Static factories and constructors don’t scale well to large numbers of optional parameters

Bloch’s examples: NutritionFactsTelescoping.java NutritionFactsBeans.java NutritionFactsBuilder.java

The last version enjoys significant advantages

The problem ?

Consider the case of a class representing the Nutrition Facts label that appears on packaged foods. These labels have a few required fields: serving size, servings per container, and calories per serving and over twenty optional fields—total fat, saturated fat, trans fat, cholesterol, sodium, and so on. Most products have nonzero values for only a few of these optional fields.

What sort of constructors or static factories should you write for such a class?

Telescoping Constructor Pattern.

Traditionally, programmers have used the telescoping constructor pattern.

Provide a constructor with only the required parameters,

Another with a single optional parameter, A third with two optional parameters, and so on,

culminating in a constructor with all the optional parameters.

Here’s how it looks in practice

What do you think of this code? Is it good or bad?

Continue….

When you want to create an instance, you use the constructor with the shortest parameter list containing all the parameters you want to set:

Disadvantages This constructor invocation will require many parameters that you

don’t want to set, but you’re forced to pass a value for them anyway.

It is hard to write client code when there are many parameters, and harder still to read it.

If the client accidentally reverses two such parameters, the compiler won’t complain, but the program will misbehave at runtime.

Think of another solution ??????

Second Solution

A second alternative when you are faced with many constructor parameters is the JavaBeans pattern.

How does it look like??????

JavaBeans Pattern Solution

Problems It is easy, if a bit wordy, to create instances, and easy to

read the resulting code.

JavaBeans pattern has serious disadvantages of its own. Construction is split across multiple calls, a JavaBean may

be in an inconsistent state partway through its construction.

The class does not have the option of enforcing consistency merely by checking the validity of the constructor parameters.

It can cause errors at runtime, as the compiler cannot ensure that the programmer calls the freeze method on an object before using it.

Builder pattern Solution There is a third alternative that combines the safety of

the telescoping constructor pattern with the readability of the JavaBeans pattern.

It is a form of the Builder pattern Instead of making the desired object directly, the client calls a constructor

(or static factory) with all of the required parameters and gets a builder object.

Then the client calls setter-like methods on the builder object to set each optional parameter of interest.

Finally, the client calls a parameterless build method to generate the object, which is immutable. The builder is a static member class of the class it builds

Item 3: Enforce Singleton Property

A Singleton is a class that’s instantiated exactly once Two approaches before Enums:

Public static member (a constant, of course) Public static factory method

Enum singleton is now preferred Lots of subtle advantages: security, serialization, etc.

Item 3: Code Example// Option 1: public final fieldpublic class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() {...}}// Option 2: static factory methodpublic class Elvis { private static final Elvis INSTANCE = new Elvis(); private Elvis() {...} public static Elvis getInstance() { return INSTANCE;

}}// Option 3: Enum type – now the preferred approachpublic enum Elvis { INSTANCE; …}

Item 4: Enforce Noninstantiability With a Private Constructor

Some classes just group static methods and/or fields Makes no sense to instantiate such a class

Trying to enforce noninstantiability by making class abstract doesn’t work Subclassing is possible Clients are led to believe subclassing makes sense

However, a private constructor does the job

Item 4: Code Example

// Noninstantiable utility classpublic class UtilityClass { // Suppress default constructor for noninstantiability private UtilityClass() { throw new AssertionError(); } ... // Remainder of class omitted}

// Note that no subclassing is possible (constructor chaining...)// Note that client can’t call constructor// Note that if constructor is mistakenly called inside class,there

is an immediate assertion violation.

Item 5: Avoid Creating Unnecessary Objects

On the one hand, performance is a secondary concern behind correctness

On the other, gratuitous object creation is just bad programming// String s = new String(“stringette”); // Don’t do this!vs. // String s = “stringette”; // Let JVM optimize for you

// Also see earlier Boolean.valueOf() static factory example

Item 5: Code Examplepublic class Person { private final Date birthDate; // Other fields, methods, and constructor omitted // DON’T DO THISpublic boolean isBabyBoomer() { // Unnecessary allocation of expensive object Calendar gmtCal =

Calendar.getInstance(TimeZone.getTimeZone(“GMT”)); gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0, 0); Date boomStart = gmtCal.getTime(); gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0, 0); Date boomEnd = gmtCal.getTime(); return birthDate.compareTo(boomStart) >= 0 && birthDate.compareTo(boomEnd) < 0; }}

Item 5: Code Example Fixed

public class Person { private final Date birthDate; // Other fields, methods, and constructor omitted private static final Date BOOM_START; private static final Date BOOM_END; static { // Note static block Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone(“GMT”)); gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0, 0); BOOM_START = gmtCal.getTime(); gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0, 0); BOOM_END = gmtCal.getTime(); } public boolean isBabyBoomer() { return birthDate.compareTo(BOOM_START) >= 0 && birthDate.compareTo(BOOM_END) < 0; }}

Item 5: Autoboxing Overhead

// Hideously slow program! Can you spot the object creation?

public static void main(String[] args) { Long sum = 0L; for (long i =0; i < Integer.MAX_VALUE; i++) { sum += i; } System.out.println(sum);}

// Lessons: 1) prefer primitives to Boxed primitives// 2) watch for unintentional autoboxing

The variable sum is declared as a Long instead of a long, which means that the program constructs about 231 unnecessary Long instances (roughly one for each time the long i is added to the Long sum).

Item 7: Avoid Finalizers

finalize() is a method in the Object class What the garbage collector may call when cleaning up an

unused object Finalizers: unpredictable, dangerous, unnecessary!

They are NOT the analog of C++ destructors There is no guarantee a finalizer will ever be called Finalizers have severe performance penalties Instead, provide explicit termination methods

Sometimes requires “finalizer chaining”

Item 7: Code Example

// try-finally block guarantees execution of termination method

// termination method ensures resources are released

// Example resources: database connections, threads, windows

Foo foo = new Foo();try { // Do what must be done with foo} finally { foo.terminate(); // Explicit termination method in Foo

}

Item 7: Finalizer chaining// Manual finalizer chaining// Only do this if you *have* to use the finalizer@Override protected void finalize() throws Throwable { try { .. . // Finalize subclass state } finally super.finalize(); // Note order of finalizer chaining }}

// Also consider “Finalizer Guardian” idiom for public, nonfinal// classes. The goal is to ensure that finalization takes place// even if subclass finalizer fails to invoke super.finalize()