Information Security
- web-application web-browser javascript vulnerability
- Updated Mon, 18 Jul 2022 00:29:21 GMT
-
Can a browser JavaScript console ever be an issue?
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?
Solution
There are two main types of issues that can occur with client-side execution:
- A malicious client can modify their client state and attempt to make the server accept that modified state as valid
- 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:
External Links
External links referenced by this document: