WebViews are a core component of today's in-app browsing technologies on mobile platforms, playing a central role in rendering web content like mobile advertisements. However, their use and potential to bridge web and mobile tracking paradigms comes at a significant privacy cost for users. Although prior work has highlighted privacy risks associated with WebViews, the real-world scale and privacy impact of their misuse and abuse remain unexplored due to the hybrid nature of WebViews-combining Java, native, and dynamically-loaded JavaScript (JS) code. In this paper, we present the first large-scale empirical study of WebView abuse in Android apps. We analyze how app developers and third-party SDKs facilitate user tracking by configuring WebViews to bypass default platform privacy protections and enable invasive tracking through JavaScript code. Using a novel analysis pipeline that combines static and dynamic analysis of Java/Kotlin code and JavaScript, we reveal how numerous actors undermine users' privacy and exploit WebViews in the wild. We show that harmful JavaScript code, often distributed via unvetted Real-Time Bidding (RTB) processes, exploits WebViews to perform advanced tracking techniques such as cookie sync-ing, canvas fingerprinting, and misuse of the Java-JS interface and permission-protected JavaScript APIs to silently leak unique user identifiers and geolocation data without user awareness for cross-platform tracking.

Given the widespread prevalence of vulnerabilities, remediation is a critical phase that every software project has to go through. When comparing the studies on understanding the security vulnerabilities in software, such as vulnerability discovery and patterns, there is a lack of studies on the vulnerability remediation phase. To address this, we have done a timeline analysis for 130 of the most dependent upon open source projects written in JavaScript language, hosted on GitHub to understand the nature and the lifetime of the vulnerabilities in those projects. We used a static code analyzer on 501K commits from the repositories to identify commits that introduced new vulnerabilities to the code and fixed existing vulnerabilities in the code. In 90% of the projects, we identified that a commit that fixed an existing vulnerability had introduced one or more new vulnerabilities into the code. On average, 16% of the commits intended to fix vulnerabilities have introduced one or more new vulnerabilities from the analyzed projects. We also found that 18% of the total vulnerabilities found in those projects have originated from a commit meant to fix an existing vulnerability, and 78% of those vulnerabilities could have been avoided of introduction if the developers were to use proper internal testing. Here, we demonstrate Sequza, a visualization tool to help organizations detect such instances at the earliest possible.

While there is a large body of work on understanding vulnerabilities in the wild, little has been done to understand the dynamics of the remediation phase of the development cycle. To this end, we have done a timeline analysis on 118K commits from 53 of the most used JavaScript projects from GitHub to understand the provenance and prevalence of vulnerabilities in those projects. We used a vulnerability detector (CodeQL) to filter commits that introduced vulnerabilities and the commits that fixed a prior vulnerability. We found that in 82% of the projects, a commit fixing a prior vulnerability, in turn, introduced one or more new vulnerabilities. Among those projects, on average, 18% of the commits intended to fix vulnerabilities, in turn, introduced one or more new vulnerabilities. We also found that 50% of the total vulnerabilities found in those projects originated from a commit meant to fix a prior vulnerability, and 78% of those vulnerabilities could have been avoided if they were to use proper internal testing. We provide critical insights into how proper internal testing can avoid a significant portion of vulnerabilities, increasing organizations' security posture.