Jump to content

Only allow script to be ran from game request


Zephni

Recommended Posts

This may sound like a weird one. I'm in the process of making a HTML5 game where I need to make contact with a MYSQL database. I planned on doing this using PHP scripts that the game sends AJAX requests to with post data. Is there a way of securing these scripts so no one on the outside can access (or just run) them, but the game can. The game will be ran on the same server as the scripts.

 

Does this sound ridiculous or is it possible? Or am I going about this the entirely wrong way, thanks for any answers in advance!!

Link to comment
Share on other sites

Even if someone gains direct access to the PHP files nothing should happen. The PHP source code is not viewable from the browser (right click > view source), only the output.
 
You could prevent direct access to the files if the request is not from ajax.

if(!empty($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) != 'xmlhttprequest') {
	die('Access Denied'); // not an ajax request kill it
}

// code to complete ajax request
Edited by Ch0cu3r
Link to comment
Share on other sites

 


Ok, but what if someone else set up a AJAX script to post data to my PHP file and make changes to the database that I don't want them to?

 

That's the problem with browser-based games; a hacker can see exactly what you are sending back and forth so you can't prevent them from trying to modify the messages your game sends to the server. You can try to add things like a checksum to make creating false messages more difficult, but in the end your HTML5 code can be read and modified completely.

 

This is why browserbased games usually let the server keep track of the important events, using the browser only as a way of interacting with the player. Then the worst a player can do is automate the response and be really quick, but he cannot for example submit an illegal highscore, or select an option that the server doesn't allow.

Link to comment
Share on other sites

 


If you have a login to the game stored in a session then if you have a session_start() at the top of the AJAX script you can make sure that the user is logged into the game and that the request comes from his browser.

 

Actually, all you know then is that a particular sessionid was supplied. If you want to know that the dat came from a particular browser you have to try to identify that browser, whch iy can't because all you have is what the browser tells you, and all of that can be spoofed, except for the IP, but the IP is not necessarily unique to a browser and with mobile devices they can even change while browsing.

 

But, identifying the browser is a separate issue, the real problem is making sure that the data that you receive is legit, and not faked by a hacker (who can also login legitimately)

Link to comment
Share on other sites

Actually, all you know then is that a particular sessionid was supplied. If you want to know that the dat came from a particular browser you have to try to identify that browser, whch iy can't because all you have is what the browser tells you, and all of that can be spoofed, except for the IP, but the IP is not necessarily unique to a browser and with mobile devices they can even change while browsing.

 

But, identifying the browser is a separate issue, the real problem is making sure that the data that you receive is legit, and not faked by a hacker (who can also login legitimately)

You are right. If the hacker is playing the game he can have a valid session and take the session ID provided and feed it into a program that then takes over. Having a session ID, does solve the original problem of someone outside who is not playing the game accessing the AJAX scripts which is how I interpreted the OP's original request.

 

Is there a way of securing these scripts so no one on the outside can access (or just run) them, but the game can

If you want to make it so that a browser can access a script but the same user, sitting at the same machine can not access that script with the same userid with a program then I think that you are sunk. The browser after all is just a program.

Link to comment
Share on other sites

 


 Having a session ID, does solve the original problem of someone outside who is not playing the game accessing the AJAX scripts which is how I interpreted the OP's original request.

 

True.

 

I guess the question is a bit too obvious because how can you register a player's moves in a game if you can't identify the players individually? And if you can identify the players then you can also identify non-players.

Then the only problem remaining is how do you identify a cheating player (which will be 98% of your problems)

Link to comment
Share on other sites

Then the only problem remaining is how do you identify a cheating player (which will be 98% of your problems)

I think that the best you can do is build in a challenge/response mechanism where the server challenges the client to authenticate it occasionally and the code to generate the response is hard to replicate. I can't imagine it would be worth the effort, the code to generate the response would probably be easy to steal if it ran in the browser and it would be hard to obfuscate, nor would it be foolproof in other ways. Seems to me it would be easier to either play the game or hire a gamer in the third world to play it for you than to write a program to cheat.

Edited by davidannis
Link to comment
Share on other sites

 


I can't imagine it would be worth the effort, the code to generate the response would probably be easy to steal if it ran in the browser and it would be hard to obfuscate

 

 

Indeed, all the code that handles the response is loaded on the browser, so the system cannot depend on anything the client does.

 

But, don't underestimate scriptkiddies and the people with no social life, they will happily invest days to hack it, just to be able to say they did.

If money or other prizes are involved this gets even worse.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.