Notes for secure Java programming
Normalization - convert all data to common format before checking input since the same character can be represented by different codes in different languages and character sets.
http://docs.oracle.com/javase/tutorial/i18n/text/normalizerapi.html
Code injection - injecting commands into exec statements in Java, for example.
Identification - who user is
Authentication - verify person is who they say they are. Make sure you are using a reputable, solid JAAS implementation
Authorization - verify user is allowed to perform selected action. Many options: again make sure solid source and reputable vendor, well tested over time.
Output encoding - let everything come into your app, then validate and make sure data cannot be executed as code when submitted to any other process. Encode special characters for the output context.
Blacklisting - many ways to bypass. Not best approach. Characters in different languages, character sets.
Whitelist - only accept known good characters. Hard to do because can break functionality - such as when checking names or passwords that may have special characters.
ReDoS - regular expression denial of service attack.
- Deterministic regular expression engines try to match one time
- Non-Deterministic regular expression engines try multiple times - can craft inputs that take systems down. Beware of repeating groups and make characters required if possible.
Use parameterized queries wherever possible to prevent SQL injection
Can use Apache XML encoding library to encode XML data, for example
Jdgui - Java decompiler
JavaSnoop - debug Java code without the source code. Defeats obfuscation tools:
http://resources.infosecinstitute.com/hacking-java-applications-using-javasnoop/
Consider implementing sensitive code in C/C++ and call using JNI. Allows advanced obsfucation, anti-debug, anti-tamper tactics.
Obsfucation and compiling to native code (Excelsior JET, GCJ -- may not be production ready) can make it take longer to get source.
Don't trust client. Even if behind firewall. Some sources report over 50% of breaches are by accidental or intentional insiders. Phishing and social engineering can cause user machine to be hacked and used by an attacker.
Validate XML against XSD (javax.xml.validation.Validator) or DTD (javax.xml.validation.Validator
XML injection - alters XML to invalid format.
XPath injection - XPath concatenation can allow querying additional information. No such thing as parameterized queries for XPath.
External entity attack. Use of word SYSTEM goes external file doctype, entity which can include malicious entity replacements, try to read system files or create DOS attacks.
XML entity expansion attack. Recursive entity replacement to create huge payload what parsed even though initial input is small.
To prevent XML attacks can configure XML parser to disallow vulerable features. Disallow doctype declarations, turn on FEATURE_SECURE_PROGRAMMING. If you require external doctype declarations write a custom entity resolver - this is complicated. Static analysis tools may check for this.
Path Manipulation Attack -unauthorized access to files by breaking out of current path or accessing a file via absolute path. To prevent verify you are in expected directory before proceeding.
Use Java Security manager to limit what code can do. Run your application with the security.manager flag and specify policy file.
Temp files may be pre-created with malicious content. On Unix systems create a symbolic link. Java now has ability to set file permissions.
java.util.random - predictable
Java 7 introduced several new methods in the java.nio.file.Files can create file names with unpredictable names. Also will not create a file if file with that name. Also has shutdown hook to delete temp files. java.io.File.deleteOnExit()
In Java 7 try statement can have objects that implement closeable interface which will be automatically closed on end of try.
Java 7 has a multi catch block to handle multiple types of exceptions.
Race conditions - timing issues while accessing resources causes data to be invalid.
TOCTOU - check a property on a resource then someone changes that resource before the resource is used.
Java Files API has TOC/TOU issues. Checks file properties, then properties could be changed before the file is used because the files API works on file paths. Using the File object does not have this vulnerability because it gets a handle on the actual file.
Deadlocks can cause DoS attack.
Encryption problems: skipping cert checks, no hostname check, no certificate validation, no certain in truststore
HTTPSUrlConnection in Java does this for you - other libraries do not
