Tuesday, 22 January, 2019 UTC
Summary
Welcome back to Jscrambler 101! A collection of tutorials on how to use Jscrambler to protect your JavaScript. This tutorial covers Jscrambler version 5.5.
Introduction
Last time, on Jscrambler 101 — Source Maps, we detailed how you can leverage Jscrambler's Source Maps to achieve painless debugging of protected apps.
This time, we’re going to talk about one of Jscrambler's most valuable capabilities: Client-Side Countermeasures. We will show you how to set up these countermeasures and highlight some common use cases where they help you ensure that your applications remain protected.
Countermeasures
As you've read in our previous 101 tutorials, two of Jscrambler's protection layers are Code Locks and Self-Defending.
By locking your code to specific browsers, domains, OS'es and date ranges, you can both prevent someone from breaking the lock and also trigger an action when a lock-breaking attempt is made.
The same goes for the self-defending module. This feature prevents someone from trying to debug the code or tamper with it and also enables you to trigger specific actions when these debugging/tampering attempts occur.
These actions, which we call countermeasures, come in four different flavors: Break Application, Custom Callback Function, Delete Cookies, and Redirect. Let's go over each of them.
Break Application
Breaking the application is Jscrambler's default client-side countermeasure.
The way it works is straightforward: every time that someone tries to break a lock in your code or whenever the self-defending module is triggered, the application will completely stop working.
This behavior is always enabled on the self-defending module.
Custom Callback Function
This countermeasure gives you full control over the desired triggered action.
To get it to work, you need to have a specific function inside your original source code with the desired behavior. Then, you supply the name of that function when setting up the custom callback, and it will be triggered as a countermeasure.
Delete Cookies
The delete cookies functionality immediately deletes all end-user cookies which don't have a
path property set nor have been created with the HttpOnly flag.We will cover a specific use case for this countermeasure further below.
Redirect
As the name implies, with this option you are able to automatically redirect the user to a specified URL, such as a warning page.
This countermeasure is currently supported for browsers versions that were released after Internet Explorer 9 but can be adapted to earlier versions as described on our docs.
Setting Up Countermeasures
As we mentioned before, client-side countermeasures are triggered when one of two possible scenarios occur: either when someone breaks a code lock or when the self-defending module is activated (during a tampering or debugging attempt).
You can set up countermeasures easily via the Jscrambler Web App. When you're on the screen with the application you want to protect, in the Fine-Tuning tab, ensure that you have selected either the self-defending feature or a code lock. In either case, you'll see a "Countermeasures" section, where you can specify which countermeasures you wish to apply.
You can also set up countermeasures directly through the Jscrambler CLI and the Jscrambler packages for webpack and gulp. In this case, you specify countermeasures directly in the Jscrambler configuration file, as shown below:
{
"keys": {
"accessKey": "myAccessKey",
"secretKey": "mySecretKey"
},
"applicationId": "myApplicationID",
"params": [
{
"name": "browserLock",
"options": {
"browsers": [
"firefox"
],
"countermeasures": {
"customCallback": "callbackFunction",
"deleteCookies": true,
"redirect": "https://www.example.com",
"breakApplication": true
}
}
}
],
"areSubscribersOrdered": false,
"applicationTypes": {
"webBrowserApp": true,
"desktopApp": false,
"serverApp": false,
"hybridMobileApp": false,
"javascriptNativeApp": false,
"html5GameApp": false
},
"languageSpecifications": {
"es5": true,
"es6": false,
"es7": false
}
}
Now that we have covered what countermeasures are and how to set them up, let's go through some examples of use cases where using Jscrambler's countermeasures can be vital to ensure the security and integrity of your applications.
Redirect to Warning Page
Currently, sophisticated phishing attacks try to redirect the users of a legitimate website to a malicious copycat page that asks for user credentials.
One such example would be a cryptocurrency exchange under the domain
www.exchange.com. If this web app isn't protected with Jscrambler and some users have compromised devices (for example with a malicious browser extension), the user may be redirected to an external website which is copying the original one (under a similar domain such as www.echange.com and the same user interface).The external website can display a warning asking the user to create a new password or to set up 2FA again. Users may be unaware of the malicious intent and insert the requested data, which is sent to attackers.
If the exchange was protected with Jscrambler's code locks, the code could be locked to run only on the crypto exchange's domain. The web app developers would also be able to set up an automatic redirect when there's an attempt to run the code outside of the specified domain. So, infected end-users would not reach the malicious website and instead see a warning message such as the one shown below.
Custom Callback to a SIEM
Picking up on the example above, a redirect to a warning page would be one of many viable countermeasures to be applied.
Another possible reaction mechanism would be to set up a custom callback to a SIEM, with the goal of sending an immediate alert to security teams whenever someone tried to run the code outside of the specified environment.
This would be a valid approach for any of the other locks (domain, OS, browser, and date range) and the self-defending feature as well.
Delete Cookies to Prevent Scraping
Several web apps require authentication in order to access user-specific pages. Imagine social media platform or even a SaaS web app with a trial plan. In both cases, the user has to log in before accessing the platform's content.
Automated scraping attacks may seek to obtain this (often private) information to feed it to an external platform or exploit the web app itself.
When the attack starts, Jscrambler's anti-tampering features come into play, detecting the tampering attempt and enabling a countermeasure. In this case, an effective one would be to delete cookies — this would immediately end the user session and deny access to private pages.
Custom Callback to Prevent App Features Abuse
For this last use case, let's consider an application with a free and premium mode, such as an HTML5 game.
While the "premium" state is often managed on the server-side, there are several cases where this must be done on the client-side, such as with offline apps.
In these cases, an attacker would be able to easily access the app's core logic, which resides in the JavaScript code. Then, it's a matter of time until the attacker is able to identify how the premium state is managed and force it to "premium" instead of "free". This effectively grants the attacker a tampered version of the app with all the premium features, bypassing the need to pay in order to unlock them.
In this case, app developers could set up a custom callback when a tampering or debugging attempt is detected by Jscrambler.
A practical example of this scenario is the tampering of the "Space Shooters" game, which we detailed in our Jscrambler 101 — Self-Defending article.
Conclusion
And we're done! Now you can unleash the full power of using Client-Side Countermeasures to protect your applications.
Remember to contact our support team through our email if you have any questions. If you wish to read our other 101 Tutorials, you can find them here.
Enjoy your testing and start protecting your Applications ASAP!