Advanced Java Programming

1. Advanced Java Programming Security

2. Agenda • About Security • Application Security • Java Security from the Ground Up • Standalone Java Application Techniques

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 • Replayattack • Capture your request and replay that request • Datainterceptionandmanipulation • Read your data (such as credit card info)

5. Common Security Threats • Repudiation • Deny your/his completed transaction • DenialofService • Terminate the service

6. Three concepts of CIA security model

7. CIA Triad

8. 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

9. 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

10. 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

11. Application code ｛ Application Level Java/J2EE APIs JVM System Level ｛ Operating System Application Security- Not just technology; it’s a process… - • System-level Security Vs. Application-level Security

12. 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 Enterprise Data System-level security Attacker

13. System-level Security Vs. Application-level Security (cont.) • Work together to build a secure system/application combination Application-level Security System-level security Enterprise Data Attacker Attacker

14. Application code Application code Application code Java/J2EE APIs Java/J2EE APIs Java/J2EE APIs JVM (Solaris) JVM (IBM AIX) JVM (MS Window) OS (Solaris) OS (IBM AIX) OS (MS Window) 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

15. Java Security from the Ground Up • Java Language Safety Features • Java Security Model • Java Security Architecture

16. 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

17. 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

18. Java Security Enforcement

19. Java Security Enforcement • Enforcement happens at different times • Compile time enforcement • Class load time enforcement • Runtime enforcement

20. Java Source Bytecode Bytecode Verifier Java Compiler ClassLoader Java Virtual Machine Runtime Compile Time Enforcement

21. Compile Time Enforcement Validate language syntax Enforce method and variable access rules Enforce variable initialization Enforce some casting operations

22. Java Source Bytecode Bytecode Verifier Java Compiler Class Loader Java Virtual Machine Runtime Class Load Time Enforcement

23. 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

24. Class Load Time Enforcement • No operand stack overflows • All field and method accesses are legal • Method calls use correct number & types of arguments

25. Java Source Bytecode Bytecode Verifier Java Compiler ClassLoader JavaCompiler Java Virtual Machine Runtime Runtime Enforcement

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

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. What does this code do?

30. 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

31. What happens when executing ? • Use caution when executing Applets as Applications • public class BadApplet extends Applet{ • public void init(){ • try { • Runtime.getRuntime().exec(“rmdirfoo”); • } catch (Exception e) { • System.out.println(e); • } • } • public static void main(String args[]) { • BadApplet a = new BadApplet(); • a.init(); • } • } • Exceptionthrown if run in an Applet container • Exception thrown if run as an application using Applet security Java –Djava.security.managerBadApplet • OK if run as an application Java BadApplet

32. 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; … } • signedBypart omitted if signatures not required for this entry. • codeBase part omitted if the entry applies to code from all sources

33. 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 OS Code signing will be discussed later.

34. Security Policy Files • General form for permissions: permissionclassNametagetName, actionList; className must be fully qualified. • Examples: permissionjava.io.FilePermission "D:\\-","read, write"; // permission to read and write all files in D drive permissionjava.awt.AWTPermission "showWindowWithoutWarningBanner"; // permission to create pop-up window without warning permissionjava.net.SocketPermission “*:8000-8999",“connect"; //permission to connect to any host via port 8000 - 8999.

35. Security Policy Files • Permission classes: java.io.FilePermission java.awt.AWTPermission java.net.SocketPermission java.net.NetPermission java.util.PropertyPermission java.lang.RuntimePermission java.security.AllPermission …. • See page 712 for details

36. Security Policy Files • java.io.FilePermission • Targets: File a file Directory a directory Directory/* all files in the directory * all files in current directory Directory/- 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

37. Security Policy Files • java.net.SocketPermission • Targets: (hostRange:portRange) HostName or IPAddreses a single host localhost or empty local host *.domainSuffixall 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

38. Security Policy Files An example policy file grant 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"; };

39. Security Policy Files • policytool: a utility for creating policy files

40. Security Policy Files Locationofpolicyfile: 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.

41. 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 the policy file grant codeBase "http://www.cs.ust.hk/~liao/comp201/codes/secu/awt/" { permission java.awt.AWTPermission "showWindowWithoutWarningBanner"; };

42. Permission Granting Examples • File Permission example: • Normally, applets cannot read and write local files. • However, FileIOAppletfrom 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"; };

43. 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"; };

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

47. Outline • Using java security mechanisms • Security policy files • Code signing

48. Public Private Key Encryption Alice Bob

50. Code Signing • Developer • Generates a certificate, which contains a pair of keys, a publickey and a privatekey. • 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.