Code obfuscation is especially prominent in server-side scripting languages. For instance, almost all webshells - backdoors installed by attackers to gain persistent access to a hacked system - and similar PHP-based malware are heavily obfuscated to hide their logic and true nature. Deobfuscation is the ability to reverse code obfuscation, i.e., to revert an obfuscated program into a form as close as possible to the original, unknown input, without changing its semantics. This is essential for incident response teams and developers alike to understand foreign code, assess how malicious programs work, and gather clues about the perpetrators. In this work, we focus on the challenges specific to PHP deobfuscation. To do so, we first study ten PHP obfuscators to assess how they obfuscate code by identifying and isolating the transformations they employ. Based on these insights, we propose Phoebe, a deterministic deobfuscator that statically reverses PHP obfuscation. We built a large dataset of PHP files sampled from popular open-source applications and their obfuscated versions to showcase Phoebe's efficacy. We then deobfuscate this dataset with both Phoebe and two other best-in-class PHP deobfuscators. We assess the results based on syntactic correctness, similarity, and code complexity. While Phoebe is the only deobfuscator that does not cause syntax errors, it also retrieves files that resemble the original file by 80% similarity, outperforming the competition by over 40%.

The DOM tree is a central part of modern web development, enabling JavaScript to interact with page content and structure. Only a few prior studies have studied its trustworthiness, despite its widespread use in guiding program logic and security decisions. Most notably, script gadgets have shown how this trust can be exploited by triggering the execution of benign JavaScript fragments with seemingly harmless markup injections. In this paper, we show that script gadgets are only the tip of the iceberg. Seemingly-benign markup injections can trigger the execution of fragments - that we call DOM gadgets - that, unlike script gadgets, do not necessarily result in a cross-site scripting vulnerability. Instead, they can result in a broader set of attacks, such as browser request hijacking attacks, cross-site request forgery attacks, and user interface manipulations.

While protecting user data is essential, software developers often fail to fulfill privacy requirements. However, the reasons why they struggle with privacy-compliant implementation remain unclear. Is it due to a lack of knowledge, or is it because of insufficient support? To provide foundational insights in this field, we conducted a qualitative 5-hour programming study with 30 professional software developers implementing 3 privacy-sensitive programming tasks that were designed with GDPR compliance in mind. To explore if and how developers implement privacy requirements, participants were divided into 3 groups: control, privacy prompted, and privacy expert-supported. After task completion, we conducted follow-up interviews. Alarmingly, almost all participants submitted non-GDPR-compliant solutions (79/90). In particular, none of the 3 tasks were solved privacy-compliant by all 30 participants, with the non-prompted group having the lowest number of 3 out of 30 privacy-compliant solution attempts. Privacy prompting and expert support only slightly improved participants' submissions, with 6/30 and 8/30 privacy-compliant attempts, respectively. In fact, all participants reported severe issues addressing common privacy requirements such as purpose limitation, user consent, or data minimization. Counterintuitively, although most developers exhibited minimal confidence in their solutions, they rarely sought online assistance or contacted the privacy expert, with only 4 out of 10 expert-supported participants explicitly asking for compliance confirmation. Instead, participants often relied on existing implementations and focused on implementing functionality and security first.

The introduction of the General Data Protection Regulation (GDPR) in 2018 marked a pivotal moment in the evolution of data protection within the European Union (EU). Consequently, companies have since been legally obliged to respect users' privacy, and, if found to be in violation, risk incurring fines. While this regulatory change greatly benefits users, software developers, on the other hand, face a tremendous challenge to make their applications compliant, creating a gap between legal requirements and effective software development. Several solutions have been proposed to bridge the gap for web application developers. However, it is unclear to what extent they fulfill the requirements laid out by the GDPR. In this work, we look at three frameworks that aim to aid compliance for web applications. To efficiently assess them, we propose a methodology and several benchmarks to evaluate and compare the frameworks. From the GDPR, we have derived a set of requirements that do not entail institutional changes but have technical implications for software. Leveraging these requirements, we evaluate both the proposed solutions' enforcement capabilities and computational overhead. Our comparison shows that each framework can, if configured correctly, enforce a different subset of GDPR requirements. Finally, based on the insights gained, we provide recommendations for the community on how to make further progress on operationalizing the GDPR.

Websites rely on server-side HTML sanitization to defend against the ever-present threat of cross-site scripting attacks. Parsing arbitrary pieces of markup to assess whether they contain an exploit payload is far from trivial. This complexity leads to divergences between the parsing results of the sanitizer and the user’s browser. These so-called parsing differentials open the door for the unexplored category of mutation-based attacks. Here, an attacker abuses the sanitizer’s incorrect HTML parser to either directly bypass it or coerce it to transform benign markup into a dangerous exploit payload.In this work, we study the prevalence of such parsing differentials and their security impact. To this end, we built a generator for HTML fragments that are difficult to parse and evaluated how 11 sanitizers across five programming languages deal with such inputs. We found that parsing differentials are commonplace, as each assessed sanitizer has at least several functional deficiencies leading to overzealous removal of benign input. Even worse, we were able to automatically bypass all but two of the 11 sanitizers, painting a dire picture of the state of server-side HTML sanitization.

Browser fingerprinting is an effective technique to track web users by building a fingerprint from their browser attributes. It is also stealthy because the tracker uses legitimate JavaScript API calls offered by the browser engine, which can be obfuscated before they are sent to a (third-party) server. Current browser fingerprinting methodologies employ coarse-grained collection and classification techniques, such as binary classification of fingerprinters based on the number of non-obfuscated exfiltrated attributes. As a result, they produce inconsistent findings. Meanwhile, the privacy of millions of web users is at risk daily. We address this gap by presenting FP-tracer, a novel methodology to detect and classify browser fingerprinters based on dynamic taint tracking and joint entropy classification. Our methodology enables detecting first- and third-party fingerprinters even when they use obfuscation by tainting attributes, propagating them, and logging when they are leaked (via 62 sources and 25 sinks). Moreover, it discriminates the invasiveness of fingerprinting activities, even from the same service, by measuring the joint entropy of the collected attributes and clustering them. We implement FP-tracer by extending Foxhound, a privacy-oriented Firefox fork with numeric type tainting, more taint tracking sources and sinks, support for multiple sources, and better logging capabilities. We embed our implementation in our automated crawling infrastructure, which is capable of testing websites in parallel using programmable and reproducible logic. We will open-source our implementation. We evaluate FP-tracer by performing a large-scale crawl over the Tranco Top 100K, and detect, amongst others, audio, canvas, and storage fingerprinting on the web. Among others, we find high fingerprinting activities in 8% of domains, with more moderate activity reaching 75%. Notably, fingerprinting is almost five times more likely to be performed by third-party scripts for high activity levels. In addition, we measure that the most severe category of fingerprinting obfuscates 46% of transmitted attributes, and 38% of fingerprinters involve two or more domains. Finally, we find that existing consent banners do not provide an effective defense against browser fingerprinting

Online messaging has rapidly emerged as today's primary communication platform, extending from personal, to business and even to government channels. But can these services be trusted to maintain the privacy of your communication? This paper addresses this question by evaluating 105 different online messaging platforms. Utilizing “honey” messages and active HTTP(S) , WebSocket, and WebRTC traffic monitoring, along with continuous observation of honey token access, we determine which messaging services process user messages beyond mere transmission. We conduct a large-scale honey token-based study on 69 popular web and 36 mobile messaging applications. Our findings reveal that 34 % of messaging services show capabilities of server-side message analysis. Seven of these messengers evidently conduct an extended analysis of the messages, reusing the results hours to an observed maximum of a month after the chat concluded. This shows that one cannot automatically expect the same confidentiality when chatting via messengers compared to in-person communication.

Recent advances in data protection regulations brings privacy benefits for website users, but also comes at a cost for operators. Retrofitting the privacy requirements of laws such as the General Data Protection Regulation (GDPR) onto legacy software requires significant auditing and development effort. In this work we demonstrate that this effort can be minimized by viewing data protection requirements through the lens of information flow tracking. Instead of manual inspections of applications, we propose a lightweight enforcement engine which can reliably prevent unlawful data processing even in the presence of bugs or misconfigured software. Taking GDPR regulations as a starting point, we define twelve software requirements which, if implemented properly, ensure adequate handling of personal data. We go on to show how these requirements can be fulfilled by proposing a metadata structure and enforcement policies for dynamic information flow tracking frameworks. To put this idea into practice, we present Fontus, a Java Virtual Machine (JVM) information flow tracking framework, which can transparently label personal data in existing Java applications in order to aid compliance with data protection regulations. Finally, we demonstrate the applicability of our approach by enforcing data protection polices across 7 large, open source web applications, with no changes required to the applications themselves.

Web applications utilizing databases for persistence frequently expose security flaws due to race conditions. The commonly accepted remedy to this problem is to envelope related database operations in transactions. Unfortunately, sole trust in transactions to isolate competing sets of database interactions is often misplaced. While the precise isolation properties of transactions depend on the configuration of the database management system (DBMS), the default configuration of common DBMS exposes transactions to anomalies that render their protection worthless.

The General Data Protection Regulation (GDPR) and related regulations have had a profound impact on most aspects related to privacy on the Internet. By requiring the user’s consent for e.g., tracking, an affirmative action has to take place before such data collection is lawful, leading to spread of so-called cookie banners across the Web. While the privacy impact and how well companies adhere to those regulations have been studied in detail, an open question is what effect these banners have on the security of netizens.

Despite the considerable amounts of resources invested into securing the Web, Cross-Site Scripting (XSS) is still widespread. This is especially true for Client-Side XSS as, unlike server-side application frameworks, Web browsers do not ship with standard protection routines, so-called sanitizers. Web developers, therefore, have to either resort to third-party libraries or write their own sanitizers to stop XSS in its tracks. Such custom sanitizer routines – dubbed hand sanitizers in the following – are notoriously difficult to implement securely. In this paper, we present a technique to automatically detect, extract, analyze, and validate JavaScript sanitizer functions using a combination of taint tracking and symbolic string analysis. While existing work evaluates server-side sanitizers using a small number of applications, we present the first large-scale study of client-side JavaScript sanitizers. Of the most popular 20,000 websites, our method detects 705 unique sanitizers across 1,415 domains, of which 12.5% are insecure. Of the vulnerable sanitizers, we were able to automatically generate circumventing exploits for 51.3% of them, highlighting the dangers of manual sanitization attempts. Interestingly, vulnerable sanitizers are present across the entire range of website rankings considered, and we find that most sanitizers are not generic enough to thwart XSS if used in just a slightly different context. Finally, we explore the origins of vulnerable sanitizers to motivate adopting a standardized sanitization API available directly in the browser.

Car-to-X i.e. Car-to-Anything communication based on standardized IEEE 802.11p radio technology is comprised with wireless communication between cars (Car-to-Car) and between vehicles and the environment (Car-to-Infrastructure). In order to develop Car-to-X applications based on this standard one needs to model parameters such as the vehicle's position, velocity, acceleration etc. and parameters of the vehicle's environment. Typically, the underlying domain models are designed in an ad-hoc manner and the domain rules become hard-coded into the source- code of the application software. In this paper we describe an alternative and more flexible approach. The model is described in almost plain English using a Domain Specific Language (DSL) and translated into target code via parser technology based on the ANTLR tool-chain. This provides more flexibility not only in creating and maintaining the domain rules, but also with regards to generating code for entirely different target languages and technology environments. For instance, we demonstrate to generate Java code for a simulation environment and C-code for the embedded device from the same rule definitions.