Page History

Replaceable (weak) guidelines

This page contains adhoc TODO ideas or topics being currently investigated. Please feel free to comment on these or suggest new ones.

Possible Changes to Current Guidelines

• All classes, methods will need to include the final keyword. Although this is against extensibility, it is critical from the security point of view.

• All file separators must be replaced by platform independent File.separator

• Wiki MarkupPossibly use the memento design pattern with deserialization. An inner class performs input validation using 'safe' objects, for example, {{long}} to store {{int}} vals and then updates the state of the actual outer class and so on..., Item 50 \ [Daconta 03\]

• readResolve() for deserialization (singletons). Do not serialize sensitive external mutable variables (best to declare them transient)

• Calling clone.super() is necessary.

...

Possible Recommendations

• Wiki MarkupDo not serialize keys, certificates or the classes that contain their instances, as deserialization may fail if the same security provider is not present at the remote end. Instead, override the readObject, writeObject methods and encode the data. \ [P 202 Oaks 01\] *(unsure if this can be classified as a security error)* (done)

• Careful while using environment variables - investigate usual conditions (done)

• Use HttpSession Wiki MarkupUse HttpSession carefully, Item 25 \ [Daconta 03\]

• Wiki MarkupFor good portability, do not make the assumption - all DBMSs can tolerate several open ResultSet Objects at a time, Item 41 \ [Daconta 03\]

• Thread.interrupted issues

• Java encoding issues (done)

• Prefer composition over inheritance (done)

• Avoid flaws in interfaces (done)

• Naming conventions (will not do)

• Check nonpublic method's params using assertions rather than normal checks (done)

• Create defensive copies of method params (done)

• Prefer interfaces to abstract classes (will not do)

• Prefer interfaces to Reflection (methods) (will not do)

• Failure Atomicity (exceptions should not leave object state inconsistent) (done)

• Avoid ThreadGroup APIs (covereddone)

• Masking, Shadowing, Obscuration (done)

• Issues with ProtectionDomains (if any)

...

Possible Rules

• Poor performance and DoS due to regex (fixed in jdk 1.6)

• Do not catch Error (done)

• Avoid using Reflection to instantiate inner classesunmigrated-wiki-markup

• Use a typesafe enum pattern \ [Bloch, Item 20\]- (_enum type_ provided, jdk 1.5 onwards, [Docs|http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html])

• Some of the anti-patterns described in EXC00-J. Handle exceptions appropriatelyDo not suppress or ignore checked exceptions (done)

• Do not hardcode sensitive information (covereddone)

• compareTo() contract violations like natural ordering that is not consistent with equals (done)

• Don't catch Throwable without checking for ThreadDeath. (Don't catch ThreadDeath can be considered)will not do)

• Usage of GetResource may be unsafe if class is extended [Findbugs Wiki MarkupUsage of {{GetResource}} may be unsafe if class is extended \[Findbugs\]

• Do not serialize/deserialize resource handles (done)

• Do not sign encrypted data (SignedObject should be first, followed by SealedObject) (done)

...