Writing secure code is hard.

The following checklist contains at least some pointer of what to keep in mind. Note that this does not include web development checks. Please check the OWASP Application Security Verification Standard Project for more information on that.

Antipatterns

• Not validating input
• Code has unnecessary permissions
• Misusing public static variables
• Ignoring changes to superclasses
• Assuming exceptions are harmless
• Beliving space of integers is unbounded
• Trust user input to obey invariants
• Beliving a constructor exception destroys the object
• Beliving deserialisation in unrelated to constructors

0. Fundamentals

• Prefer obviously no flaws to no obvious flaws
• Design API’s to avoid security concern (i.e. final classes)
• Avoid duplication
• Restrict privileges (policy files, javax.security.AccessController.doPrivileged)
• Establish trust boundaries
• Minimize number of permissions checks (single point of access)
• Encapsulate methods, fields and classes to coherent sets of behaviour

1. Denial of Service

• Beware of activities that may use dispropportionate resources
  • Image processing
  • Complex object graphs
  • Zip bombs
  • Billion laughs attack
  • Parsing and processing complex grammars
  • Deserialisation processing anomalies
• Release sources in all cases

• Resource limit checks should not suffer from integer overflow

  // off + len can overflow and become negative so the updateBytes // will be called although it should not public void update(byte[] b, int off, int len) { if (b == null) { throw new NullPointerException(); } if (off < 0 || len < 0 || off + len > b.length) { throw new ArrayIndexOutOfBoundsException(); } crc = updateBytes(crc, b, off, len); } // bad if (current + extra > max) {} // good if (extra < 0 || current > max - extra) {} // which gives us if (off < 0 || len < 0 || off > b.length - len) {}

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

  // off + len can overflow and become negative so the updateBytes // will be called although it should not public void update(byte[] b, int off, int len) {     if (b == null) {         throw new NullPointerException();     }       if (off < 0 || len < 0 || off + len > b.length) {         throw new ArrayIndexOutOfBoundsException();     }       crc = updateBytes(crc, b, off, len); }   // bad if (current + extra > max) {}   // good if (extra < 0 || current > max - extra) {}   // which gives us if (off < 0 || len < 0 || off > b.length - len) {}

2. Confidential information

• Purge sensitive information from exceptions
• Do not log highly sensitive information
• Purge highly sensitive information after use
  • Do not depend on garbage collection
  • Keep information local
  • Use char[] to clear traces

3. Injection and inclusion

• Generate valid formatting
• Avoid dynamic SQL
• XML and HTML generation requires care
• Avoid untrusted data on command line
• Restrict XML inclusion
• Care with files
• Disable HTML display in Swing components
• Take care of interpreting untrusted code

4. Accessibility and extensibility

• Limit accessibility of classes, methods and fields
• Limit accessibility of packages
• Isolate unrelated code
• Limit exposure of classloader instances
• Limit extensibility of classes and methods
• Understand how a superclass modifications affects subclass behaviour
• Prefer composition insted of inheritance

5. Input validation

• Validate inputs
• Validate output from untrusted objects as input
• Define wrapper arounds native methods

6. Mutability

• Prefer immatable value types
• Create copies of mutable output values
• Create safe copies of mutable and subclassable input values
• Support copy functionality for a mutable class
• Do not trust identy equality when overridable
• Treat passing input to untrust object as output
• Treat output from untrust object as input
• Define wrapper methods around modifiable internal state
• Make public static fields final
• Ensure public static final values are constants
• Make classes final
• Do not expose mutable statics

• Static variables are global across a JRE

  // Copying values public class MyClass { private static byte[] data; public synchronized static byte[] getData() { return data.clone(); } public synchronized static void setData(byte[] b) { securityCheck(); data = b.clone(); } } // Finalise fields public class FunctionTable { // Can be modified from outside if not final!!! public static FuncLoader m_functions[]; }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  // Copying values public class MyClass {     private static byte[] data;     public synchronized static byte[] getData() {         return data.clone();     }       public synchronized static void setData(byte[] b) {         securityCheck();         data = b.clone();     } }   // Finalise fields public class FunctionTable {     // Can be modified from outside if not final!!!     public static FuncLoader m_functions[]; }

7. Object construction

• Avoid exposing constructors of sensitive classes
• Prevent unauthorized construction of sensitive classes
• Defend against partially initialized instances of non-final classes
  • Throwing an exception from a constructor does not precent a partially constructed instance from being acquired
  • Attacker can override finalize() to obtain object
  • Constructors that call into outside code often naivelt propagate exceptions
• Leaking this enables the same attack as if the constructor directly thre the exception
• Prevent constructors from calling into methods tht can be overridden
• Defend agains cloning of non-final classes

• Throw exception BEFORE super() to destroy object

  // Constructor does not always destroy the object public class ClassLoader { public ClassLoader() { securityCheck(); init(); } } // Attacker can override finalize to get partially initialised // classloader instance and can call into very important methods! public class MyCL extends ClassLoader { static ClassLoader cl; @Override protected void finalize() { cl = this; } public static void main(String[] args) { try { new MyCL(); } catch (SecurityException e) {} System.gc(); System.runFinalization(); } }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

  // Constructor does not always destroy the object public class ClassLoader {     public ClassLoader() {         securityCheck();         init();     } }   // Attacker can override finalize to get partially initialised // classloader instance and can call into very important methods! public class MyCL extends ClassLoader {     static ClassLoader cl;       @Override     protected void finalize() { cl = this; }       public static void main(String[] args) {         try { new MyCL(); }         catch (SecurityException e) {}         System.gc();         System.runFinalization();     } }

8. Serialisation and deserialisation

• Avoid serialisation for security-sensitive classes
• Guard data during serialisation
• View serialisation the same as object construction
• Duplicate SecurityManager checks during serialisation and deserialisation
• Understand security permissions given to serialisation and deserialisation
• Validate the data

9. Access control

• Understand how permissions are checked
• Beware of callback methods
• Safely invoke AccesssController.doPrivileged
• Know to restrict privileges through AccesssController.doPrivileged
• Be careful caching results
• Understand the context transfer
• Understand how thread constructors transfer context
• Safely invoke standard API’s that bypass SecurityManager checkes depending on the callers class loaer
• Safely invoke standard API’s that perform tasks using the callers class loader instance
• Be aware of standard API’s that perform Java language access checks against the caller
• Be aware of java.lang.reflext.Method.invoke is ignored for checking the caller