Java App With Online Database

[hype 0]

I'm trying to create a Java Application which will be able to preform CRUD with perhaps a MySQL database hosted online. However, I'm worrying over security issues, including authentications and especially how would the server authenticates that the data is actually generated or sent by the Java Application, not someone who break into my application, change the code and modify the data that is being send to the server and updated into the database.Is there any form of authentication or perhaps is there an alternative that can be use in Java to perform such process in a more secure way?

[manish-mohania 0]

I'm trying to create a Java Application which will be able to preform CRUD with perhaps a MySQL database hosted online. However, I'm worrying over security issues, including authentications and especially how would the server authenticates that the data is actually generated or sent by the Java Application, not someone who break into my application, change the code and modify the data that is being send to the server and updated into the database.
Is there any form of authentication or perhaps is there an alternative that can be use in Java to perform such process in a more secure way?

For java related security, please refer to :
1) SecurityManager Class
2) Java Policy Tool

You can restrict which ip-address is allowed to access the database remotely.

Also, you can implement user login feature to authenticate/authorize the user.

[shadowx 0]

Well in theory you could send a token to the Java app from the server perhaps just an MD5 of the current date/time then have the Java app perform some modification, perhaps reversing the string or something like that and sending the token back with the SQL data. If the token doesnt meet the requirements (you would need to store the token the server sends out and then perform the same modification EG reverse it, and compare the two) scarp the data and block the IP.you could also program in a token into the app itself just so it sends a sort of "password" along with the SQL data that authenticates it. Both methods are vulnerable to decoding the app and going through the resulting goo of code to find the method employed but if they can do that then your SQL data is in trouble anyway....

[hype 0]

For java related security, please refer to :1) SecurityManager Class
2) Java Policy Tool

You can restrict which ip-address is allowed to access the database remotely.

Also, you can implement user login feature to authenticate/authorize the user.

Yea I do have login feature to authenticate the users. However my scenario is as follows:

I have an application in which users will use it to gain credits with a credit system. After performing some task through the java application, they will be entitled to some credits in which the application will inform the server abt the amount to be credited and to whom it should be credited.

My problem is what if someone decode my application, found the way in which the application communicates with the server, and then modifies the application so that he can always send his own desire amount of credits.

Would this be a definite problem for Java Applications or is there any workaround to it? Because it would be best if I could use Java for this particular application.

Well in theory you could send a token to the Java app from the server perhaps just an MD5 of the current date/time then have the Java app perform some modification, perhaps reversing the string or something like that and sending the token back with the SQL data. If the token doesnt meet the requirements (you would need to store the token the server sends out and then perform the same modification EG reverse it, and compare the two) scarp the data and block the IP.
you could also program in a token into the app itself just so it sends a sort of "password" along with the SQL data that authenticates it.

Both methods are vulnerable to decoding the app and going through the resulting goo of code to find the method employed but if they can do that then your SQL data is in trouble anyway....

Yea this is a good idea but as you said, if someone were to decode it that would prove the security measures useless already. I was thinking about applet but it would result in the same outcome as well. Web application would not be that flexible as the application would be restricted by the browsers limitivity.

[shadowx 0]

I dont think there is a real way around this, unless you compile your application when the user requests it:HTTP request for myapp.appPHP/CGI/ASP application starts compiling myapp.app PHP/CGI/ASP creates a custom "token" that is valid for 5/10/20 minutes and is logged in a log at the time it starts/expiresPHP/CGI/ASP is still compiling the code for the app so it inserts the custom token into the code and carries on compilingmyapp.app is ready to be used with its custom tokenwhen the data comes in from the app the server checks its logs for the token which is also sent in to the serverIf the log shows the token as expired the app reloads the page or gives an error or somethingIf the log shows the token as valid the data is sent on to the SQL database and what not.This way each app only has a lifespan of a limited time. If you expect the user to use the app for an hour then make the token expire after 1:20 or something practical. The limitation here is i dont know how/if its possible to make a PHP/CGI/ASP script to compile a java app. I suspect it is but im not 100%You could theoretically change the token into being the app name, so instead of "myapp.app" you get RANDOM_TOKEN.app Have the app referenced in the HTML as a PHP page: app_src="app_create.php"Then app_create.php makes a token up randomly, assigns an expiry time/date in a log somewhere and then sends out the app named as RANDOM_TOKEN.app (eg 144DFFGVR4DBD.app) And have the app transmit its own name with the data and that can act as your token and no compiling needed. Just a bit of copy/rename/send of an app file.

[hype 0]

I dont think there is a real way around this, unless you compile your application when the user requests it:
HTTP request for myapp.app
PHP/CGI/ASP application starts compiling myapp.app
PHP/CGI/ASP creates a custom "token" that is valid for 5/10/20 minutes and is logged in a log at the time it starts/expires
PHP/CGI/ASP is still compiling the code for the app so it inserts the custom token into the code and carries on compiling
myapp.app is ready to be used with its custom token
when the data comes in from the app the server checks its logs for the token which is also sent in to the server
If the log shows the token as expired the app reloads the page or gives an error or something
If the log shows the token as valid the data is sent on to the SQL database and what not.

This way each app only has a lifespan of a limited time. If you expect the user to use the app for an hour then make the token expire after 1:20 or something practical.

The limitation here is i dont know how/if its possible to make a PHP/CGI/ASP script to compile a java app. I suspect it is but im not 100%

You could theoretically change the token into being the app name, so instead of "myapp.app" you get RANDOM_TOKEN.app

Have the app referenced in the HTML as a PHP page: app_src="app_create.php"

Then app_create.php makes a token up randomly, assigns an expiry time/date in a log somewhere and then sends out the app named as RANDOM_TOKEN.app (eg 144DFFGVR4DBD.app) And have the app transmit its own name with the data and that can act as your token and no compiling needed. Just a bit of copy/rename/send of an app file.

That might be a solution for it if the user must access the application from the website itself, which only open door to Java Applet and Java Web Start. Application that resides on desktop would not work, which means I'm left with having the users to download the application everytime they uses it.

I guess I'll think about it and maybe I'll use some manipulating of the tokens with some authentication. Banning system comes handy too, but requires lots of monitoring.

Thanks for all the advise!
Edited September 24, 2009 by hype (see edit history)

[shadowx 0]

If you want the app to reside on their desktop have it download a "cookie" like a small text file, possibly encrypted which contains a token made by the server (you could also just have the app request a token which it then stores in its own memory as a variable, hence it will be destroyed when the user closes the program) and again have the token expire after a certain time and have the app send the token off each time. That way the user has the Java app on their desktop but it requires the "key" or token, from the server before it can be used.

[hype 0]

If you want the app to reside on their desktop have it download a "cookie" like a small text file, possibly encrypted which contains a token made by the server (you could also just have the app request a token which it then stores in its own memory as a variable, hence it will be destroyed when the user closes the program) and again have the token expire after a certain time and have the app send the token off each time.
That way the user has the Java app on their desktop but it requires the "key" or token, from the server before it can be used.

That sounds promising, but I think if the user edit the application in a way such that he doesn't touch the code where the application communicates with the server and the user alters the data(credit) being send to the server for only, everything would defeat it's purpose.

The user can also make their own application which can download and send the token as well to the server right? Correct me if I'm wrong, not too sure about all these stuff.

Something just struck me, how about generating an MD5 of the current application being used to prove the original application was used?

[shadowx 0]

"Something just struck me, how about generating an MD5 of the current application being used to prove the original application was used?"Funny as it seems i just thought of that too :lol:That would indeed solve the problem i think....You could have the app MD5 itself as it sends the data (perhaps MD5 the file myapp.app or whatever you call it) and that can then be the "key" that shows it is legit. Though then someone could write their own app that just sends an MD5 hash that they made themselves from your file, and just send that off using their own app... SO you would need someway of ensuring that the MD5 hash came from the program that is sending it, otherwise i could manually make an md5 hash of your app, and then make my own app that sends the message md5="somehashq32353wed" credits="=1000000000000" and as far as your server can tell it is a legitimate request and i would get lots of credits...This is a fairly tough one...

[hype 0]

"Something just struck me, how about generating an MD5 of the current application being used to prove the original application was used?"
Funny as it seems i just thought of that too

That would indeed solve the problem i think....

You could have the app MD5 itself as it sends the data (perhaps MD5 the file myapp.app or whatever you call it) and that can then be the "key" that shows it is legit.

Though then someone could write their own app that just sends an MD5 hash that they made themselves from your file, and just send that off using their own app... SO you would need someway of ensuring that the MD5 hash came from the program that is sending it, otherwise i could manually make an md5 hash of your app, and then make my own app that sends the message md5="somehashq32353wed" credits="=1000000000000" and as far as your server can tell it is a legitimate request and i would get lots of credits...

This is a fairly tough one...

Yep, that's exactly what's troubling me.. It's indeed a tough one, still in search of a good solution to it. I guess I need some research on the web for normal practises of others.

[shadowx 0]

I dont know how easy it is to reverse engineer a Java applet... Im not sure how complex their compiling algorithm is, but it might be something to worry about that much. It would be a good idea to have a reasonable limit on the server to say 5 or 10 credits, some sort of limit that if the credits are more than that the user must be cheating somehow. You'd have to know how many credits it is reasonable for the user to get per day/hour or something and work out an upper limit. Also, depending how large the applet is going to be you could make a client which users save to their desktop and it can be a simple VB application with a web browser embedded in it which then loads the applet direct from your server in the same way it would load if you had as part of any HTML page. The disadvantage is that if the applet is really big users could easily get annoyed. But if you followed this approach you could use one of the other methods above of setting a token or key and assigning it to a particular copy of the applet for a short time.