Writing secure java code with RMI

Question

This may seem like a very broad question, but any help is appreciated.

I have a client/server solution written in java which uses the Cajo project (which uses RMI). I just want to try and make my solution as secure as possible, given the sensitive data that will be transferred between server and client.

So far, my ideas are to make all my classes "final" as well as throw a "non-serializable" exception for all my classes in the server (except for the object bound in the RMI registry, and any objects that actually do need to be transferred of course).

Can anyone think of any other ideas?

I know that someone could write a malicious client - this isn't hard to do as you can find out the remote object's API using reflection. However is there anything I can do to protect a malicious client access classes/objects within the server that they are not supposed to access?

Many Thanks

Update: Thanks everyone for the helpful tips, and sorry it took so long to get back to yous. My current train of thought is this for make a secure system:

• Use OpenVPN between the clients and the server. This means that you need access to the physical client to gain access. (NB Due to the 2 points below, the VPN will actually be between the server and the office LAN. I feel that this is secure enough)
• Use usernames and password (maybe using JBOSS) for authentication between server and client. This means that for anything to get done on the server, an attacker would need the username and password.
• Throw a "Non-serizable" exception for all objects, except the ones that are actually supposed to be sent over the network. This stops sensitive objects from being sent over the network.

Does that sound fair? Please correct me if I'm missing anything.

Further Update : It appears there seems to be some confusion over what I'm trying to prevent against. What I'm trying to prevent, is someone from "hacking" the server. So basically exploiting the server to dump/drop its entire database, for example.

Thanks

Answer 1

Protecting a system that connects with potentially compromised systems over RMI is very difficult. The first thing to do is to disable the dynamic code loading feature of RMI using the java.rmi.server.useCodebaseOnly system property - no more mobile code (via this channel). As RMI man Stuart Marks notes, this property is now secure by default , in line with Oracle policy.

Answer 2

I would use a custom socket factory to encrypt all the RMI data. Eg Using SSL will prevent viewing the data, modifying it, and replay attacks.

This tutorial describes how to create a custom RMI socket factory, and a general discussion of RMI over SSL.

• Using a custom RMI socket factory
• The scoop on RMI and SSL (A little old, but should be mostly relevent. SSL is part of the JRE now.)
• Using SSL in the JDK

It might seem like a lot of work, but if you really must hide sensitive data from anauthorized eyes, then making objects final will simply not provide any real security - the sensitive data can still be read.

EDIT: This is all pretty much a moot point, since the OP mentioned in comments below that a VPN is being used.

Answer 3

Does Cajo only let you invoke methods on exported objects? If so, simply only export safe-to-be-invoked-remotely objects. Otherwise you are forced to use the sandbox if you want the hosts to be secure. Also see this .

You will need SSL to prevent sniffing/modification of network traffic.

Answer 4

You mention that you are using VPN, so for a malicious client to connect to your server, they would have to comprimise your VPN, or install rogue software on a machine with legitimate access to your VPN.

Once this is done, then there is no easy way to distinguish a rogue client from your authorized software. You could proide additional credentials to each user of your client software for additional authentication, but these can be comprimised if the client machine is comprimised. A stronger authentication scheme is to send each user a small "widget" that computes access codes. An rogue client will not have access to this, and it cannot be comprimised by software alone since it is physically separate from the client machine. Combining this with a username/password for each user will defeat one user stealing another user's widget.

Depending upon how secure you want it and how much effort you are prepared to invest, this may be overkill. If your primary concern is guarding against an automated attack from a rogue client vs a regular user using the software, you could implement "I'm a human" authentication by presenting a capcha at login.