3. Security Defined “Freedom from undesirable events”. (Neumann) There are usually three elements to security :  Confidentiality  Integrity  Availability

4. What is Security? Safe from malevolent programs Non-intrusive Authenticated Encrypted Audited Verified C2 or B1 certified

5. Why Java Security is important? Java security is important to a number of distinct sets of people Web users Developers of Java code System administrators

6. Guidelines for Java Web Users Web sites visited Learn about Java security Java environment Security updates Security alerts Apply drastic measures Assess your risks

7. Guidelines for Java Developers Rule 1: Don't Depend on Initialization Rule 2: Limit Access Rule 3: Make Everything Final Rule 4: Don't Depend on Package Scope

8. Developers of Java Code Cont. Rule 5: Don't Use Inner Classes Rule 6: Avoid Signing Your Code Rule 7: Archive file

9. Rule 8:Classes Uncloneable public final void clone() throws java.lang.CloneNotSupportedException { throw new java.lang.CloneNotSupportedException(); }

10. Rule 9: Classes Unserializeable private final void writeObject(ObjectOutputStream out) throws java.io.IOException { throw new java.io.IOException("Object cannot be serialized"); }

11. Rule 10: Classes Undeserializeable private final void readObject(ObjectInputStream in) throws java.io.IOException { throw new java.io.IOException("Class cannot be deserialized"); }

12. Rule 11:Don't Compare Classes by Name if(a.getClass( ) == b.getClass()){ // objects have the same class }else{ // objects have different classes } Rule 12: Secrets Stored in Your Code Won't Protect You

13. Other People Security Effects System Administrator –Install, configure and manage the products –For managers who decide which products are developed and they are developed.

14. Java Security Manager Class that allows applications to implement a security policy Useful to determine a possibly unsafe or sensitive operation The application can allow or disallow the operation

15. Java Security Manager Descends from class java.lang.SecurityManager For each potentially unsafe action, there is a method in the security manager that defines whether or not that action is allowed by the sandbox.

16. Method’s Classification The methods in the Security Manager can be broadly classified into groups  Methods protecting file access e.g. checkRead(String file)  Methods protecting network access: e.g. checkAccept(String host, int port)

17. Method’s Classification  Methods protecting program threads  Methods protecting the JVM e.g. checkExit(int status)  Methods protecting system resources e.g. checkPrintJobAccess( )  Methods protecting Java security aspects e.g. checkSystemClipboardAccess( )

18. Anatomy of a Java Application

19. The bytecode verifiers The class loader The access controller The security manager The security package The key database

20. The Bytecode Verifier  The bytecode verifier ensures that Java class files follow the rules of the Java language.  In terms of resources, the bytecode verifier helps enforce memory protections for all Java programs.

21. Class Loader / Access Controller The class loader One or more class loaders load classes that are not found on the CLASSPATH The access controller The access controller allows (or prevents) most access from the core API to the operating system.

22. The Security Manager Primary interface between the core API and the operating system Allowing or preventing access to all system resources The access controller used for decision making Responsibility on actions

23. Security Package / Key Database Security Package Basis for authenticating signed Java classes.  The security provider interface Message digests Keys and certificates Digital signatures Encryption (an optional extension to the security package) The key database / digital signature

24. Potential Threats There are four basic categories of potential attacks Java applets could facilitate:  Attacks that modify the system  Attacks that invade a user's privacy  Attacks that deny legitimate use of the machine by hogging resources  Attacks that antagonize a user

25. Potential Threats ATTACK CLASS EXPLANATION AND CONSEQUENCES JAVA DEFENSE Invasion of Privacy If you value your privacy, this attack class may be particularly odious. They are implemented by malicious applets. Include mail forging. Consequences of these attacks: moderate. Strong Denial of Service Also serious but not severely so, these attacks can bring a machine to a standstill. Also implemented by malicious applets. May require reboot. Consequences of these attacks: moderate. Weak Antagonism Merely annoying, this attack class is the most commonly encountered. Implemented by malicious applets. May require restart of browser. Consequences of these attacks: light to moderate. Weak

26. Invasion of Privacy Disclosing information about a user or host machine that should not be publicized  On Unix machines, if someone gains access to the /etc/passwd file (which contains usernames and encrypted passwords) he or she could mount a password - cracking attack. A successful password - cracking attack

27. Denial of Service System resources become unavailable. There are many subcategories of denial of service attacks. Some examples include:  Completely filling a file system  Using up all available file pointers  Allocating all of a system's memory  Creating thousands of windows, effectively denying access to the output screen or window event queue  Using all of the machine's cycles (CPU time) by creating many high-priority threads

28. Antagonism Sometimes seemingly antagonistic attacks may be the result of simple programming errors. Examples:  Playing unwanted sound files through a speaker  displaying obscene pictures on a monitor

29. Java Risks in Perspective Stopping the worst potential attacks that hostile applets might carry out System modification and invasion of privacy attacks One kind of mobile code that everyone wants to avoid is a computer virus

30. Java Sandbox Restriction of programs Damage can be done in the sandbox, but will not affect other applications, system resources, and files. Three steps of defense:  Byte Code Verifier  Class Loader  Security Manager They depend on each other Each part must do its job properly

31. Java Sandbox Java is designed so that programs can be dynamically loaded over the network and run locally Restriction on programs Damage can be done in the sandbox, but will not affect other applications, system resources, and files.

32. Java Sandbox Three steps of defense:  Byte Code Verifier  Class Loader  Security Manager They depend on each other Each part must do its job properly

33. Type Safety Programs are prevented from accessing memory in inappropriate ways A program cannot perform an operation on an object unless that operation is valid for that object Most essential element of Java’s security

34. Type Safety Example

35. Type Safety Class tag / Dynamic type checking Static type checking Guarantees security Prevent arbitrary access to memory using typing constraints Encapsulation

36. Where to Find More Information on Java securingjava.com developer.com javaWorld.com unix.org.ua Jia, Xiaoping. Object-Oriented Software Development Using Java. 2 nd Ed. Addison Wesley. 2001