References

Garfinkel and Spafford, Web Security and Commerce
chapter 3 Java and Javascript (security)

Java Technology - Libraries

The Java libraries are mainly in bytecode, some are in native code.

Provide the program interface to services of the interpreter runtime system and other added features

Many of these are essential but not built in to the language.

The library mechanism (through collections of pre-compiled classes) provides a very powerful means of extending the language for whole areas of applications:

has commercial possibilities (re-usable code, packages can be sold as commodity or designed for specific purposes)

... perhaps...

Java safety features

In the language: - safety comes from stronger type properties, simpler language mechanisms

• no pointers, unlike C and C++ - no pointer arithmetic
  yes references
• strong typing
• strong static type checking
• active string and array bounds checking, null pointer checking
• exception handling model
• object-oriented (? safety? some say so)
• single inheritance in object class definitions - easier to understand/write correctly

In the runtime environment:

• interpreter is sensitive to mode of running
  - can block actions which are outside allowed policy
• interpreter checks validity of downloaded bytecodes
  - prevents doctored bytecodes from being executed

Java - and the kitchen sink

Very popular - more for promise than present delivery

Very appropriate for small-medium scale programs - especially applets
- an unknown in large scale programs (and slow speed may tell)

Not easy to program - nothing really is.

Object code is portable.

Provides dynamic documents economically.

An open standard?

A universal standard?

Java at both ends

Java is a sufficently powerful programming language that it can be used for
- standalone applications
- server-side as well as client-side

E.g. (standalone) implementation of complete browser - HotJava

and implementation of complete server - Jeeves

and complete productivity software - Corel. <URL:http://www.corel.com/javastrat>

Possibility of server-side pieces of code
- servlets as well as client-side applets

and other "mobile" code - (agents) aglets.

Possibility of "thin" clients with hard/firmware Java interpreter (Java on a chip) - downloads all applications as required
- no local file store

the network computer (NC) - Oracle especially.

Why?
- system administration/maintenance costs for enterprise PC networks

Java Security

"safety" - a property of the Java language

"security - a property of the Java language, the Java environment, the Java libraries
and of the whole surrounding environment and usage.

Basis of Java security problem:

• Java wanted for programs that are general purpose
  - no more than local organisational/personal security of user & creator
• Java wanted for downloading programs from the untrustworthy network
  - security has to be enforced automatically

"safer" programs have fewer security problems
- because many security loopholes have come from programs that (deliberately) write outside their allocated memory.
- in C there is no check against this
- commonly seen as buffer overruns - e.g. Internet Morris worm

What can a safe but bad applet do?

A general purpose program is allowed

An unconstrained applet should not be allowed to do all of these.

Java Runtime Environment security model

The difference between applets and general purpose programs is not in the Java language in which they are programmed but in the environment in which they are run.

Security is therefore enforced in the Java Runtime Environment.

1. Java sandbox security model

2. security manager class

3. bytecode verifier

4. class loader

5. digital signatures on bytecode

Java sandbox security model

The "sandbox" is a restricted way of running a Java interpreter
with a security policy
so that no "insecure" operations are permitted.

The effect of violating a restriction is to raise an exception during execution..

The security policy differs for different uses/implementations of the interpreter
i.e. in different browsers and applet viewer utility programs.

These programs determine a level of security checks for classes being interpreted

The level may be automatic or explicitly chosen by user
depending on the source of the class bytecode

Common Sandbox restrictions

Garfinkel and Spafford table 3-1

Implementation of security

The implementation of security is by having a Java interpreter always check
such operations before they are executed.

To allow general purpose programs to implement their own security policies against classes that they download,
the security policy is implemented in an extesible (programmer-redefinable) class.

Security manager class

has methods to check attempts to

Bytecode verifier

is used to ensure that downloaded bytecode is properly formed

• valid JVM code

• does not break strong typing restrictions of the language
• will not overflow or underflow stack in execution
• uses registers correctly

Implemented as ~3500 lines of ad hoc checks - no formal model

Class loader

A functional component of Run Time Environment which pulls classes from network and links with executing code, with some security checks

Loaded classes are put into a separate namespace
so that they cannot replace basic system classes of the same name.

Digital signatures on bytecode

Allows an additional level of trust.

Netscape 4.0, Java 1.1

Based on digital certificates attached to bytecode files,
with user's list of trusted signatures
(public/private key system, list of trusted public keys & identifiers)