Third-party JavaScript attacks: Why virtual sandboxing doesn't work in the real world

March 6th, 2019

Symantec recently reported last week that that 4,800 websites are 'form-jacked' every month. This is clearly a massive problem that the industry has to reckon with.

Third-party javascript services integrated on websites seem to be the biggest culprits. The question is, how do you solve this problem?

'Sandboxing' is a fantastic security concept that has manifested itself in various avatars - Linux jails, VMs, malware sandboxing, iFrame sandboxing in HTML5 etc. Unfortunately, security companies have a tendency to latch on to the latest technology trend and try to use it to solve each and every problem. Essentially, you think you have a hammer and everything starts to look like a nail.

Some vendors are trying to utilize a sandboxing approach to third-party JS protection - something called 'virtual sandboxing.' In a nutshell, you take the third-party JS and 'confine' it in a sandbox that it is not supposed to break out. Sounds great in theory, but works awfully poorly in practice.

There are lots of reasons why this approach is impractical. I'm only highlighting the major ones that we consistently hear from enterprises who have tried out such solutions:

  1. Performance. Sandboxing leads to very significant latencies that can slow down the page by several 100s of ms, sometimes seconds. In most mission-critical sites, such a delay is unacceptable. Security isn't meant to shut down the site, but protect it.
  2. Tags. If your site includes a number of tags (which is increasingly the norm), sandboxing becomes a massive operational and performance challenge. Who is going to sit and determine the sandboxing policies for each of these tags? Performance comes to a grinding halt as you hit a dozen or more tags per page.
  3. Functionality. Many third-party JS cannot and should not be sandboxed. Sandboxing will in fact, break normal functionality.

Our belief at Tala is that complicated solutions make the life of customers worse, not better. Tala considered several approaches to solving this critical customer problem (including sandboxing) and realized that security should never become a drag on performance, especially on mission-critical, revenue-generating websites and web apps.

The technology choices we made early on help Tala to protect web assets whilst adding almost no latency to page loads. Tala works very well with large number of tags, and does not break normal functionality.

Security and performance do not have to be mutually exclusive.