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) (done)
- Careful while using environment variables - investigate usual conditions (done)
- 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 (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 (done)
- 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 classes
- Use a typesafe enum pattern [Bloch, Item 20]- (enum type provided, jdk 1.5 onwards, Docs)
- Some of the anti-patterns described in ERR00-J. Do not suppress or ignore checked exceptions (done)
- Do not hardcode sensitive information (done)
compareTo()
contract violations like natural ordering that is not consistent withequals
(done)
- Don't catch Throwable without checking for ThreadDeath. (will not do)
- Usage 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 bySealedObject
) (done)
1 Comment
Dhruv Mohindra
Looks like we need a separate section to cover 'serialization' properly. [Bloch 08] talks about at least a dozen issues that must be addressed by implementers. Sun's forum also has a devoted section on it. If anyone thinks this isn't a reasonable idea, please feel free to leave me a comment here.