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
Possibly use the memento design pattern with deserialization. An inner class performs input validation using 'safe' objects, for example,
long
to storeint
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
Do 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)
- Careful while using environment variables - investigate usual conditions
Use HttpSession carefully, Item 25 [Daconta 03]
For 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
- Prefer composition over inheritance
- Avoid flaws in interfaces
- Naming conventions
- Check nonpublic method's params using assertions rather than normal checks
- Create defensive copies of method params
- Prefer interfaces to abstract classes
- Prefer interfaces to Reflection (methods)
- Failure Atomicity (exceptions should not leave object state inconsistent)
- Avoid ThreadGroup APIs (covered)
- Masking, Shadowing, Obscuration
- Issues with ProtectionDomains
Possible Rules
- Do not catch
Error
- Avoid using Reflection to instantiate inner classes
Use a typesafe enum pattern [Bloch, Item 20]- (enum type provided, jdk 1.5 onwards, Docs)
- Some of the anti-patterns described in EXC00-J. Handle exceptions appropriately
- Do not hardcode sensitive information (covered)
compareTo()
contract violations like natural ordering that is not consistent withequals
- Don't catch Throwable without checking for ThreadDeath. (Don't catch ThreadDeath can be considered)
Usage of
GetResource
may be unsafe if class is extended [Findbugs]
- Do not serialize/deserialize resource handles
- Do not sign encrypted data (
SignedObject
should be first, followed bySealedObject
)