Q&A With Jasvir Nagra, Jscrambler Technical Advisor

Following the exciting announcement of Jasvir Nagra joining Jscrambler's advisory board and given his extensive expertise in obfuscation, software watermarking, fingerprinting, and web security, we have taken the chance to ask Jasvir for his comments on the present and future of browser security.

Cyberattacks have already made some significant headlines over the last few years. Organizations are facing increasingly complex challenges, especially regarding web security.

Browser Security: Present and Future

Q: How do you classify the state of browser security these days?

What people mean by browser security itself has evolved.

Originally, most web applications consisted of code written by a small number of teams within a company. The focus of the industry was on making web applications more resilient to the accidental vulnerabilities that these developers introduced. Problems like XSS and XSRF were the major sources of these vulnerabilities.

To defend against these attacks, it was sufficient to use robust frameworks that have threat protections like contextual auto-scapers built into them. There were certainly challenges in rolling these out, but largely auto-escaping frameworks and defense-in-depth tools like CSP and trusted types have gone a long way toward mitigating those challenges.

Unfortunately, as the web has evolved and more valuable data has moved to the web, attacks and attackers have also evolved.

Browser security today includes threats from bots, compromised third parties, cryptocurrency miners, timing attacks that leak information, and malicious extensions. These threats require more sophisticated and continuous monitoring, as well as the ability to understand what is happening on browser applications in the wild and adapt to changing tactics by attackers.

Tools that give this kind of visibility, control, and analytics to web developers have become critical for protecting users.

Overall, browser security has come a long way as a secure platform. But while attackers keep adapting, browsers will need to adapt too.

Q: It has been 11 years since you co-authored a well-known book on Software protection, including obfuscation techniques and others. How does it feel to now be associated with a company whose flagship product includes JavaScript obfuscation techniques?

Honestly, it has been a pleasant surprise! At the point when I was originally working on obfuscation, watermarking, and fingerprinting, which led up to the book Surreptitious Software with Christian Collberg, cloud computing was still in its infancy.

It seemed obvious to everyone that techniques like obfuscation were a stopgap until the network was fast enough that sensitive computation that needed to be protected from reverse engineering could simply be moved from the client to the server.

What was unexpected was the sheer volume of data transfer that would be needed to move computation back to a server. And more so, the dramatic impact of not having an equivalent of Moore’s law for networks.

The more the improvements in computation outpaced improvements in bandwidth, the more compelling it became to take advantage of doing the computation wherever the data already resided. This desire came along with the need to maintain the integrity of both the data and the computation on remote, distributed machines.

In parallel, there are new classes of attacks in browsers, like bots, that require the ability to do remote attestation. One of the most effective ways of providing that ability has been to continuously change JavaScript obfuscation to frustrate and slow down attackers.

Obfuscation has a mixed reputation in the security community, sometimes dismissed as “merely” security through obscurity.

In many cases in the past, this poor reputation has been deserved. However, companies like Jscrambler, which is bringing well-crafted obfuscation techniques to browsers, are showing that these software protection techniques are empirically very effective in tipping the balance back in favor of defenders.

I’m excited to get to work with researchers at Jscrambler who have continued to push the obfuscation frontier in the last decade.

Q: Not too long ago, one developer broke thousands of NPM packages when he deleted his package (left pad). What does this say about the ecosystem? Also, do you think these dependency-related incidents are giving attackers ideas?

The security consequences highlighted by Leftpad make it tempting to think of the third-party ecosystem as “just” a security problem. Don’t get me wrong, the security problem posed by third-party libraries is severe.

But as you point out, web application developers’ dependency on third-party libraries has consequences not only for security but also for availability, functionality, and API evolution.

The wrong lesson to learn from the Leftpad fiasco is “don’t rely on third-party libraries”. However, by focusing on specific problems, third-party libraries often provide better, more specialized functionality than similar services built and maintained in-house.

Attackers pay attention to whatever is the weakest security link in the chain that can get them what they need. Third-party libraries, as evidenced by attacks like Magecart, are a weak link. There’s a lot of value provided by third-party libraries. Finding ways of mitigating the extent to which companies are vulnerable to them has a lot of positive benefits and deserves greater attention.

By evolving JavaScript and the browser’s security model, increasing the security of third-party libraries, and building tools that detect and mitigate attacks from first and third parties, we are introducing new tools in web developers’ arsenal.

hen we get to a point where companies have to rely less on trust, and where the consequences of a compromised library are minimal, we will have more companies being incentivized to collaborate.

Q: In your 8-year tenure at Google, where you (amongst other things) led Google Caja development, did you anticipate that browser security would evolve to be what it is today? Was anything a surprise?

I am very proud of the work we did as part of the Google Caja project.

Our predictions were a mixed bag—we certainly foresaw how much more prevalent third-party libraries would become and how severe the security implications would be. I believe a lot of the security improvements in JavaScript (in particular with strict mode) were inspired and proven by the work we did. The work on Content Security Policy and Trusted Types has also been exciting to see.

Without speaking for the rest of my team, I was personally surprised by how quickly attacks evolved away from the straightforward exploitation of the authority granted to libraries to supply chain attacks where attackers did not merely take advantage of existing vulnerabilities in third-party libraries but actively tried to introduce new vulnerabilities either by taking over existing open source libraries, attempting to contribute exploitable code to them, or compromising servers to serve their version of code.

As a team, we always understood the limitations of code review as a defense. However, the speed with which attackers evolved in this direction was a surprise and made the kind of defenses Caja was advocating to build into browsers even more urgent.

What was the motivation for joining the Jscrambler’s advisory board?

I learned early in my career that the most fulfilling work is when you get the chance to build great things that address an important hard problem with people you love working with.

I’ve known Pedro and Rui for a long time, and the team they have put together at Jscrambler is among the best working on web security.

Securing the browser platform remains a challenging, evolving, and unsolved problem.

Jscrambler is one of those companies making a real dent in addressing it, and I am excited to be on the journey with them.