4

I'm sure most of you are familiar with the JavaScript-based game Candy Box.

As you probably know, one can cheat this game's candy system by sending commands to the console.

For instance, if you click the link, you will see that your candy count increases slowly. Somebody using Google Chrome (I refer to Chrome specifically because I know the keyboard shortcuts; perhaps this can be done in Firefox or IE) who wants to cheat can press Ctrl + Shift + I, navigate to Console and send candies.setNbrOwned(2147483647) to the console for a quick and easy sugar-high.

Can this pose a problem in other contexts? For instance, let's say that I have a website that sells widgets. Can somebody's balance (or even the price of my widgets) be altered through sending something like userBalance = 2147483647 or widget.setPrice(0.01) by using JavaScript (maybe even without using the browser's JavaScript Console)?

If it isn't possible, why is that the case? My first guess for why it might not be possible is because changed variables would be stored as local variables and wouldn't affect anything major -- kind of like changing elements through 'Inspect Element' features.

If it is in fact possible, through what means can it be done, and how does one prevent it?

4

There are two main types of issues that can occur with client-side execution:

  1. A malicious client can modify their client state and attempt to make the server accept that modified state as valid
  2. An unsuspecting user can be tricked into running code in their console by a malicious third-party, something caused Self XSS

Malicious clients running JavaScript

When an unprivileged, untrusted client interacts with a server, the server must, whenever possible, validate all the input received by the client and the legality of client actions. Failing to do so opens the server up for a wide range of attacks known as 'Insecure Interaction Between Components'. Just like all your Web forms' input must be validated, you must validate any data you receive from client-side via AJAX queries or other mechanisms.

Once you've validated all the data, there are still a number of cases where users can abuse client-side scripting, such as online games. The defences you can set against players giving themselves more resources than allowed, making more moves than allowed, displacing themselves further than allowed in a multiplayer game, etc., are relatively limited. Some defence strategies could include:

  • analysing in-game footage captured by a privileged anti-cheat app to verify if rendering libraries were modified or scripts injected -- classic defence for competitive desktop gaming but you don't usually have this capability for a Web client
  • hashing the functions being executed and sending the hashes to servers for comparison -- this would only thwart basic cheats that forget to also modify the hashing code
  • calculating the bounds of / rate-limiting benefits a user can realistically obtain within a time period (e.g. no more than X per minute) -- this is probably the most efficient defence since it's agnostic to the client platform

Self cross-site scripting

Online social networks like Facebook are particularly wary of people downloading "hacks" that claim to give users more likes or access to their friends' profiles. Many malicious scripts can be found that, if copied into a browser, will let a third-party take over your user session. This is a dream scenario as attackers can execute arbitrary code in your valid user session! Facebook now injects a warning message in browsers' developer consoles to help fight this phenomena:

Facebook's STOP warning, which reads 'Stop! This is a browser feature intended for developers. If someone told you to copy and paste something here to enable a Facebook feature or "hack" someone's account, it is a scam and will give them access to your Facebook account.'

4

Yes it can be an issue but there are ways for applications to protect against it.

Two sides to every internet application.

In order to understand internet application security you have to understand the difference between the client and the server. Data which is generated by the client (the browser), must be sanitized and validated before being by the server.

If you had a website that sells widgets, you would never store a users account balance on their machine, in their browser. This would be like a brick and mortar bank asking you to take home the balance sheet, and bring it back when you are ready to make a withdrawal. Therefore the server side of the application must keep track of the balance, and only allows the client application to request actions be taken on their behalf.

How could I prevent people from cheating in my game

If the game is implemented on the client side, you can't. Any logic that is done on the client side can be altered. There are some ways to make it more difficult though. Minimizing and obfuscating the javascript will increase the time it takes to understand the code, but it won't really protect anything.

Ideally your client side logic would only represent the view and then send action requests to the server. The client view could always be altered but because all the real logic takes place on the server, the integrity of the game remains in tact.

0

Javascript, and all other client side technologies, are inherently insecure. You can't keep people from cheating, only make it more difficult.

  • More accurately, client side technologies are out of your control. Any inputs coming from the client need to be untrusted by the server. That's why you validate and sanitize everything from a source that you do not control. – schroeder May 21 '15 at 19:30
  • Language design is rarely at fault. Compilers and bad client design can be. But in modern JS's case, that consists of several major browser JITs executed constantly by billions of people every minute of every day executing UI and server communication code running a full range on spectrums of quality and chaos. I'm only speculating but I imagine newly introduced v8 versions rarely have relatively basic exploits go undiscovered for as long as more traditional pre-compiled systems can through sheer orders of magnitude of accidental QA they get the benefit of. – Erik Reppen May 21 '15 at 23:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.