Enhancing Security - Expert Oracle and Java Security - page 266

combination of an RMI server (with the unique class loader) and a port server, again with the same
weaknesses.
Weaknesses in All These Approaches
A computer hacker will do better to attack the client than the server. In Java, eventually all those
connection strings are converted into a human-readable form in memory. No matter how fleeting and
transitory, that is our biggest security weakness, and one that we have not solved. Our best efforts in the
utility OracleJavaSecure class only succeed at keeping the connection strings out of the application
code, and in keeping them encrypted until the moment they are needed, then discarding the
unencrypted string.
It is beyond the scope of this topic to look at an obvious protection from an attack on the client -
that is connecting to Oracle database only from a server. Web applications are an example of this: the
user sees the web page, but it is generated from data that is queried by the web server. We have
mentioned RMI, and it could play a potential role in this. With RMI, the client may request data from the
RMI server, and the RMI server would be responsible for querying Oracle database.
If you decide to run all your Oracle queries from a web services, HTTP, or RMI server, then you need
to turn your attention to securing acquisition and use of the Oracle passwords on the server, which is an
identical prospect, albeit more centralized, to what we have been discussing for client application
security.
Get It from a Native Call: JNI
Perhaps we can protect our Oracle password by using a different programming language from Java for
storing and reading our password, maybe even for querying Oracle database. We can write a procedure
in C+ and call it from our Java application using Java native interface (JNI).
Granted, because Java is compiled into byte code that is interpreted by the JVM, the byte code is
slightly more susceptible to decompiling back into source code than compiled C+ code. But code written
in any language can be decompiled or disassembled. Dynamic link libraries (DLLs) and executable
programs are just as open to attack.
I recommend just sticking with Java. For security, maintaining and applying one secure
programming skill set well is better than being semi-fluent and semi-trustworthy in multiple languages.
Get It from an Encrypted Java Class
Okay, we're back to our client Java code, and we're trying to secure our embedded Oracle password. If
we could encode our password so that only our program can read it, that would be good. But we'd have
to hide how our program reads it to keep hackers from duplicating the process and reading the
password.
The question has been asked, and we ask it here again, can we hide what we're doing in Java by
encrypting our class files doing byte code encryption? The answer is yes, and an excellent description of
the process and results was provided by Vladimir Roubtsov in his JavaWorld article, “Cracking Java byte-
code encryption” from May 2003. He subtitles his article “Why Java obfuscation schemes based on byte-
code encryption won't work.”
The heart of Roubtsov's article describes his EncryptedClassLoader . If you recall, we discussed class
loaders in the last chapter regarding realizing our application object and class in the Oracle database. We
said that the ClassLoader cannot realize a class for which he has no prior knowledge, so we put a stub
class on the Oracle database.