Beyond Obfuscation: JavaScript Protection and In-Depth Security

When we throw in the concept of JavaScript Obfuscation, many dismiss it on the basis that "obscurity isn't security". And "security through obscurity is a bad idea", says every CISO, and with good reason.

But obfuscation is just a small piece of a much bigger picture: source code protection. The ISO 27001 information security standard states:

Program source code can be vulnerable to attack if not adequately protected and can provide an attacker with a good means to compromise systems in an often covert manner. If the source code is central to the business success it’s loss can also destroy the business value quickly too.

This last sentence says it all. The more value your applications bring to your business, the more it has to lose from attacks on source code. This is why it's crucial to understand JavaScript Obfuscation, JavaScript protection, and in-depth security.

Having a security system rely on secrecy is by no means a good practice. In the NIST Guide to General Server Security, it's clear:

"System security should not depend on the secrecy of the implementation or its components."

Nowadays, security engineers generally accept and adopt this principle. And this could be the end of our story, but it isn't.

JavaScript Obfuscation

JavaScript obfuscation is a series of code transformations that turn exposed JS code into a modified version that is extremely hard to understand and reverse-engineer.

Look at a sample of obfuscated JavaScript (and yes, it is valid JavaScript):

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+

[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+

([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+

[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+

[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+

(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+

!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+

[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+

[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+

[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+

[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+

(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+

[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+

[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+

[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+

!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+

(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+

[])[+!+[]]])[!+[]+!+[]+[+[]]])()

To the human eye, this seems impossible to reverse-engineer. But while this code has been obfuscated with high potency, the obfuscation is very weak.

Using an automated reverse-engineering tool, we would get the original code immediately. This means that this obfuscation has low resilience.

Knowing these two concepts will go a long way toward being able to compare different obfuscation tools. As you do this analysis, you'll see how free obfuscators offer basic transformations with very little resilience, meaning that they would be easily reversed. There are also known cases of these free tools inserting malware during obfuscation.

On the contrary, the obfuscation layer that Jscrambler provides includes a meticulous combination of the most potent and resilient transformations to make it extremely hard for humans and machines alike to reverse the code. Like one of our clients in Healthcare stated:

Jscrambler was the only product we found that could not be cracked.

Now that we've covered obfuscation, let’s look at the remaining pieces of JavaScript protection.

JavaScript Protection

Just like you put in place strict measures for server-side and network security, specific client-side security practices are crucial to preventing serious attacks.

To understand why, let's see what OWASP says about this in their Mobile Top 10 Security Risks guide:

While obfuscation should provide a good way of preventing reverse-engineering, more advanced threats like code tampering require protection at runtime.

Jscrambler provides advanced runtime protection with techniques such as Self-Defending, which breaks the protected app when an attacker tries to debug it or when there’s any change to the source code.

By providing these techniques on top of our cutting-edge obfuscation, we have helped thousands of businesses tackle different attack scenarios. Let’s look at some of the most prevalent ones.

Attack Scenario 1: Automated Abuse

On the Web, abuse refers to exploiting the web application’s functionalities to gain access or privileges through the use of bots, for example, to automate new account creation with a cloud provider and get unlimited free benefits to mine cryptocurrencies.

Often, these attacks require some sort of source code manipulation, which is possible when JavaScript is unprotected.

Jscrambler’s unique polymorphic JavaScript obfuscation directly tackles this by making each new code build completely different. When coupled with frequent deployments, this means that the attack window is short and neither automated nor manual reverse-engineering is possible.

Attack Scenario 2: Piracy and Cheating

Piracy is a key business threat to digital products and services, especially in the fast-growing OTT industry.

The forensic watermarking solutions that providers employ to track down the source of leaks are typically deployed with a client-side JavaScript agent. Because the source code of this agent is exposed, attackers can tamper with its logic to bypass it and make it much harder for providers to block their accounts.

Using a similar tactic, attackers can abuse games by tampering with the code to illegitimately gain advantages. This negatively affects legitimate users and severely hurts the business.

Jscrambler addresses both of these threats. When an attacker tries to debug or tamper with a client-side watermarking agent protected by Jscrambler, the code is highly obfuscated, and Self-Defending will break the app and keep the attacker locked out.

The same happens when attackers are trying to tamper with a game’s logic to bypass its restrictions.

Attack Scenario 3: Data Exfiltration

On the Web, users commonly submit data like their email, name, address, credit card number, or even medical information on a website using a form.

The safety of this data might be at risk. These risks are based on the JavaScript logic behind these forms: all this sensitive data passes through the client-side.

By leaving their JavaScript exposed, organizations make it easier for attackers to understand how their web applications work and facilitate the planning or automation of data exfiltration or scraping attacks.

On the contrary, by protecting their source code with Jscrambler, companies make it much harder for attackers to go through the source code.

This protection helps frustrate attackers and raise the cost of the attack to a point where they’re likely to move on to another target.

Plus, by protecting their JavaScript source code, these companies increase their compliance with standards such as ISO 27001 and data protection regulations like CCPA and GDPR.

Attack Scenario 4: In-Depth Security

The different attack scenarios we just covered are the reason why we emphasize that JavaScript Protection is much more than obfuscation. This protection should be seen as a valuable component of an application security strategy.

Because attackers keep evolving their tactics against web applications and the JavaScript ecosystem doesn’t stop growing, we keep improving our JavaScript protection solution, even after 10 years of R&D and over 500,000 protected builds.

And as we bring JavaScript protection to major enterprises, this is what we’re hearing back from our clients:

So the "security isn't obscurity" argument has naturally evolved to today's context with the new constructive argument of "what we need is in-depth security".

Feel free to try all Jscrambler features with a free trial to learn more.