How do i secure my high score table? (AJAX, PHP, MySQL)

1 favourites
  • 6 posts
From the Asset Store
An educational game for Times Table. An easy to use template for developers to build larger games
  • Hello there!

    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) ... -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?

    Anyone who access the javascript file will be able to find the URL patch. He'll access: 'savescore.php?name=jhondoe&score=999'.

    Is there a way to make this highscores table more secure?

    I hope someone could lend me a hand. Thanks a lot!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • bump

  • 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:

    name: jhondoe

    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

    name: jhondoe

    token: abc123

    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 what C2 needs to do is every time is sends an Ajax request it needs generate an encripted key using the token that will then be validated by PHP. To start you will need a dynamic variable. Game ticks is probably the easiest to use since they always change and are simple integers. Imagine if game ticks is currently 45354 at the moment you send the ajax request you take that number and do something with it evolving the "111" token it received. Like 111*45354/2*.2 = 503429.4 To be safe were going to assume a hacker will know in advance about "111" as they could see it being received back to C2 at login. So the real algorithm is what comes after in this case i kept it small (X*2/.2) is your encryption. Someone will have to go digging in your code to find it so the more complicated you make it the harder it will be for someone to find it or figure it out. If your javascript is minified (obfuscated) it should be almost impossible to find.

    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.

    Best regards.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)