Sneaky: Verifying the authenticity of user generated content in a game situation isn't easy. I recommend obfuscating commands with gibberish sent between the JavaScript and the server. For example if you were to send the x coordinate of the user to the server instead of:
ajax.send('userXLocation=80');
Try something that isn't plain English:
ajax.send('J{};;%FI=80');
Not bulletproof certainly, but with some good JS minification/obfuscation users would have trouble differentiating the commands sent if all they can understand is the number.
In your JS code the gibberish would have to be hard-coded, but in PHP you could have an array that maps the gibberish to the actual commands.
Extra sneaky: Instead of gibberish, used fixed length pre-pended numbers as commands. User X move to 80 could be: 24080
Sneaky: You could also try occasionally sending a unique session identifier (similar to a semi-public key) and instruct JS to encode all messages using that session identifier. This again could be cracked, but it add time to any cracking attempt.
Extra sneaky: This session identifier could be the text of the last response by the server, so with every request it would change, but there wouldn't be any obvious message a hacker could see telling JS that the key had changed. It would all be just innocent communication between JS and PHP.
Sneaky: This is another temporary solution, but to obfuscate numbers you could decide on a constant (possibly one unique for the session) to add or subtract to each number before sending. So if a hacker knew that he was at X position 80 and looked for communications containing 80 he/she wouldn't see any because JS and PHP already decided to add 5 to every number. 85 would be able to pass through undetected.
Super Sneaky: Similar to above, instead of agreeing on an number obfuscation constant, use the number last sent to JS by the server. Again the hacker will be puzzled why the numbers keep changing but there are no messages informing JS to change its numbers.
Sneaky: Again temporary, but when obfuscating code try to mix-in logic with base stuff (creating an ajax object) so even with pretty print for chrome hackers would find your code hard to decipher. Something else to consider is possibly abandoning putting variables in the post completely. It wouldn't last long, but it would be sneaky to pass commands through a cookie (which would be sent with the ajax requests). To be more sneaky, you could have PHP and JavaScript decide when to switch back and forth between post and cookie communications or only use post for non-sensitive things.
Super sneaky: Put core game logic and communication in a file called jquery-1.6.2.min.js. I guarantee most who attempt to hack your script will ignore it.
Ninja Worthy: If you choose to alternate between cookie and post requests create a honeypot on the transport that's not being used. So after PHP sends a response and says, "Hey let's move to cookies!" and JavaScript says, "Sure thing," PHP should listen for attempts to communicate via POST. It should assume since JS is communicating via cookie (for now) if a post request is tried some hacking was involved. It should then frighten the user with a "You're busted" message or even temporarily ban. This should of course flip when they switch back to POST communication.
Beyond Ninja: You could also send GET requests identical to the POST/Cookie ones which would be permanently honey-potted. If there is a discrepancy between the GET and the POST/COOKIE then the hacker assumed that it was as easy as changing some get variables and you could display the same "You're caught" message with possible temporary or permanent bans from your game.
A couple final things:
- Take advantage of new web technologies. If available, you could use web sockets as a transport to make it a honey-potted quartet (WebSockets, POST, Cookies, and GET). You can also use web workers to hide the execution of your special code. Though you would be able to open the JS file for the worker, I don't know of anyway to directly access the scope of the worker from the console or in FireBug.
- Use dumb hackers to your advantage. Place in stupid things that hackers would expect. If some of the security measures look bad or are easy to crack the hacker might get cockey or assume you're a bad coder. They then would proceed to mess up with things like the honeypotted transport system and get busted!
- Finally, always be on the lookout for weird request patterns. If the maximum velocity of a player is 10 pixels a second, but in two requests, only a second apart from each other, the distance traveled is 20 pixels, PHP should know something is up. You could even allow PHP to track message action & send times by sending a quick AJAX message saying hey I'm about to send you a message. If the user tampers with the actual message the times between the first message and the message containing the data would vary in many seconds. PHP could watch for this as it usually doesn't take a computer 5+ seconds to process data and send AJAX requests.
