applets and sql security

Im not to familiary with applets but ive been reading how they work and the digital? signing for if you dont use the pure java library but use 3rd parties.

So i know i would want to restrict myself from using 3rd party libraries because most people are afraid to accept such things.

How would i best go about making a simple game that handles users and uses mysql database and keeping it secure? would java fx be a better way to go on this?

I was reading about making a servlet? that would handle the sql -> servlet -> applet which seems more of a pain to go through so I wanted to see what everyone thought on here for some ideas or the best ways to go about this, thanks.

just for users?

if so then PHP all the way.

easy to learn, easy to use.

Yeah im still deciding, it would be cooler to do something more dynamic on the client side, its where users log in, interact with information and a database and spits out stuff within say a console window and since it would be client based the user wouldnt have to refresh their webpage for the upated information. SO im still trying to decide what i want to do this in, im now interested in javascript since its client side and can interact with php…? thanks for the reply

[quote]How would i best go about making a simple game that handles users and uses mysql database and keeping it secure? would java fx be a better way to go on this?
[/quote]
the easiest is probably :

PHP ====> mySQL (server side)
/
||
HTTP CALL with session id (using HTTPConection and/or socket)
||
/
unsigned Applet (client side)

your applet tag may give the applet php session id that you will use in your php call later (something like the following) :

<APPLET ...code=... >
<PARAM NAME=PHPSESSID VALUE="<?=session_id();?>">
</APPLET>

in the applet you get the session id and you add it to all your http call:

String id=getParameter("PHPSESSID");

finally to be sure to keep the right session server side you fix session again :

<?
session_id($_GET('PHPSESSID ')); //or $_POST you can also change the parameter name PHPSESSID to something else
//you php to my sql file
?>

EDIT

[quote]How would i best go about making a simple game that handles users and uses mysql database and keeping it secure? would java fx be a better way to go on this?
[/quote]
before reaching your applet page you can do a simple login/pass in php as usual wich will initialise your session id

ok i understand passing the session, thanks by the way for the detailed reply.

How do i go about doing sql commands within the applet, is that possible while keeping it secure fairly secure?

would i just use the sql library and tell the php to send the connection info and have the applet establish a connection with the sql server to do queries?

[quote]How do i go about doing sql commands within the applet, is that possible while keeping it secure fairly secure?
[/quote]
you dont send SQL from applet to php, you send “instruction” to php then php send sql to mysql. no SQL between Applet & PHP and no Database acces from Applet.

scenario:
Applet request user names for exemple it ask for the page users.php
users.php ask the mysql data base => SELECT names from users etc…

ok that makes sense im gonna have to try it this weekend, thanks.

I need a little more help.

Here is my html part, was php but made it more easier to find the bug.

<applet code=MechApplet.class width=650 height=460>
	<param name="what" value="hi2">
</applet>

Then .java part

private String test3 = “hi”; <–just to make it not null at start.
In my init part :

	test3 = getParameter("what");
	System.out.println(test3);

Im getting a null pointer. Am i doing something wrong, missing a step? Wouldnt the getParameter get the what param and make it hi2 ?

Try this:

<applet code=MechApplet.class width=650 height=460>
      <param name=what value="hi2">
   </applet>

That is, remove the quotes from the parameter name.
As seen here : http://java.sun.com/j2se/1.4.2/docs/api/java/applet/Applet.html#getParameter(java.lang.String)

duh, i think that did it, the error is gone, not sure until i have it output onto the textarea i have. thanks i really appreciate the help.

ok just wanted to confirm it does work, my stupid xampp wasnt running it right so i uploaded it to my server and walah! it works :smiley:

Maybe I’m making useless comments cause they are obvious, but if you want security you need to avoid 2 thinks:

  1. Having the applet communicate with the database
  2. Having the applet communicate with php with any other method than POST

A database access needs password, so if your applet knows the password, any client also does. Therefore only a php page on the server knows the password and access the database.
Now if you want to avoid users to use this php page to do diverse requests and try to find a crack in your security, you want to use the POST method (as opposed to GET or whatever) for the applet to transmit infos to the php page. I think there will always be a security issue with an applet not shutting its mouth but ohwell…

   Client                                Server
                          |

applet>>>>>>>> | >>>>>>>>database
applet--------------- | ------ php >>>>>>database
|

critical info
-------- ohwell info

you want to keep critical communications on the server side :slight_smile:
If you need Java/PHP/SQL commands related to that just let me know

PS: yeaaaah now I feel like I’m not just being an ass that uses this forum to advertise a game, but I also contribute (even if its useless)

Post or Get doesn’t really matter as far as security goes except for noob hackers but they aren’t the problem anyway :slight_smile: To make it a bit better you can send (and check) referrer info but that doesn’t solve it either seeing as sniffers/java decompile would see that as well. The best security you can have is to handle as much as possible using php, log what users do and ban their ip when they feed the php page without using the applet.

For example, say that I want to hit a person in my game and have it stored in a database. Instead of sending the damage to the php page let php handle the damage and only tell php “I want to hit this person”.

POST vs. GET is not about security (since both send the data as plain text) but about idempotence. Trying to subvert them for flimsy security reasons is not a good idea.

Idempotent methods (like GET) should not have any effect on the webserver, and may be cached by transparent proxies along the way. That’s the real reason why you should use POST for score submission (which will not be cached or reused in any way).

heu… once again… no interrest in using POST rather then GET for security… POST is more usable for bigger size of data, the GET size limits is a bit random even if some RFC will say you it is Nb octets depending on server it may change

Sorry sorry, I didn’t try to say POST is secure, it’s “ohwell” ;D
Another way is having a coding sequence known by the server and the applet (like a pseudo random loop big enough) and use it to communicate. Therefore, you don’t care about infos in clear, you just care about Java decompiling which I dunno anything about (can we make it difficult?). If the pseudo random algorithm is hard enough to figure out, a hacker will need to wait till it loops, this can take a while!

ya i plan on doing post and my php doing sql stuff and my client just getting data from the php and sending data to php and of course doing a ip banlist.

It isn’t hard to crack that system, java decompiling is extremely easy and 100% precise due to byte code.

There is a couple of ways to make it harder to figure your logic out where the handiest one is to obfuscate your code.

Still, as I said in the previous post, the best way is to let php handle as much as possible instead of relying on the parameters you post.

as said by Mickelukas, if you want avoid player to cheat perform all your logic server side.

if you want to managed user accoount just use standard session login/pass=>session id,one possible way is exlplained in one of my above post.

and finally if you want data to be exchanged in a secure manner between client and server (not viewable by network snifffer) then look at SSL and use https.

It’s important to keep in mind that the formalism of “not sending SQL from the applet” is
a necessary but not sufficient condition. If the language the applet uses to instruct the
agent that constructs the SQL is tantamount to SQL, you’ve only changed the “sql injection”
hazard into a “your private language injection” hazard. To whatever extent you trust the
applet to only make legal requests, you are vulnerable to abuse; and ultimately, no agent
on the thin end of the wire can be completely trustworthy.