Q&A With Jasvir Nagra, Jscrambler Technical Advisor

Cyber attacks have already been making some significant headlines in 2021. Organizations are facing increasingly complex challenges, especially when it comes to Web security.

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

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

Jasvir: What people mean by browser security itself has evolved over time. Originally, most web applications consisted of code written by a small number of teams in a company. The focus of the industry was on making web applications more resilient to accidental vulnerabilities that these developers introduced. Problems like XSS and XSRF were the major sources of such vulnerabilities. In order to defend against these attacks, it was sufficient to use robust frameworks that have threat protections like contextual autoscapers built into them. There were certainly challenges in rolling these out but largely autoescaping frameworks and defense-in-depth tools like CSP and trusted types have gone a long way towards 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, from compromised third-parties, from cryptocurrency miners, from timing attacks that leak information, and from 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?

Jasvir: 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 nascency. It seemed obvious to everyone that techniques like obfuscation were a stopgap till 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 come to 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 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 continuously changing JavaScript obfuscation to frustrate and slow down attackers.

Obfuscation has a mixed reputation in the security community, sometimes dismissed as being “merely” security through obscurity. In many cases in the past, this poor reputation has been deserved. However, companies like Jscrambler—who 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 the 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 own package (left-pad). What does this say about the ecosystem? Also, do you think these dependency-related incidents are giving ideas to attackers?

Jasvir: The security consequences highlighted by leftpad makes it tempting to think of the third-party ecosystem as “just” a security problem. And 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 on security but also on 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 certainly pay attention to whatever is the weakest security link in the chain that can get them what they need.  And third-party libraries, as evidenced by attacks like Magecart, are a fairly weak link. Nevertheless, 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 important tools in web developers’ arsenal. When we get to a point where companies have to rely less on trust, and where the consequences of a compromised library are minimal, we’ll 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?

Jasvir: I’m 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 on 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 own version of code.  We as a team 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.

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

Jasvir: 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 itself remains a challenging, evolving, and unsolved problem. Jscrambler is one of those companies making a real dent in addressing it and I’m excited to be on the journey with them.