How to securely communicate with a database using a java applet

Question

I have been writing web applications for quite sometime in PHP with MySQL. I always stored my database connection information into a configuration variable and connected to the database that way.

A client wants a java applet for their website to communicate with their database. I'm very hesitant on this because the applet is going to be public and I am not sure how I would go about storing the database connection information.

I'm paranoid that someone would decompile my application or find some way to extract my database connection information and use it maliciously.

Any suggestions on how to do this securely?

Answer 1

Just to clarify, you're not too worried about the connection being "overheard", you're worried that somebody might hack open your applet and pull out the database connection details, right?

Well I would probably not let it connect directly and instead have it talk to a web-app that returned the data in JSON/XML. People can still grab that from within your applet if they really want to but they're limited to what the web-app can.

If that doesn't float your boat, make sure that the database user the applet uses is limited to doing only what it needs to. If it's just pulling data, don't give it insert permission.

If you're only doing writes, another option is to have a public database and a private database. Writes from your applet go into the public DB and get synced over once verified. The problem with this is you might lose some built-in checks and relationships unless you keep a copy of all the data in the public DB - which may not be safe.

Another option could be to give each user their own database user. Then if somebody unauthorised were to get the applet, they'd still need an account to get in.

I think that building an intermediary web-app is probably your best bet but I don't know the full scenario, so I'm not best placed to judge.

Answer 2

I would suggest to have an applet which communicate with the website. Which itself communicate with the database.

Answer 3

This is a trusted client problem, without looking to deep into JDBC regarding authentication extensions on top of the standard JDBC connections credentials, I suggest that you wrap all requests through your own DB layer.

I have actually implemented a JDBC wrapper using Ajax where the client issues direct SQL statements from within JS to a Servlet which translates those into DB requests, I implemented update and query and the whole implementation is less than 300 lines Java Servlet code and 60 lines of JS code.

The solution does not include any authentication but that is easily added on top of the HTTP layer. Anyway you have a trusted client problem, it does not solve the problem where a hacked client can access the whole database schema outside any predefined or specified use cases, e.g:

select * FROM records

Instead of the backend request:

SELECT id, data, val, ... FROM records WHERE userid = ...

Which only selects the records that was created by the authenticated user. The only way to ensure that security is maintained is to only access the DB through predefined data retrieval/modification methods. Otherwise the security and data isolation must be enforced by the Database itself, Read "expensive big O database" :)

My 400 line JS/Java example above is used in a test system for in house usage only.