Product: Code Integrity

Welcome back to Jscrambler 101, a collection of tutorials on how to use Jscrambler to protect your JavaScript. This tutorial is about SIEM integration and covers Jscrambler version 7.2.

Introduction

Last time, in Jscrambler 101: Memory Protection, we explored a new Jscrambler feature that ciphers sensitive data using cryptographic algorithms, allowing the application to decipher it only when it needs to access it.

This time, we’re going to explore SIEM Integration, a new Jscrambler feature that lets you forward and aggregate the valuable security Information Jscrambler provides into a SIEM (e.g., Elasticsearch, Splunk).

SIEM Integration

From Jscrambler version 6.0 onwards, we provide a JavaScript Threat Monitoring module that displays a real-time notification on the Jscrambler dashboard as soon as a violation occurs, such as the client’s JavaScript code being tampered with or used in a different environment or date from the one(s) that are set on the protection configuration.

With SIEM Integration, you can access all that valuable information from one place and automate audit log review and alerting.

Setting up your SIEM Integration

To set up the integration between Jscrambler and your SIEM, you need to configure a Jscrambler notification driver and map the fields of the notification body. Let’s explore these steps below.

To access the SIEM Integrations page, go to the Jscrambler dashboard, select the target application, and then click the “Integration” link under the Setup section.

Currently, we provide two driver types that your SIEM will most likely support: Elasticsearch and Webhook. Below, we will explore how to set things up in each of these.

Elasticsearch

To set up real-time notifications with an Elasticsearch instance, select the Elasticsearch Notification driver from the dropdown box and click the “Add” button.

Then, you will need to configure the following parameters according to your Elasticsearch setup:

• Title: Name of this integration
• URI: Network endpoint of your Elasticsearch instance (must be publicly available)
• Accept All Certificates: turn on to allow self-signed certificates
• Username/Password: client authorization to the Elasticsearch instance
• Request Timeout (milliseconds): maximum amount of time waiting for the request to be completed
• Max. Number of Retries: number of times the service attempts to deliver the Real-Time Notification once the first attempt fails
• Elasticsearch Index: name of the Elasticsearch index where your notifications will be grouped
• Elasticsearch Type: name of the Elasticsearch type

When you are done, click on the Create button to validate and store the configured Elasticsearch integration.

Webhook

To set up real-time notifications with a Webhook, select the Webhook Notification driver from the dropdown box and click on the “Add” button.

Then, you need to configure the following parameters according to your SIEM (which should be capable of receiving HTTPS requests):

• Title: Name of this integration
• Endpoint to send a POST Request: Network endpoint of your HTTP (S) server instance (must be publicly available)
• Basic Authentication Username/Password: client authorization to the HTTP (S) server
• Support Self-Signed Certificates: turn on to allow self-signed certificates
• Max. Number of Retries: number of times the service attempts to deliver the Real-Time Notification once the first attempt fails

When you are done, click on the Create button to validate and store the configured webhook integration.

And that’s all from the Jscrambler dashboard! Let’s now see how to map the notification body to the respective security alerts.

Mapping the notification body

Each real-time notification sent by Jscrambler will follow the pattern below:

{
  "title": "Real time notification",
  "description": "Code violation: j-003-00001",
  "body": {
	"0": "j-003-00001",
	"1": 1625757006491,
	"2": -60,
	"3": "Linux x86_64",
	"4": "Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0",
	"5": "https://example.com/index.html",
	"8": "Gecko"
  },
  “clientIp”: “111.111.111.111”
}

To properly visualize this data in your SIEM, you should map these fields to their corresponding descriptions.

Here’s the meaning of each field in the request’s body:

As for the alert codes of body[“0”], find the corresponding alert description below:

And that’s it! You’re done with the required configuration.

End Result

Now that you have set up your SIEM integration, you should see real-time notifications in your SIEM. In the image below, you can see a preview of the resulting dashboard using Kibana.

Now that you have centralized your security information in one system, it is easier to start automating your audit logs and alert checkups.

Conclusion

We have reached the end of our Jscrambler SIEM Integration tutorial.

As you saw, getting started with this feature is a simple, one-time process that will enrich your SIEM with valuable information. Don’t miss this chance to start centralizing your security information and making it easier to maintain in-depth security. Enjoy your testing. Start protecting your Applications ASAP! If you have any additional questions, feel free to contact us.

Welcome back to Jscrambler 101! A collection of tutorials on how to use Jscrambler to protect your JavaScript. This tutorial covers Jscrambler version 7.1.

Introduction

Last time, on Jscrambler 101 — App Classification, we explored a new Jscrambler feature that classifies your apps and adjusts Jscrambler’s protections to maximize their security and performance.

This time, we’re going to explore Memory Protection, a new Jscrambler feature that increases the security of sensitive data in your apps.

Memory Protection

In Web and Mobile applications, sensitive data often passes through the client-side. More specifically, values stored in memory can be accessed and tampered with at runtime.

Attackers’ motivations to exploit the app’s memory may vary from lower-risk to critical-risk. Generally, they will do it for one of these reasons:

• to reverse-engineer the code and understand its mechanics;
• to modify the app’s behavior and, for example, access new features;
• to access and retrieve sensitive data, for example, in Contact Tracing apps.

In comes Memory Protection, is a new Jscrambler feature that ciphers sensitive data using cryptographic algorithms, only allowing the data to be deciphered when it needs to be accessed by the application.

Memory Protection can be applied to strings and numbers that are present in complex structures like objects and arrays.

Memory Attack Example

Let’s look at an attack example using our Jscrambler Racer HTML5 app.

In this simple HTML5 game, you do some laps with a racing car, attempting to keep your lap time as low as possible. We even have a Fastest Lap scoreboard at the top.

Without question, a next-gen AAA racing game.

So let’s assume we are an attacker wanting to cheat by changing our current lap time. This is a perfect example of a value that’s typically stored in memory.

So, using one of many widely available tools for tampering with the memory, we can start looking for the Time value by trial and error at runtime.

So, when the time is at 15 seconds, we can look for values between 10 and 20. This retrieves 1718 results. Then, we keep refining our search as the time increases and, when we finally get 1 result, we can directly modify its value. Et voilà, we are now the best Jscrambler Racer player of all time.

Memory Protection Example

Now, let’s look at how this attack would unfold if this app’s JavaScript and HTML5 code were protected using Jscrambler with the Memory Protection feature.

First off, we need to upload our app to the Jscrambler Web app and open the file that contains its source code.

We can apply Memory Protection using Code Annotations. In our example, we want to protect the function that handles the Time value:

// @jscrambler enable memoryProtection
function () {
    // other variables
    var currentLapTime = 0;
    var lastLapTime    = null;
    var keyLeft        = false;
    var keyRight       = false;
    var keyFaster      = false;
    var keySlower      = false;
    var hud = {
      speed:            { value: null, dom: Dom.get('speed_value')            },
      current_lap_time: { value: null, dom: Dom.get('current_lap_time_value') },
      last_lap_time:    { value: null, dom: Dom.get('last_lap_time_value')    },
      fast_lap_time:    { value: null, dom: Dom.get('fast_lap_time_value')    }
    }
    // other nested functions below
    function update(dt) {
      var n, car, carW, sprite, spriteW;
      // other variables in nested functions
    }
}

Using the settings we defined above, Memory Protection will be applied both to the primary function and all nested functions.

Because we know that these nested functions don’t pose a security risk, we should disable Memory Protection on them to ensure maximum performance of the protected app.

We do this by adding the // @jscrambler disable memoryProtection code annotation before each nested function:

// @jscrambler enable memoryProtection
function () {
    // variables
    }
    // other nested functions below
    // @jscrambler disable memoryProtection
    function update(dt) {
      // variables in nested functions
    }
}

Now that we have added Memory Protection to all high-risk objects, we can protect the app and run the newly protected version. Let’s try to replicate the attack on the protected app.

As we can see, Memory Protection prevents the attacker from gaining access to the value in memory, eventually getting 0 results.

Use Cases

Looking back at the 3 main scenarios for memory attacks that we presented earlier, our demo above is a good example of “modifying the app’s behavior and, for example, accessing new features”. So, changing values stored in memory can allow attackers to cheat.

However, another very significant scenario is with applications that handle critically sensitive data, such as government, healthcare, and financial apps. In those, an attack on the memory can have devastating results, with the exfiltration of extremely sensitive user data when certain conditions are met.

Conclusion

And so we reach the end of our Jscrambler Memory Protection tutorial.

As you’ll see in our upcoming tutorials, this is one of the new Jscrambler features aimed at protecting sensitive data within web and mobile applications. Now more than ever, companies have the duty of keeping their users’ data secure. Enjoy your testing and start protecting your Applications ASAP! If you have any additional questions, feel free to contact us.

Welcome back to Jscrambler 101! A collection of tutorials on how to use Jscrambler to protect your JavaScript. This tutorial covers Jscrambler version 6.3.

Introduction

Last time, on Jscrambler 101 — Self-Healing, we explored a new anti-tampering approach that ensures that the app doesn’t break when tampering is detected while regenerating the original code.

This time, we’re going to delve into a new Jscrambler feature: Profiling. We will explain why Profiling is a valuable feature for performance-critical apps, how you can use it in your own apps, and its main use cases.

Profiling

When protecting JavaScript, it’s desirable to achieve the optimal balance between three key metrics: potency, resilience, and cost. The first two correlate to the overall strength of the code protection, while the last refers to eventual impacts on performance and code size.

Often, applying a strong set of protections to the whole source code doesn’t affect the performance of the app. However, some applications tend to perform less than ideal when this is done. In those cases, we can reduce Cost manually using Code Annotations — specifying different protection templates to parts of the code that we know to be crucial to performance.

Jscrambler Profiling is a new way of achieving this goal effortlessly by understanding which parts of the code are performance-critical and applying the best transformations when you protect your code.

When To Use Profiling

Now that we understand the basics of Jscrambler Profiling, it begs the question: when should we use Profiling?

As a general rule, before using Profiling, you should protect your application normally and check if the protected app has any performance issues. If it doesn’t, then there is no reason to use Jscrambler Profiling.

Setting Up Profiling

From Jscrambler version 6.3 onwards, Profiling can be set up both via the Web App and via the CLI. We’ll cover both strategies step-by-step. If you intend to use the CLI, please don’t skip the instructions on the Web App Setup, as they cover essential Profiling concepts.

We will be using the “Jscrambler HTML5 Racer” app as an example.

Initial Setup Using The Web App

Once you’re on your app’s Code Protection Builder page on the Jscrambler Web App, switch from the “Protect App” context to “Create Profiling” by using the dropdown on the right sidebar as shown below:

Now, we need to instrument our app. This step adapts the application to include tools that will measure the performance of the original application and report data back to Jscrambler. It’s as simple as clicking “Instrument Application” and then downloading the newly instrumented app.

This instrumented app is not protected — do not send it to production! Instead, we will be using it to run the app in a testing environment so that it sends performance data to the Jscrambler profiler. To do so, let’s click “Start Profiling”.

From this point onwards, Jscrambler Profiling is actively receiving data whenever the profiled app is run. Our objective here is to run the app in a way that “exercises” as many functions of our code as possible, and/or the application “flows” that you believe to be less performant than usual.

So, let’s unzip the previously downloaded instrumented app and run it in our browser.

Don’t worry if the profiled app doesn’t run smoothly — this slowdown is due to the overhead of measuring the properties of the application, and will not be present in the final protected version.

As we do this, we can check the Jscrambler Profiling progress in the Web App. There, we will see a number of reports coming in as shown below — this is the collected performance data that will be essential to let Jscrambler figure out which parts of the code are performance-critical.

You can also run your automated unit tests with the instrumented code so that all program flows are tested.

Once we consider that we have tested most of the application, we can click “Stop Current Profiling”. Note that Profiling will also finish automatically if no data is received for 30 minutes.

Now that we have finished Profiling our app, the next step is to check the results. This step is the same for the Web App and CLI approaches.

Initial Setup Using The CLI

Note: The instructions for the CLI can also be seen in a small video.

Let’s consider that we have a simple project with our example app within the following directory:

simpleRacerDemo/
|-- profiling-ready/
|-- protected/
|-- unprotected/
| |-- *.js
| |-- *.html
|-- jscrambler.json

Our first step is to generate the jscrambler.json file through the Web App as shown below and place it on our root folder.

Now, let’s generate the instrumented version of our app (placing it on the profiling-ready/ folder) with the following command:

jscrambler -c jscrambler.json --instrument --output-dir profiling-ready/ unprotected/**/**

We’re now ready to exercise the logic of our instrumented app. Let’s initiate the Profiling process with:

jscrambler -c jscrambler.json --start-profiling

The next step is to start running tests that cover as many possible use cases of our app as possible (luckily, in our case, this means taking our Jscrambler race car for a spin!).

Once we’re happy with our tests, let’s stop the Profiling process with:

jscrambler -c jscrambler.json --stop-profiling

And there we have it! Our app is now Profiled and our next step is analyzing the Profiling results and fine-tuning them if needed.

Profiling Results

When we stop the Profiling process, Jscrambler will process all the collected data and we will see a summary of the Profiling results on the Web App.

On this updated screen, we see 4 main results:

• Profiled Functions: Functions that were executed during Profiling;
• Remaining Functions: Functions that were not executed during Profiling;
• Recommended Settings: Functions that will be protected with the recommended settings by Profiling; for example, recommending the “Light Obfuscation” default template when a function is profiled as being performance-critical;
• General Settings: Functions that will be protected with the general settings selected by you in the Protection Builder.

We can also click “See Report” to check each profiled function of your app and their Profiling recommendations.

On this page, we can change the template that Profiling suggested in each instance — perhaps we know that a certain function is security-critical but Profiling suggested a “Light Obfuscation” template; we can change this template to “General Settings” to ensure that this specific function will be protected with the overall protection settings.

Note that you should upload Source Maps in cases where you are using transpilers or module bundlers, for example. Simply use the “Source Maps” toggle for this.

We will also see some references to “Annotations”. This has to do with the different Profiling modes that can be used to apply Profiling recommendations when it’s time to protect the app. Let’s explore that next.

Protecting a Profiled App

Since Jscrambler version 6.3 onwards, there are 3 different Profiling modes: Annotations, Automatic, and Off.

Deciding which to choose depends on your objectives. The Annotations mode requires a one-time additional step where you have to annotate your code – meaning that Profiling results will persist after source code changes. The Automatic mode automatically applies Profiling results at protection time, but new Profiling is needed after source code changes.

So, as a rule of thumb, you will find the Automatic mode more useful when you’re first trying out Profiling or just wanting to see its results quickly. The Annotations mode is more beneficial when you want to easily integrate Profiling into your CI/CD pipeline.

The Off mode, as the name implies, doesn’t use the Profiling results at all when protecting the code.

Choosing a Profiling mode and protecting the app varies depending on whether you’re using the Web App or the CLI. Let’s explore both below.

Protecting Profiled App Via the Web App

Let’s change our Web App context from “Create Profiling” to “Protect App” using the dropdown on the top right. Now, we can choose a Profiling mode on the bottom dropdown, as shown below.

If we’re using the Automatic mode, then our next step is simply to click “Protect App”. Jscrambler will automatically apply the Profiling results and we’ll get our protected code.

But if you want to use the Annotations mode, you’ll have to get back to the Profiling Results page. Once there, you can either download a .csv file with all Annotations or copy them one by one, as shown below.

In both instances, you’ll have clear instructions about the position (line/column) of the annotation. Let’s look at an example:

"// @jscrambler profiling default lightObfuscation","highCostFunction",1:10,"index.js"

This means that we have to find function highCostFunction on line 1, column 10, and add the Profiling annotation so that the final result looks like this:

// @jscrambler profiling default lightObfuscation
function highCostFunction() {
 // performance-intensive logic
}

If you plan on using minifiers, consider adding these annotations as strings to avoid having them removed.

After placing the required annotations, we go back to the “Protect App” context, change the Profiling mode to Annotations, and click the “Protect App” button. Jscrambler will use our Profiling annotations and protect the code accordingly.

If, after this, we make some minor changes to our source code, we probably won’t have to profile the app again — Profiling is necessary after major changes.

Now, all that’s left for us to do is check the performance of our protected app.

Protecting Profiled App Via the CLI

Now that we understand the different Profiling modes, we are one command away from protecting our code.

So, if we want to use the Automatic mode, we use the command:

jscrambler -c jscrambler.json --profiling-data-mode automatic

This will create a new folder inside the protected/ folder with our newly protected app. Following our example, we can serve it locally with:

http-server protected/unprotected/

Final App Test

We can now test our final app, which was protected using Profiling recommendations. Let’s take our Jscrambler race car out of the garage for another spin:

Not only does our HTML5 app run with great performance, but all of its code is also protected with an excellent potency-resilience-cost balance. Based on our tests for this HTML5 app, the average performance of the protected profiled app (measured in FPS) was 35% better than the un-profiled protected app.

And remember, our code is still protected with the best JavaScript protection available today:

With Jscrambler Profiling doing all the heavy lifting to obtain most of the gain, we could now still use Code Annotations if we wished to tweak performance even further.

Conclusion

This sums up Jscrambler Profiling — a feature that enables effortlessly improving the performance of protected code in complex apps.

Enjoy your testing and start protecting your Applications ASAP! If you have any additional questions, feel free to contact us.