Software development has, to a large extent, become synonymous with using readymade blocks of code in the form of third-party components, like libraries and frameworks, to build applications. All code may include weaknesses that may be exploited by criminals and script kiddies, potentially causing harm to both corporations and people. Third-party components, too, may include weaknesses, but in the case of such a vulnerability being exploited, the effects could be even more critical since popular components may be used in thousands of applications. There are several types of vulnerabilities and one of them is called prototype pollution. This is a JavaScript specific vulnerability that has been found in many well-used third-party components in the last years. However, it has not been the subject of much research. This thesis investigates the risks of using third-party components when developing software with a focus on web applications by conducting a literature survey. It also includes a case study of the prototype pollution vulnerabilities found in recent years and what mitigation techniques have been proposed by both academia and the industry.

Prototype pollution is a vulnerability in JavaScript and other prototype-based languages that allows malicious actors to inject a property into an object’s prototype. The injected property can subsequently trigger gadgets - source code sections that use the properties in sensitive locations. Gadgets can lead to various exploits, including denial-of-service, data exfiltration, and arbitrary code execution (ACE). Current research focuses primarily on the detection of pollution, while only a few discuss gadget detection. Those that do either propose detection solutions for browser-side applications or selected frameworks. This thesis aims to answer how prototype pollution affects modern server-side applications built on the Node.js framework. We propose a system that can automatically detect potential prototype pollution gadgets in Node.js applications. We utilize dynamic taint tracking to find flows from polluted prototypes to exploitable functions. Our system consists of multiple distinct runs. A first run analyzes a program without changing the control-flow to avoid premature termination through exceptions and program crashes. In subsequent runs, the system selectively changes conditionals to increase coverage. Based on our methodology, we implement Dasty, a performant dynamic taint analysis for prototype pollution gadgets built on NodeProf and the Truffle Instrumentation Framework. Dasty can automatically analyze third-party packages by utilizing their test suites. We use our implementation to analyze the 5000 most depended upon npm packages and verify the resulting flows systematically, focusing on ACE and similar high-profile vulnerabilities. Through the analysis, we identify 16 new gadgets in packages used by thousands of applications. Our results suggest that prototype pollution can lead to serious security issues in many modern applications. / Prototype pollution är en sårbarhet i JavaScript och andra prototypbaserade språk som tillåter skadliga aktörer att injicera en egenskap i ett objekts prototype. Den prototype som blivit komprometterad kan därefter utlösa gadgets - delar av kod som använder egenskaperna på känsliga positioner. Gadgets kan leda till olika exploiteringar, inklusive denial-of-service, dataexfiltrering och arbitrary code execution (ACE). Aktuell forskning fokuserar främst på detektion av prototype pollution, medan endast ett fåtal diskuterar detektion av gadgets. De som gör det föreslår antingen detekteringslösningar för applikationer på webbläsarnivå eller enskilda ramverk. Detta examensarbete syftar till att svara på hur prototype pollution påverkar moderna applikationer på serversidan byggda med ramverket Node.js. Vi föreslår ett system som automatiskt kan upptäcka potentiella prototype pollution gadgets i Node.js-applikationer. Vi använder dynamic taint tracking för att hitta flöden från injicerade prototyper till exploateringsbara funktioner. Vårt system består av flera distinkta körningar. En första körning analyserar ett program utan att ändra kontrollflödet för att undvika för tidig terminering p.g.a. exceptions och programkrascher. I efterföljande körningar ändrar systemet selektivt villkoren för att öka täckningen. Baserat på vår metodik implementerar vi Dasty, en snabb dynamic taint analysis för prototype pollution gadgets byggda på NodeProf och Truffle Instrumentation Framework. Dasty kan automatiskt analysera tredjepartspaket genom att använda deras testramverk. Vi använder vår implementering för att analysera de 5000 mest npm-beroende paketen och verifiera de resulterande flödena systematiskt, med fokus på ACE och liknande högprofilerade sårbarheter. Genom analysen identifierar vi 16 nya gadgets i paket som används av tusentals applikationer. Våra resultat tyder på att prototype pollution kan leda till allvarliga säkerhetsproblem i många moderna applikationer.

JavaScript-built programs are widely used by the general public, but they are also vulnerable to JavaScript-related exploits stemming from the newly discovered prototype pollution vulnerability. Research has been focused on understanding the impact of this vulnerability and finding ways to detect it using code analysis tools. However, current tools have difficulty achieving both high accuracy and completeness, and many do not provide out-of-thebox support for detecting prototype pollution. This creates the possibility of tools with no out-of-the-box support for the vulnerability potentially being better suited for different environments and scenarios than the currently employed state-of-the-art. This thesis aggregates the existing knowledge about prototype pollution detection and examines the detection capability of Joern, a code analysis tool that does not have out-of-the-box support for prototype pollution detection, by comparing it to the state-of-the-art tool CodeQL. The comparison is made by analyzing their ability to detect prototype pollution in vulnerable Node.js packages. Both tools use queries to analyze code. An implemented Joern query is compared to prototype pollution queries included in CodeQL, as well as a CodeQL query taken from the literature. The results show that Joern is capable of identifying prototype pollution vulnerabilities but also wrongly reports more places as vulnerable than it correctly identifies. The same issue was found with the CodeQL query taken from the literature, which also found more vulnerabilities than the implemented Joern query. However, the implemented Joern query could identify a larger number of vulnerabilities in the dataset than the included CodeQL queries. Joern’s reasons for the misclassification of code as (non)vulnerable were identified as JavaScript constructs/features not being correctly modeled, bugs in the tool, and difficulty in differentiating data structures from each other. In conclusion, Joern can be used to detect prototype pollution vulnerabilities but requires further development and research to improve its detection capability. / JavaScript-byggda program används dagligen av allmänheten, men dessa program är sårbara för olika JavaScript-relaterade angrepp möjliggjord av den nyligen upptäckta sårbarheten prototypförorening. Tidigare forskning har fokuserat på att förstå dess konsekvenser i kombination med sätt att detektera sårbarheten med hjälp av verktyg för kodanalys. Nuvarande verktyg har svårt att detektera alla sårbarheter med en hög noggrannhet, och många ger inte stöd för att detektera prototypförorening som standard. Detta skapar möjligheten för verktyg utan inbyggt stöd för sårbarheten att potentiellt vara bättre lämpade i olika miljöer och scenarier än nuvarande state-of-the-art. Denna rapport sammanfattar den befintliga kunskapen om detektion av prototypförorening och undersöker detekteringsförmågan hos Joern, ett verktyg för kodanalys som inte har inbyggt stöd för att detektera prototypförorening, genom att jämföra den med state-of-the-art-verktyget CodeQL. Jämförelsen görs genom att analysera verktygens förmåga att detektera prototypförorening i sårbara Node.js-paket. Båda verktygen använder queries för att analysera kod. En implementerad Joern-query jämförs med queries som ingår i CodeQL, samt med en CodeQL-query som hämtas från litteraturen. Resultaten visar att Joern kan identifiera prototypförorening men rapporterar även felaktigt fler platser som sårbara än den korrekt identifierar. CodeQL-queryn som hämtades från litteraturen hade samma problem, dock kunde den hitta fler sårbarheter än den implementerade Joern-queryn. Den implementerade Joern-queryn hittade istället ett större antal sårbarheter i datasetet än de queries som var inkluderade i CodeQL. Joerns anledningar för felklassificering av kodrader som (icke)sårbara identifierades som att vissa JavaScript-konstruktioner modelleras felaktigt, buggar i verktyget och svårigheter att skilja mellan datastrukturer. Sammanfattningsvis kan Joern användas för att detektera prototypförorening men kräver ytterligare utveckling och forskning för att förbättra dess detekteringsförmåga.