I'm a little frustrated because i focused on this problem for long hours and i haven't found any way to solve it yet.
I'm following this guide: Online High Score Table (AJAX, PHP, MySQL)
https://www.scirra.com/tutorials/346/on ... -php-mysql
This tutorial is great, really well done. But theres a thing that makes me worry. Since the project uses Ajax to send the data, is there a way to secure these data?
Is there a way to make this highscores table more secure?
I hope someone could lend me a hand. Thanks a lot!
Develop games in your browser. Powerful, performant & highly capable.
I haven't given up yet!
I need to know this to. How?
vitormb Since i don't want mail telling me im wrong let me start with I'm not an expert and don't know what best practices are and I assume others reading this may have more knowledge about this but since no one answered ill give my 2 cents.
Assuming your hosting your own server and as it looks by your statement you have one and you also authenticate a user before they can play (IE username and password required to play) then once they login you have PHP generate a key/token that is required for every request from that user for this session and send it back to C2 in the Ajax response after they login.
Your user table can store this token after they login.
Example Table Columns:
token: abc123 (generate this randomly..doesn't matter what it is... but it changes every time they login)
C2 recieves the "abc123" token and sends it back with every request.
You future C2 ajax requests would look like this
When PHP get this request it first validates the token belongs to the user by looking up in the table. If it matches then you at least know this request came from the user you expected it to and their session is valid. Every Ajax request they send from that point on needs to have their user name and that token to be a valid request for that user. Else the requests are just ignored. All requests are now tied to the user and this solves one problem where a user can't hack any body else's properties (unless they somehow figure-out someone else's password).
Now to prevent them from hacking there own account PHP needs to validate the request came from the correct C2 session. This way you know the request came from C2 and not another browser window (IE Hacking). There are many ways to do this and NONE of them are full proof but they will make it much more complicated for a would be hacker to try and game the system (hopefully so much they give up trying). So same as for the user you need to generate a session token for the C2 client. how ever this one should be an integer since it will be used in an equation for validation.
Table Columns Example
c2_token : 111 (generate this randomly..doesn't matter what it is)
C2 receives the "111" token at login, stores it and uses it for the base in its encryption algorithm (this is a simple example so you can expand on making it more difficult if you want later by sending multiple tokens instead of just one).
so now you Ajax request looks like this:
(in an ideal environment for unbreakable encryption both PHP and C2 would know ticks at the same time and you wouldn't have to send it but this is impossible for us to so you have to send it along with the c2_token)
PHP will reverse the equation using the 2 known variables (ticks/token) and the predefined algorithm to solve for 503429.4/45354*2/.2 = 111 If this checks out then PHP knows the request came from C2 for this user. No this is not a very good encryption method but it will stop 99% of amateurs and once you see the basics of how it works you can expand on it to make it a complicated as you want. The trick is just to get PHP to know the request came from the right user and came from the right C2 session. Good Luck
troublesum, Thanks alot for the information!
I'll try it out today when i get back home. We could have more people like you in the world. Thanks for all the time you spent writing your answer.