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

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.

Now that we 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 prevent serious attacks.

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

M8 Code Tampering	M9 Reverse Engineering
“The mobile app must be able to detect at runtime that code has been added or changed (…) The app must be able to react appropriately at runtime to a code integrity violation.”	“In order to prevent effective reverse engineering, you must use an obfuscation tool.”

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

Over the years, we have helped thousands of businesses tackle different attack scenarios with JavaScript protection. Let’s look at some of the most prevalent ones.

Automated Abuse

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.

Piracy and Cheating

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.

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. 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, source code 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.

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.

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.