Blog

Javascript versus Javascript​: The war within a browser



Context

The weakest link in a modern web application is external javascript – something that has been exploited in recent attacks such as (Magecart, British Airways, Newegg…). Recent studies such as [1] have determined that when a user visits a website roughly 2/3rd of the code running in the browser comes from 3rd parties (analytics, tag management, audio/video integration, form builders, social media etc.). How do you defend the user of a webapp from threats resulting from the compromise of these 3rd party components as they are fetched in real time within a browser? A couple of approaches that have been touted, rely on injecting heavyweight Javascript as a layer of defense into a webpage when the page is served from the website. The purpose of this layer of javascript is to hook onto key javascript APIs in a browser (as the user is visiting the page), instrument access and flow of data, and/or to provide a layer of application sandboxing (aka virtual iframe) within a browser. These approaches, what one would call “javascript versus javascript” (like a war within a browser between the attacker’s javascript and the layer of defense’s javascript), are flawed for a variety of reasons that are highlighted below.

Performance

To start with, that time your developers and application owners have spent on optimizing page load times is futile, the moment you inject this heavyweight javascript as a layer of defense. There is an increase in page latency, load time and time to execute the code within the browser (as this javascript defense layer often duplicates functions within a browser such as parsing JS/HTML and maintaining state machines). Secondly, hooking onto network calls to monitor outbound post requests, websocket connections, calls to local filesystem or reads/writes to/from the parent DOM is very expensive to do in a browser. On an average page, there are at least 75+ such events that’ll now be monitored with javascript hooking, significantly slowing down the end user experience on the webpage. CDNs and load balancers cannot rescue you from such performance issues because the slowdown is not over the network but due to the additional code running within a browser.

Security

Wait! Isn’t giving up on performance worth it to get strong security? The golden rule in the security world is that the layer of defense should run at a higher privilege level than the layer of attack AND retain enough visibility to understand the context of the layer at which the attack happens. Running at the same privilege as the attacker’s code is an absolute NO NO! Hardware level defenses are superior to software level defenses. Kernel level defenses are stronger than user space defenses. OS level defenses are superior to defenses inside an application. The concept of TCB (Trusted Computing Base) and a defense mechanism ideally as part of TCB, has been explored way back in the classic paper [2]. In the current discussion, the browser, the javascript interpreter and the OS are the TCB. The defense mechanism protecting a component outside the TCB, should ideally reside in the TCB. Therefore, browser or javascript interpreter level defenses [3], which are part of the TCB, are much more difficult to circumvent than a pure Javascript layer of defense (running as is or presenting itself as a virtual sandbox) layered on top of a browser. Any approach that explicitly or implicitly assumes that my Javascript layer of defense is smarter than the attacker’s Javascript is flawed. Having application virtualization implemented at JS level to confine code between custom HTML tags(virtual iframes) is an insecure implementation of the virtual sandbox concept.

Deployment Challenges

Last but not the least, javascript injection approaches are too intrusive with a high potential for breaking existing apps. The defense layer of javascript could interfere with legitimate javascript running on that page. How much effort does one want to spend on testing each and every page and pulling in your developers to troubleshoot? The developers will definitely not be happy while debugging real issues and trying to figure out whether the fault is with their code or with this other piece of code. In deploying virtual sandboxing how does one know, without involving the developers, which data flows are legitimate and which are not? Try determining this for a site that has 30k+ pages. One customer, trying a product based on virtual sandboxing, is still struggling even after spending almost a year.

Conclusion:

In conclusion, securing your web application against javascript attacks with a javascript has a negative impact on security, performance and intrusiveness. These attacks are best addressed by leveraging W3C compliant native controls available within 90% of PC & mobile browsers OR emerging Javascript interpreters. (Javascript insertion does have some uses such as stage 3 of fraud detection but more on that later..)

[1] D. Kumar, Z Ma, et. al., Security Challenges in an Increasingly Tangled Web http://mdbailey.ece.illinois.edu/publications/www17_tangled.pdf

[2] B. Lampson, M. Abadi, M. Burrows and E. Wobber, Authentication in Distributed Systems: Theory and Practice, ACM Transactions on Computer Systems 1992, on page 6.

[3] D Stefan, et. al., Protecting Users by Confining JavaScript with COWL, http://www.scs.stanford.edu/~deian/pubs/stefan:2014:protecting.pdf

blog

Shift in Web Architecture and its Impact on Security

by admin

Fifteen years ago, when a user visited a website, all the logic and processing happened on the server, and the […]

read more

whitepaper

Tala is powered by advanced AI and threat intelligence.

Get the most comprehensive view into how your users are being attacked. Understand the where, how and when of attacks, in real-time. Tala’s AI driven analytics helps you focus on attacks that matter the most.

download now

Request A Demo

Learn how Tala’s technology works and can help you protect your users against malicious attacks.

Bitnami