The perils of JavaScript: How we've broken the internet's security

This article is a synopsis of John Elliott's keynote at RSA Conference 2023, "Regulation and Risk When Your Customer’s Browser Leaks Data."

When I say that I'm worried we've broken the internet, people often think that I'm perhaps over-exaggerating or worse, a little unhinged. Let me assure you this is not the case. But I am concerned that we've broken some of the security of the internet. And if you can spare me a few minutes, I'll explain.

Over the last ten or so years we've changed how the web works. We've moved a large part of the intelligence of the internet from web servers to the web browser like the one you're using now to view this blog post.

Ten years ago, if I had a web page on my site that needed to look up a zip code, or to error check a form, I'd have the user enter the data in their browser, post the data to my web server where I'd do the lookup or validation, then send a fresh page back to the browser. That's not how we do things now.

Now, we'd do all that work client-side, in the browser using JavaScript. And so a web page is no longer a collection of text, images and style directives, but a series of JavaScript programs that are interpreted in the browser to render a functional web page application. JavaScript is what makes the internet the rich experience it is today. 

The second major change in the architecture of the web is the move to distributed microservices that are accessed directly by JavaScript in the browser. In the web's prior architecture, if I was to build a web application there would pretty much be a single conversation between a browser and my web server which is where the business intelligence would be. Where other third-party services or data were required, they would be accessed and managed by the web server. Today, JavaScript running in the browser contains the business logic and communicates directly with microservice APIs from multiple parties.

This ability to assemble JavaScript from anywhere to build a web application has changed the way we build web applications and the way we integrate with business partners who provide their own third-party JavaScript that runs in your customer's browsers.

But this architecture change comes with a problem. Any JavaScript running in a web page has access to all the elements on the page. It can access any data entered by the user, anything that's displayed on screen, any keyboard and mouse events and in certain cases the contents of other sites' cookies. Any JavaScript can also send any data anywhere, it can hijack events and change the behaviour of a page or application. This is because (excluding cross-origin iframes) there is no security barrier or segmentation within a web page that could restrict JavaScript loaded from another location from accessing everything. 

To get a sense of the size of the amount of first- and third-party JavaScript on a site press the F12 key and you will see the number of scripts. On this page, when I last looked, there were 51 scripts coming from 17 locations. When I looked at 20 large US e-commerce websites there were, on average, 100 separate scripts on a page, divided almost equally between first- and third-party scripts coming from up to 35 separate domains.

Now, when all the JavaScript plays nicely, there isn't a problem. However, not all JavaScript is nice and there are four data-leaking behaviours that can create problems for organisations.

Many bits of JavaScript are used for advertising, user profiling and tracking. They come from the big advertising networks such as Google/Alphabet and Facebook/Meta. The more data that such advertising and tracking companies have access to, the better they can track users and target adverts. It should therefore be no surprise that in some cases their JavaScript has been taking much more data than the company that included the JavaScript on its web page expected.

There's been significant research into this type of data leakage in the healthcare industry because it provided advertisers with the ability to target medically vulnerable users with adverts for non-regulated medical products.¹

Many of the tracking and advertising networks allow the amount and types of data that they collect from web sites to be configured. But frequently that step is missed out by the marketing or digital departments who added the JavaScript to a website, which results in the collection of excess data. Some recent examples include the Meta JavaScript taking detailed information from tax preparation sites² and sites providing abortion advice³.

Another common use of third-party JavaScript is to be able to record and then replay a user's journey through a site. This can be useful to optimize a site's design and UX. Researchers found that such scripts often record user credentials and the contents of unsubmitted forms⁴.

Finally we come to the malicious use of JavaScript by criminals. Historically this has mainly been used in e-commerce to steal payment card data. Attacks like this rose 174% last year⁵ and are the main way that criminals now steal credit and debit card data. You may hear such attacks described as skimming or "magecart" attacks, named after the criminal groups who first discovered and used this method of attack.

To execute the attack the malicious threat actor just needs to get their rogue JavaScript into the web page, and that can be done by inserting it into any first- or third- party script running on the page. Remember that the average page contains 100 such scripts coming from 13 different domains, so the attack surface is large. 

Some of the more public examples of this were the attacks against British Airways where a first-party script was modified by the attacker, against Ticketmaster via a third-party script that powered a customer support agent real-time chat tool, and, ironically, against many e-commerce websites that displayed the "Shopper Approved" security seal because the JavaScript that produced the security seal was compromised by the criminals⁶.

Although data stealing by JavaScript skimming is common in the payment card domain, it hasn't yet been operationalized by threat actors looking to steal other sorts of data – but I predict that will happen.

To summarize the problem, we've created a new attack surface that can be used by legitimate entities such as advertising and tracking networks and by illegitimate entitles such as hostile nation states and criminals to extract data from web applications. At some stage we're going to have to work out how to secure this.

Theoretically securing client-side JavaScript is really simple. We'd ´just´ need to:

1. Ensure that all JavaScript added to a web site was included in our software inventory and SBOM

2. Review the code to make sure it we understood its behaviours and what data it had access to 

3. Include all the third-party providers of JavaScript in our third party risk program. 

4. Put all JavaScript under change control and re-review any code changes before they were released. 

For our own first-party client-side JavaScript, we could probably manage this through our normal secure software development lifecycle. But third-party scripts are a real problem, because they are updated regularly by the third-party outside of any of our change control.

This is a hard problem, and because of the potential for data leakage it has not gone unnoticed by regulators. As a direct result of the research into health data leaking to advertising and tracking networks, the US Department of Health and Human Services has made it clear that such data leakage is a clear violation of HIPAA⁷, and hospitals have had to issue breach notifications to affected patients.

In Europe data protection regulators have made it clear that organisations are expected to manage the data leakage risk associated with all JavaScript they include in their website.

The regulator's view is typically that organisations should manage JavaScript in the same way they would manage the risk that any code could affect the security of data – by inventory/SBOM, code reviews and change control. The latest version of the Payment Card Industry (PCI) Data Security Standard (DSS) is the first information security standard to explicitly address this risk and indeed takes this approach.

Security tool vendors have realised that managing JavaScript will become a problem and there many vendors now with solutions to help organisations address this.

To get ahead of the risk and future regulatory expectations, Information Security and risk teams can take practical steps today by understanding how much JavaScript is present on their organisation's websites, and how it gets there. There are plenty of tools that will give you an inventory of scripts, and you can use Content Security Policy (CSP) in report-only mode to do this for you. What's important is that you gather this inventory by browsing the site because you'll only get an accurate inventory from the browser view – some scripts load other scripts and you just won't see this if you look from the server side.

The next stage is to work out how scripts get added to the site. That's quite easy for first-party scripts because they do typically go thought your existing change control process.  However, third-party scripts are often added to the site by digital or marketing teams using script management platforms such as tag managers which were intentionally designed to defeat change control⁸. What's important here is to work out who in your organisation owns each script – if hypothetically you wanted to remove the script from the site, who would you ask?

With the inventory and ownership in place, it's time to think about the business processes that are currently in place to add and manage JavaScript, because from here you can then think about how you can manage it in the future. 

You can then consider what technology solutions will work for your organisation. Some vendors are developing tools that automatically profile all JavaScript, which will alert you when new scripts appear on your website, and even block malicious behaviour. Whatever approach you take, it will entail changes to business processes and perhaps the use of more technology and tools.

As an industry we haven´t really addressed the risks associated with the way we now build web applications by assembling hundreds of small scripts in the customer's browser. Any one of those scripts can leak data, intentionally, accidentally or because they've been compromised by a threat actor. Organisations are going to have to manage this risk in the future, and if they don't do it voluntarily, regulators will enforce it.

_{1. Health advertising on Facebook: Privacy and policy considerations. Patterns. Vol 3, Issue 9. September 2022. Downing A, Perakslis E. https://www.sciencedirect.com/science/article/pii/S2666389922001726}

_{2. https://themarkup.org/pixel-hunt/2022/11/22/tax-filing-websites-have-been-sending-users-financial-information-to-facebook}

_{3. https://themarkup.org/pixel-hunt/2022/06/15/facebook-and-anti-abortion-clinics-are-collecting-highly-sensitive-info-on-would-be-patients}

_{4. Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission. Proceedings of the 31st USENIX Security Symposium (USENIX). August 2022. Senol A, Acar G, Humbert M & Borgesius FZ  https://homes.esat.kuleuven.be/~asenol/leaky-forms/}

_{5. Visa Biannual Threats Report. December 2022. https://cdn.visa.com/dam/visa/vgb/visanotification/PFD-Biannual_Report_December_2022_Public-ACCESSIBLE.pdf}

_{6. https://www.securityweek.com/magecart-attack-hits-shopper-approved/}

_{7. https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html}

_{8. https://business.adobe.com/blog/basics/tag-manager : "A tag manager shortens web development cycles. It frees up developer time so they can do other important work instead, and allows marketers to gather, organize, and manage website data better.”}