1

Desire: I want to make an ever expanding single player online rpg world. Even though it is single player, I would like to make it possible for people to trade items they find in an online market and rank players. To reduce requests to the server I wanted the local machine to hold all the information in javascript objects until the player presses SAVE. When SAVE is pressed an AJAX request is sent to the server and I'll handle that with PHP, MySQL ect.

Perceived Problem: If I do this my concern is that someone will access the variables by typing javascript:object.hit_points=10000000000000;. If one person cheats and floods the online market with items they cheated to get, then that will cheapen the experience for everyone else.

Questions: Is it possible for a player to manipulate live javascript object variables through the address bar or some other means? If so, is there some way that I can secure the game and still use javascript for managing the interface and data?

Thank you for your time in sharing your learning and understanding. Best Regards, Bryan

Bryan
  • 123
  • 7

1 Answers1

2

Is it possible for a player to manipulate live javascript object variables through the address bar or some other means?

Yes:

  • If the variables happen to be globally accessible, the user only has to open the console and assign to them. Eg, they could type in window.money = 999999999;. This could be solved by putting the whole script into an IIFE without using global variables. But...
  • Even without global variables, no code that runs client-side is "secure". See Is it possible to gain access to the closure of a function?. The user could simply intercept the JavaScript that your site runs, and replace it with their own JavaScript that implements their desired functionality (giving them free items, money, etc). This can be mitigated to a moderate extent by minifying and obfuscating the JS, but it's not a full solution. You'd want to make sure the network request payloads cannot be easily deciphered either.

Ultimately, the only good solution to this is to generate and save all state on the server, which gets communicated to the client when needed. The client cannot be allowed to generate any data or state themselves - the client should only be able to ask the server what their state is.

If the user is at a section where an item may be generated (eg, a treasure chest is opened), the only way to do this securely is for the server to verify that the player is at the position of a treasure chest, and for the server to generate the item in the chest, then inform the client of their new item. This way, no matter what JavaScript code runs on the client, if the client tries to make an invalid trade, or patches things so they have more HP than they're allowed to have, the server can verify it and reject the invalid request. For example:

Client: Attack

Server: You attack and deal X damage. You are counterattacked and lose Y HP. You die.

Client: Open chest

Server: (Verifies that you are at an openable chest, then replies:) You receive a Water of Life

Client: Offer trade of item ID 333 for some other user's item 555

Server: (Verifies that client currently holds item 333, and that the other client holds item 555, then:) Trade successful (switches around items in server's DB)

CertainPerformance
  • 356,069
  • 52
  • 309
  • 320
  • thank you. I will look deeper into minifying and obfuscation software. I am unsure how to accept this answer because it is excellent. I will accept it once I can figure out how to. – Bryan Sep 26 '20 at 16:58
  • 1
    It's difficult. It's not hard to solve in a theoretical sense, but it requires a *lot* of code logic and coordination between the client and server. You can compromise by generating some state on the client, but the more state the client is allowed to create itself, the more "hackable" such a game would be, even with minification and obfuscation. But in exchange, the code would be much easier to manage if you only have to keep track of things on the front-end. – CertainPerformance Sep 26 '20 at 17:00