PostHole
Compose
Login
SE Radio 642: Simon Wijckmans on Third-Party Browser Script Security
Simon Wijckmans, founder of c/side -- a company that focuses on monitoring, securing, and optimizing third-party JavaScript -- joins SE Radio host Kanchan Shringi for a conversation about the security risks posed by third-party browser scripts. Through real-world examples and insights drawn from his work in web security, Simon highlights the dangers, including malicious attacks such as the recent Polyfill.io incident. He emphasizes the need for vigilant monitoring, as these third-party scripts remain essential for website functionalities like analytics, chatbots, and ads, despite their potential vulnerabilities. Simon explores the use of self-hosting solutions and content security policies (CSPs) to minimize risks, but he stresses that these measures alone are insufficient to fully safeguard websites. As the discussion continues, they delve into the importance of layering security approaches. Simon advocates for combining techniques like CSPs, real-time monitoring, and AI-driven analysis, which his company c/side employs to detect and block malicious scripts. He also touches on the complexities of securing single-page applications (SPAs), which allow scripts to persist across pages without full reloads, increasing the attack surface for third-party vulnerabilities. Brought to you by IEEE Computer Society and IEEE Software magazine.
Simon Wijckmans, founder of c/side — a company that focuses on monitoring, securing, and optimizing third-party JavaScript — joins SE Radio host Kanchan Shringi for a conversation about the security risks posed by third-party browser scripts. Through real-world examples and insights drawn from his work in web security, Simon highlights the dangers, including malicious attacks such as the recent Polyfill.io incident. He emphasizes the need for vigilant monitoring, as these third-party scripts remain essential for website functionalities like analytics, chatbots, and ads, despite their potential vulnerabilities. Simon explores the use of self-hosting solutions and content security policies (CSPs) to minimize risks, but he stresses that these measures alone are insufficient to fully safeguard websites.
As the discussion continues, they delve into the importance of layering security approaches. Simon advocates for combining techniques like CSPs, real-time monitoring, and AI-driven analysis, which his company c/side employs to detect and block malicious scripts. He also touches on the complexities of securing single-page applications (SPAs), which allow scripts to persist across pages without full reloads, increasing the attack surface for third-party vulnerabilities. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
Other References
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Kanchan Shringi 00:00:35 Hello everyone, welcome to this episode of Software Engineering Radio. Our guest today is Simon Wijckman. Simon is the founder of C/side. C/side is focused on monitoring, securing, and optimizing third-party JavaScripts. Welcome to the show Simon. Great to have you here. Before we get started, is there anything else you’d like to add to your bio?
Simon Wijckmans 00:00:57 Well, thank you so much for having me. Well, something I like to add is that we start with third-party scripts today, but what we want to do is basically protect the entire like browser as an attack surface. So today that starts with third-party scripts as that’s where a lot of dynamic behaviors come from. But over time we anticipate to solve client-side security as a whole.
Kanchan Shringi 00:01:18 Let’s start though with just third-party scripts and how do they actually fit into the browser security supply chain? What is the browser security supply chain to start?
Simon Wijckmans 00:01:31 When you go to a website, a lot of things happen, right? But I’m going to jump a few steps and go straight to the part where you actually get a response from the web server. An HTML page is loaded. JavaScript, CSS, et cetera comes along. Depending on your framework, there may be server side or client site rendering. But then often in that file or in that page there is a reference to other third-party sources, third-party domains. Those third-party domains didn’t obviously get fetched. So the browser for user is told go to this other domain and get something from there. And that something is defined by that path that full URL, but you don’t necessarily know what you’re actually getting from there. So you can add a hash to that script deck to define specifically the hash of the file you’re expecting, but it’s really up to that web server to serve a piece of content back.
Simon Wijckmans 00:02:19 And so that’s how these third-party scripts are being delivered to the browser of users. And that is essentially also where a problem begins of a third-party script. So day one you think you allow a certain thing, but it has all the capabilities for changing over time. Certain things are dynamic and even though we refer to them assuming that they wouldn’t change, in some cases they can. And so in that case it was basically a wakeup call where if you refer to something that is dynamic that can change, the entire context can change. And so that is also what has happened with these third-party script attacks. When people refer to a third-party script that is supposed to be a chat bot and the week after it is actually listening to you entering passwords, then that is something that is perfectly technically capable of doing and that is a problem.
Kanchan Shringi 00:03:08 Why do developers use third-party scripts to begin with? And sounds like they’re pretty common in web dev. Like can you explain some reasons around that?
Simon Wijckmans 00:03:18 So when the world moved away from using fully server-side things like PHP or, and we’re still actively in the process on that or some things, and Flash player and Java and browsers became less common client-side JavaScript. So client-side fetch JavaScript became a much more common way of dealing with these things. And so JavaScript became supported by browsers and people then used big JavaScript libraries to perform certain dynamic actions in browsers. And at the beginning this was very efficient because when you went to 10 different websites and they were all using that same library because they used a third-party domain, your browser would not have to re-fetch it every time if there was browser site caching enabled for that package. So it was a very efficient way for loading a JavaScript file that would allow you to have a certain behavior in their website.
Simon Wijckmans 00:04:08 Over time this has progressed and people have luckily started moving away from using client-side fetch scripts for this use only. With tools like Note Package Manager and other registries for open-source packages becoming more common. But still these third-party scripts are necessary for certain things like analytics tools, chat bots, ads often there’s all sorts of these third-party that we have to use if you want to use a certain tool. And there isn’t really an alternative for many of these. So any type of like chatbots tool for instance is often a fully dynamically fetched client-side script.
Kanchan Shringi 00:04:44 So there are cases you absolutely must use third-party, but you said things have gotten better with the note Packet Manager as an example. Can you explain that a little bit more?
[...]