May 5, 2020

Celebrating 500K App Builds Protected with Jscrambler: Lessons Learned

by Jscrambler

Celebrating 500,000 App Builds Protected with Jscrambler: Lessons Learned

Some milestones cannot go unnoticed.

This week marks 500,000 application builds protected using Jscrambler. Our long journey of making JavaScript apps more secure has started over 10 years ago, even before Jscrambler was founded.

Back then, when we were developing security solutions to battle click fraud, we had to develop a JavaScript protection solution in-house to prevent fraudsters from reverse-engineering and bypassing our technology.

As it turned out, we weren’t alone in needing to protect our JavaScript. Requests for our JS protection were pouring in, and we quickly understood that this was a huge problem in need of a robust solution — Jscrambler.

During this decade, we invested extensively in R&D. Building a team of experts in JavaScript and Application Security, we developed the most advanced and effective JavaScript protection transformations available today — including Control Flow Flattening, Code Hardening, Self-Healing, and Threat Monitoring.

So, what did we learn from half a million protected builds (from over 43,000 users)?

JS Protection is Much More Than Obfuscation

While most people aren’t familiar with the concept of JavaScript Protection, many have heard of JavaScript Obfuscation. The two are often confused for one another and this leads many to believe that obfuscation is all there is to it.

Often, we hear CISOs and those working in security say “obscurity is not security” (which is a valid statement) and many dismiss obfuscation on this basis (which is an incorrect generalization). This is why we emphasize why JavaScript Protection is much more than obfuscation. JS Protection means making attackers’ lives extremely difficult when they try to tamper with, debug, or reverse-engineer JavaScript code.

Most JavaScript obfuscation tools (namely, free obfuscators) only scrape the surface in terms of protection — failing to include resilient code protection transformations, which means that they are defeated promptly using automated tools. Plus, they offer little to no runtime protection.

On the contrary, Jscrambler isn’t an obfuscation tool that seeks to keep adding new features. It is a code protection technology that leverages tried-and-true techniques to address real key security threats.

And this leads us to another key realization:

Protected JavaScript Hinders Several Different Attacks

A great thing about protecting half a million app builds and working with over 43,000 users is getting to know in-depth several different attacks to source code.

Besides more obvious threats like intellectual property theft (as many applications have no choice but to ship proprietary logic on the client-side), we find more advanced threats like Automated Abuse, Piracy, and Data Leakage. We have written a white paper exploring the role of JavaScript Protection in mitigating piracy and we’re working on new content covering the other threats. For now, let’s get a sneak peek:

Automated Abuse

In the Web, abuse refers to exploiting the web application’s functionalities to gain access or privileges through the use of bots. Automated attacks are concerning because they can target new versions of the code with minimal cost, which means that they can scale, hit more targets, or even allow attacks to be conducted remotely.

Cloud providers that offer free benefits in new accounts are often targeted, as attackers abuse this system to automate new trial account creation and use the benefits for mining cryptocurrencies, for example.

Often, these attacks require some sort of source code manipulation, which is possible when JavaScript is unprotected. Polymorphic JavaScript Obfuscation (a combination of unique Jscrambler transformations) 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.

Try Jscrambler For Free

Data Leakage

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.

Management, Investors, Regulators Call For JS Protection

As knowledge about Application Security becomes more widespread, we see source code protection becoming a standard. OWASP, for example, directly mentions this in their Mobile Top 10 Security Risks:

owasp-logo

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

And just last week, the National Institute of Standards and Technology (NIST) also dedicated a section of their secure software development white paper to “Protect Software”, stating:

Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code that is not intended to be publicly accessible, it helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.

This increased need for JavaScript protection has reached the management and investors of companies across the world — especially in high-stakes industries like Finance and Broadcasting.

Nobody put it better than one of our clients in Banking:

“Protecting our JavaScript was a requirement from day one. Investors and management made sure that it was a priority. Today, not a single product ships without secure client-side logic and this has been extremely effective.”

JS Doesn’t Stop, Attackers Don’t Stop — We Stay Ahead

Our mission has always been straightforward: to make sure companies can get the latest technology to safeguard their business in today’s context.

Because attackers keep evolving their tactics against web applications and the JavaScript ecosystem doesn’t stop growing, we are fully dedicated to ensuring that our JavaScript Protection always stays at the forefront.

Just recently, we improved our protections by adding new features like Self-Destruct, and Self-Healing, while maximizing our compatibility with ES7/ES8, the main browsers, and JS frameworks and libraries.

We are truly proud of all these achievements and fulfilled by knowing that these 500,000 protected builds enabled our clients to push technology forward while keeping millions of users safe.

See you at 1 million!


Meanwhile, if you want to protect your own application builds with Jscrambler, start your free trial!