0

I'm interested in learning secure coding best practices (specifically for Java apps) and I'm reading OWASP's Secure Coding Practices checklist. Under their Memory Management section they state the following:

Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy, etc.).

I'm not a C/C++ developer, but this must mean that the above functions have security vulnerabilities in them. I ran a couple of searches for vulnerable Java methods and all I came up with was this CVE.

What Java SE/EE methods (if any) apply to this advisory from OWASP?

IAmYourFaja
  • 55,468
  • 181
  • 466
  • 756
  • 1
    Anything involving Strings is suspect since they can be potentially extracted. If the data needs to be secure, better to use char arrays. – Hovercraft Full Of Eels Aug 10 '12 at 00:30
  • Thanks @HovercraftFullOfEels (+1) - can you please explain what you mean when you say "*they can be potentially extracted*"? Maybe give a concrete example? Thanks again! – IAmYourFaja Aug 10 '12 at 00:48
  • Like a `JPasswordField` with the method getText() – Paul Vargas Aug 10 '12 at 00:55
  • 1
    Not trying to be difficult here (!) - but I'm still not seeing what @HovercraftFullOfEels means when he says that string can be extracted. Is he just saying that any Object that has String fields might potentially reveal `toString()`-type information about that Object? – IAmYourFaja Aug 10 '12 at 00:59
  • @pnongrata http://stackoverflow.com/q/8881291/758280 – Jeffrey Aug 10 '12 at 01:23

2 Answers2

3

For C APIs, yes, you can cause problems with those functions by doing unintentional memory corruption if your parameters are not carefully checked.

In Java, since all operations are automatically checked, this class of memory corruption exploit should not happen (barring bugs in the implementation).

Yann Ramin
  • 32,895
  • 3
  • 59
  • 82
2

Those are C functions that are particularly prone to buffer overflow and format string attacks.

Java doesn't typically have those problems, but the same rule of thumb applies -- don't trust your inputs.

Reflection & Serialization

Java's reflection APIs can be a source of vulnerabilities.

If an attacker can cause part of a string they give you to be treated as a class, method, or property name, then they can often cause your program to do things that you did not intend.

For example, 

ObjectInputStream in = ...;
MyType x = (MyType) in.readObject();

will allow an attacker who controls content on in to cause the loading and initialization of any class on your CLASSPATH and allow calling any constructor of any serializable class on your CLASSPATH. For example, if you happen to have a JS or Python interpreter on your CLASSPATH, they may be able to get access to a String -> JavaScript/Python function class from where they might be able to gain access to more powerful methods via Java reflection.

javax.script

javax.script is available in Java 6 and allows converting strings into source code in an embedded scripting language. If untrusted inputs reach these sinks, they may be able to use the script engine's access to Java reflection to reach the file-system or shell to execute arbitrary user-ring instructions with the permissions of the current process's owner.

XML

Java is just as vulnerable to external entity attacks as other languages whereby external entities in an XML input can be used to include content from URLs from the local network.

If you don't hook into java.net.SocketFactory or use a SecurityManager to filter outgoing connections then any XML parse method that does not let you white-list URLs that appear in DTDs is vulnerable.

Runtime / ProcessBuilder

Also not Java specific, but Runtime and ProcessBuilder allow access to executables on the local file-system. Any attacker controlled strings that reach these can potentially be used to elevate permissions.

Mike Samuel
  • 118,113
  • 30
  • 216
  • 245