Beyond Obfuscation: JavaScript Protection and In-Depth Security

"Security through obscurity is a bad idea" — says every CISO, and with good reason.

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."

Today, this principle is generally accepted and adopted by security engineers. And this could be the end of our story — but it isn't.

When we throw in the concept of "JavaScript Obfuscation", many are quick to dismiss it on the basis of "obscurity isn't security".

But obfuscation is just a small piece of a much bigger picture: source code protection. Just like 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 to source code.

This is why it's crucial to understand JavaScript Obfuscation, JavaScript protection, and in-depth security.

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.

Let's look at a sample of obfuscated JavaScript (and yes, it's 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 in fact 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 get you a long way towards 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 covered obfuscation, let’s look at the remaining pieces of JavaScript protection.

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

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

So, 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.

In 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 in 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.

Piracy is a key business threat in digital products and services, especially to 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 hurts the business severely.

Jscrambler addresses both 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.

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. Because the logic behind these forms is handled by JavaScript and all this sensitive data passes through the client-side, the safety of this data could be at risk.

By leaving their JavaScript exposed, organizations make it easier for attackers to understand how their web applications work and facilitate the planning/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 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/GDPR.

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 or book a demo with us in case you want to learn more.