Scripting languages like Python or JavaScript are extremely popular among developers, in part due to their massive open-source ecosystems that enable smooth code reuse. However, recent work shows that a lot of scripting code runs C/C++ code under the hood, via native extensions. This might introduce subtle security issues that can surprise the users. Prior work in this domain relies on simple, intra-procedural, flow-insensitive data flow analysis to detect such problems, but it is unclear if a more holistic polyglot static analysis could be feasible, and if so, what are its costs and benefits.In this work, we propose CHARON, the first inter-procedural, polyglot static analysis for detecting vulnerabilities in scripting languages. Our approach advocates for linking together the code property graphs of the different languages and performing cross-language data flow analysis by switching between code representations, when cross-language function calls are encountered. In this way, CHARON supports data flows that cross several times the language boundary, spanning multiple functions on either side. We evaluated CHARON on 11.8K polyglot packages from npm and PyPI, containing 896M lines of code. CHARON identified 5,813 manually-confirmed, vulnerable data flows in 116 packages. We performed a baseline comparison of CHARON with single-language analysis on native code, showing a ~6x increase in true positives and ~4%, less false positive alerts. We demonstrated exploitability of the discovered vulnerabilities by creating 63 PoCs across 34 packages, showing, among others, how we can escalate a buffer overflow vulnerability in native extensions to arbitrary code execution, which we believe to be the first of its kind. Overall, our results show that inter-procedural, polyglot analysis is both feasible and effective for detection of native extension vulnerabilities.

English is the predominant language on the web, powering nearly half of the world's top ten million websites. Support for multilingual content is nevertheless growing, with many websites increasingly combining English with regional or native languages in both visible content and hidden metadata. This multilingualism introduces significant barriers for users with visual impairments, as assistive technologies like screen readers frequently lack robust support for non-Latin scripts and misrender or mispronounce non-English text, compounding accessibility challenges across diverse linguistic contexts. Yet, large-scale studies of this issue have been limited by the lack of comprehensive datasets on multilingual web content. To address this gap, we introduce LangCrUX, the first large-scale dataset of 120,000 popular websites across 12 languages that primarily use non-Latin scripts. Leveraging this dataset, we conduct a systematic analysis of multilingual web accessibility and uncover widespread neglect of accessibility hints. We find that these hints often fail to reflect the language diversity of visible content, reducing the effectiveness of screen readers and limiting web accessibility. We finally propose Kizuki, a language-aware automated accessibility testing extension to account for the limited utility of language-inconsistent accessibility hints.

While internet usage is slowly catching up globally, it is still unclear how the web experience differs in developing and developed countries. On the one hand, the web has a notoriously large inertia, with many webpages still relying on unencrypted HTTP, deprecated web features, or old and buggy libraries. On the other hand, developing countries are expected to leapfrog and directly adopt the newest technologies by learning from the prior mistakes of more developed countries. Anecdotal evidence suggests that webpages in developing and developed regions differ significantly. In this work, we test this hypothesis by measuring differences in web development practices across the two groups of countries, using multiple dimensions: webpages' size, complexity, security, privacy, quality, technology adoption, and accessibility. Concretely, we collect the largest dataset to date that compares web development practices across developed and developing regions -- 200,000 webpages across 20 countries -- which we aim to open source along with this publication. Our findings reveal that webpages in developing regions are generally smaller and simpler, utilizing fewer requests - an adaptation that improves the performance over slower network conditions common in these areas. However, these sites are less optimized in other critical aspects: they frequently employ inefficient image formats, include unnecessary JavaScript or CSS code, or lack responsive image designs. Notably, our security assessment shows developing regions lagging in HTTPS adoption and vulnerability mitigation, possibly due to lower awareness of best practices.

When creating automated tests for web applications, one major part is filling and submitting web forms. Filling out forms automatically is challenging, as form fields would typically be subject to specific constraints that prevent entry of invalid data. Modern test generators, such as the recently proposed Black Ostrich scanner, are already capable of identifying expected patterns for form values and solve them, using instance generators for regular expressions and/or string constraint solvers. String solvers, however, are limited to, well, strings.

In recent years, scripting languages such as JavaScript and Python have gained a lot of traction due to their flexibility, which allows developers to write concise code in a short amount of time. However, this flexibility is achieved via weak, dynamic typing, which fails to catch subtle bugs that would be prevented by a compiler, in static typing. Gradual-type systems like TypeScript emerged as a solution that combines the best of both worlds, allowing developers to annotate parts of their code with optional type hints. Nonetheless, most practical deployments of such systems are unsound, limiting themselves to static checks and not performing residual runtime checks that help enforce type hints uniformly. This is a missed automation opportunity that offloads the burden on developers, who still need to perform explicit type checks at transition points between untyped and typed code so that values at runtime obey the type hints. Failure to do so can result in subtle type inconsistency bugs, and when user input is involved, it can render input validation mechanisms ineffective, resulting in type confusion problems. In this work, we study the relation between gradual typing and type confusion. Our main hypothesis is that the type hints in the code can mislead developers into thinking they are enforced consistently by the compiler, resulting in a lack of explicit runtime checks that ensure type safety. We perform a large empirical study with 30,000 open-source repositories to statically analyze if and how they use gradual typing and to what extent this influences the presence of explicit type checks. We find that many projects feature gradually typed code, but usually only in small portions of their code base. This implies the presence of many points in the code base where developers must add explicit type checks, i.e., at the transition points between unannotated and annotated code. Our results further indicate that gradual typing may have a deteriorating effect when parameters are annotated with primitive types. Finally, we manually analyze a small portion of the studied repositories and show that attackers can remotely cause type confusion and violate the type hints added by developers. We hope that our results help raise awareness about the limits of current gradual-type systems and their unwanted effect on input validation.

In recent years, we have seen an increased interest in studying the software supply chain of user-facing applications to uncover problematic third-party dependencies. Prior work shows that web applications often rely on outdated or vulnerable third-party code. Moreover, real-world supply chain attacks show that dependencies can also be used to deliver malicious code, e.g., for carrying cryptomining operations. Nonetheless, existing measurement studies in this domain neglect an important software engineering practice: developers often merge together third-party code into a single file called bundle, which they then deliver from their own servers, making it appear as first-party code. Bundlers like Webpack or Rollup are popular open-source projects with tens of thousand of GitHub stars, suggesting that this technology is widely-used by developers. Ignoring bundling may result in underestimating the complexity of modern software supply chains.

NPM is the largest software ecosystem in the world, offering millions of free, reusable packages. In recent years, various security threats to packages published on npm have been reported, including vulnerabilities that affect millions of users. To continuously improve techniques for detecting vulnerabilities and mitigating attacks that exploit them, a reusable benchmark of vulnerabilities would be highly desirable. Ideally, such a benchmark should be realistic, come with executable exploits, and include fixes of vulnerabilities. Unfortunately, there currently is no such benchmark, forcing researchers to repeatedly develop their own evaluation datasets and making it difficult to compare techniques with each other. This paper presents SecBench.js,, the first comprehensive benchmark suite of vulnerabilities and executable exploits for npm. The benchmark comprises 600 vulnerabilities, which cover the five most common vulnerability classes for server-side JavaScript. Each vulnerability comes with a payload that exploits the vulnerability and an oracle that validates successful exploitation. SecBench.js, enables various applications, of which we explore three in this paper: (i) cross-checking SecBench.js, against public security advisories reveals 168 vulnerable versions in 19 packages that are mislabeled in the advisories; (ii) applying simple code transformations to the exploits in our suite helps identify flawed fixes of vulnerabilities; (iii) dynamically analyzing calls to common sink APIs, e.g., exec(), yields a ground truth of code locations for evaluating vulnerability detectors. Beyond providing a reusable benchmark to the community, our work identified 20 zero-day vulnerabilities, most of which are already acknowledged by practitioners.

Third-party libraries ease the development of large-scale software systems. However, libraries often execute with significantly more privilege than needed to complete their task. Such additional privilege is sometimes exploited at runtime via inputs passed to a library, even when the library itself is not actively malicious. We present Mir, a system addressing dynamic compromise by introducing a fine-grained read-write-execute (RWX) permission model at the boundaries of libraries: every field of every free variable name in the context of an imported library is governed by a permission set. To help specify the permissions given to existing code, Mir's automated inference generates default permissions by analyzing how libraries are used by their clients. Applied to over 1,000 JavaScript libraries for Node.js, Mir shows practical security (61/63 attacks mitigated), performance (2.1s for static analysis and +1.93% for dynamic enforcement), and compatibility (99.09%) characteristics---and enables a novel quantification of privilege reduction.

Modern JavaScript applications extensively depend on third-party libraries. Especially for the Node.js platform, vulnerabilities can have severe consequences to the security of applications, resulting in, e.g., cross-site scripting and command injection attacks. Existing static analysis tools that have been developed to automatically detect such issues are either too coarse-grained, looking only at package dependency structure while ignoring dataflow, or rely on manually written taint specifications for the most popular libraries to ensure analysis scalability.

JavaScript has been used for various attacks on client-side web applications. To hinder both manual and automated analysis from detecting malicious scripts, code minification and code obfuscation may hide the behavior of a script. Unfortunately, little is currently known about how real-world websites use such code transformations. This paper presents an empirical study of obfuscation and minification in 967,149 scripts (424,023 unique) from the top 100,000 websites. The core of our study is a highly accurate (95%-100%) neural network-based classifier that we train to identify whether obfuscation or minification have been applied and if yes, using what tools. We find that code transformations are very widespread, affecting 38% of all scripts. Most of the transformed code has been minified, whereas advanced obfuscation techniques, such as encoding parts of the code or fetching all strings from a global array, affect less than 1% of all scripts (2,842 unique scripts in total). Studying which code gets obfuscated, we find that obfuscation is particularly common in certain website categories, e.g., adult content. Further analysis of the obfuscated code shows that most of it is similar to the output produced by a single obfuscation tool and that some obfuscated scripts trigger suspicious behavior, such as likely fingerprinting and timing attacks. Finally, we show that obfuscation comes at a cost, because it slows down execution and risks to produce code that changes the intended behavior. Overall, our study shows that the security community must consider minified and obfuscated JavaScript code, and it provides insights into what kinds of transformations to focus on. Our learned classifiers provide an automated and accurate way to identify obfuscated code, and we release a set of real-world obfuscated scripts for future research.

Automatically generating unit tests is a powerful approach to exercise complex software. Unfortunately, current techniques often fail to provide relevant input values, such as strings that bypass domain-specific sanity checks. As a result, state-of-the-art techniques are effective for generic classes, such as collections, but less successful for domain-specific software. This paper presents TestMiner, the first technique for mining a corpus of existing tests for input values to be used by test generators for effectively testing software not in the corpus. The main idea is to extract literals from thousands of tests and to adapt information retrieval techniques to find values suitable for a particular domain. Evaluating the approach with 40 Java classes from 18 different projects shows that TestMiner improves test coverage by 21% over an existing test generator. The approach can be integrated into various test generators in a straightforward way, increasing their effectiveness on previously difficult-to-test classes.

Programmer-provided identifier names convey information about the semantics of a program. This information can complement traditional program analyses in various software engineering tasks, such as bug finding, code completion, and documentation. Even though identifier names appear to be a rich source of information, little is known about their properties and their potential usefulness. This paper presents an empirical study of the lexical similarity between arguments and parameters of methods, which is one prominent situation where names can provide otherwise missing information. The study involves 60 real-world Java programs. We find that, for most arguments, the similarity is either very high or very low, and that short and generic names often cause low similarities. Furthermore, we show that inferring a set of low-similarity parameter names from one set of programs allows for pruning such names in another set of programs. Finally, the study shows that many arguments are more similar to the corresponding parameter than any alternative argument available in the call site's scope. As applications of our findings, we present an anomaly detection technique that identifies 144 renaming opportunities and incorrect arguments in 14 programs, and a code recommendation system that suggests correct arguments with a precision of 83%.