Twelve rules for developing more secure Java code

“Twelve rules for developing more secure Java code” “Writing security-conscious Java code can help you avoid security surprises” [1] Article published December 1998 by Gary Mc. Graw, Ph. D, vice president at Reliable Software Technologies Edward Felten, professor of computer science at Princeton Presentation by Stefan Thoren, stho 128@ec. auckland. ac. nz CS 725 - Software Security 9/18/2020 1

Outline n Introduction - Java Security Model n Article objectives - Security rules at code level n Rules grouped, from the developer’s perspective u Really? u Oops, backdoors! u Ha, I knew that! u But… I want to! u Why do that? u Where then? - Rule 1, 8 - Rule 9, 10 - Rule 2, 3, 11 - Rule 4, 5 - Rule 6, 7 - Rule 12 n Summary n Questions See last page for references 2

Java Security Model n Sandbox [2] d uc ti on u JVM - runs the program in an isolated environment u Security manager - checks and restricts access in advance u Compiler and a byte code verifier - ensures that only legitimate java code is executed u Classloader - defines a local namespace to avoid interference between programs u Runtime type safety checking n Java language has built-in security features u Automatic memory management and garbage collection u Type-safety and range checking on strings and arrays This environment does not ensure that the Java code executed is secure! 3

Security rules at code level n Writing secure java code is very difficult u Developers need all help they can get. n Based on u Experience from the Secure Internet Programming Team at Princeton and others (>7 experts) u Authors “…experience in hunting down java security bugs” bj ec tiv es n Checklist style, to keep it simple u Developers can “…save brainpower for other security issues” Discussion - Rules grouped by a developer’s possible reaction 4

R 1: Don't depend on initialization R 8: Make your classes noncloneable ea lly ? n Possible to allocate an object without running a constructor. u Make variables private u Use variable “initialized” to verify everywhere, then set it to true when constructor finishes (same approach for static mechanisms) n Attacker can subclass your class, let that one be cloneable and copy the memory image from your existing object. u Define a class as final or declare a final clone() method 5

R 9, 10: Make your classes nonserializeable and nondeserializeable …bypass the constructor ck d o or s! n Can serialize the internal state of your objects to a readable byte array u Declare a final write. Object() method, throw exception n Can create a sequence of bytes to be deserialized into an instance of your class u Declare a final read. Object() method, throw exception 6

R 2: Limit access to your classes, methods, variables R 3: Make everything final R 11: Don't compare classes by name n General programming guidelines e w th at! u. Pfleeger [3]: Modularity, Encapsulation, Information Hiding Tight coupling Independent, loosely coupled modules Access to all parts of module Method, data hidden n Use final, otherwise an attacker (or user) can: u. Extend class in a dangerous / unforeseen way u. Override method behavior 7

R 4: Don't depend on package scope R 5: Don't use inner classes w an t to ! n Package scope is intended to prevent innocent, accidental access to things you want to hide n Give up extensibility for security! u Extensibility = more ways to cause trouble u An attacker can insert a malicious class in your package to get access to “hidden” (package scope) functionality n. Inner classes are translated to ordinary classes by the compiler u. Provides access to any code in the same package u. Inner class have access to private stuff in the outer class 8

R 6: Avoid signing your code R 7: If you must sign your code, put it in one archive file n Signed code has special privileges do th at ? u E. g. file access in a specific folder u Perform a dangerous operation n Unsigned code is less likely to do damage n Minimize code amount with special privileges u Easier to keep track of possible access paths u Audit that code more carefully n Mix-and-match attack by linking other code with your signed classes u By signing a group of classes together and put them in an archive such an attack becomes more difficult u Still, the attacker can mix different versions of signed classes 9

R 12: Secrets stored in your code won't protect you n Leave passwords and cryptographic keys outside n Java byte code is informative re th en ? u Contains line number table, local variable names, source filenames n A malicious programmer or a virtual machine can look inside your code u An attacker can reverse engineer your code using a decompiler n By using an obfuscator the extra information is removed and the code is “shuffled” (still not enough) 10

What have we learned? m m ar y n Add variable “initialized” to check everywhere n Make everything private and final by default n Add final clone() method n Add read. Object() and write. Object() methods that throws exception n Improve your programming style n Choose extensibility or security (package scope, inner classes) n Minimize privileged code amount, put in separate archive file n Secrets somewhere else…? 11

Thank you for listening! sti o ns ? Questions: n Are the rules still valid (article = JDK 1. 2)? n Will developers happily conform to these rules? n What must be added to help or force developers to think about security? n Can you mention other code-level security rules? 12

What must be added to help or force developers to think about security? n Use a process model, e. g. RUP n Use security audits n Perform code reviews n Security analysis tools n Extensive testing n Learn to use obfuscators 13

er en ce s n [1] G. Mc. Graw, E. Felten, Twelve Rules for Developing More Secure Java Code, Java. World, 01 December 1998, http: //www. javaworld. com/javaworld/jw-121998/jw-12 -securityrules. html, March 2002. n [2] L. Gong, Secure Java class loading, IEEE Internet Computing, vol. 2, no. 6, Nov. -Dec. 1998. n [3] C. Pfleeger, Security in Computing, 2/e, Prentice Hall PTR, 1997. 14