How Secure is your Web Browser?

"JavaScript is ubiquitous. Everywhere you look, something has been created, at least in part, using JavaScript. JavaScript is so easy to learn and use, as there is a wide availability of easy-to-incorporate, open-source libraries like jQuery, React.js, and Frameworks such as Backbone.js, Angular.js, and Ember.js.

But the most important fact is that JavaScript is very dynamic and versatile.

Companies have acknowledged the power of this language and are using it to develop almost anything that is important to them. This raises concerns as more and more sensitive logic is being developed in JavaScript and more and more data and Intellectual Property is being put on the client-side. If companies focus only on protecting the server, as they have been doing until now, they will leave their front door open to attacks such as user-experience tampering, malware injection, data leakage, MiTB, Intellectual Property, and code theft.

According to Statista, over three billion people access the internet globally, giving cyber thieves a very big pond to fish in. Last year alone, it was discovered that nearly one billion Android handsets could be hacked by just one SMS. Also, so-called rogue app stores are becoming a serious concern for banks. Subtly altered versions of popular apps, often available for free, are appearing more often on smartphones. In some cases, these apps allow the theft of mobile banking passwords or redirect text messages containing passcodes.

Traditionally, code protection meant storing as much code on the server as possible. This kept your code safe from prying eyes and it also allowed the server to do the heavy lifting, performance-wise. Even today, storing your code on the server certainly offers the best protection, although with some disadvantages.

Web Security: the Challenges

One challenge involves forcing an internet connection; if you're developing an application you want to work offline then it's not feasible. Another consideration is performance. Server calls take time. Not an issue for simple apps but for high-performance apps like games, excessive latency can ruin the user experience.

A question that often crops up is, “Why can't I just encrypt my JavaScript code?” Seems like a great solution at first, but it doesn't quite work that way. You can encrypt the files but then they won't be of any use to the browser. You'll need to decrypt them to make them readable to the browser, which takes you back to square one.

Let us bear in mind that to date, organizations have relied heavily on endpoint security solutions to protect the client-side - yet solutions such as antivirus have a low success rate of around 40 percent. If we consider that an application encompasses both the server and client side and that the client side solution doesn't necessarily have to be endpoint security, then we understand that every client app has its own cloaking system and defense.

To date, companies have been focused on the threats via servers and have paid little attention to the hidden dangers of hacks through the client-side. Often, when we get in front of IT teams they are unaware of the risks they face if the client-side isn't protected sufficiently. Our technology is designed to detect tampering with the application on the client. This means that the development and security teams are made aware and can execute a plan to ensure the attack isn't successful. We make the assumption that execution takes place in an unsafe environment so we take every measure possible to allow the app to execute safely.

Due to the increasing ubiquity of HTML5 and JavaScript, more and more of an app's logic is transferred from the server-side to the client-side. This requires developers to focus much more on security. Applications need to be protected in a comprehensive manner.

An additional layer of security allows an application to become self-defensive ensuring that it is able to detect any kind of tampering and make the code derail the execution of the program. Also, if you require real-time notifications then you can use settings to warn you if your application is being tampered with or used in a different environment or date other than the one you have defined.

Conclusion

JavaScript is the de facto language of the web. As we see more and more important information, logic, and assets being incorporated on the client-side, we see an expansion of the battlefield. Attacks are happening now in the absence of effective countermeasures.

We need to recognize and understand the very real dangers posed by not protecting the client side instead of relying solely on antivirus-type solutions and other security on the server side. It's time to make a stand on security to better protect your precious web assets."

Originally published in SC Magazine UK on January 20, 2017.