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.

As privacy concerns grow, organizations and policy makers promote the use of privacy-enhancing technologies (PETs) to improve user trust and data-sharing behaviors. However, privacy-enhancing technologies (PETs) are often technologically complex and opaque to lay users. It is challenging to understand and effectively communicate the functionality of complex PETs to the users, such as Secure Multi-Party Computation (MPC). Studies typically assess the impact of new PETs by presenting users with a high-level description of the technology before measuring how this treatment changed their attitude or behavior. These results influence business and regulatory decisions (see Gartner's Hype Cycle for Emerging Technology [123]). In the present study, we question this approach. We assess whether naming specific PETs and providing generic descriptions impact users' willingness to put trust in service providers and share their data. Our survey presented three randomized controlled trials with 1,457 participants in a data marketplace scenario. The first group was treated with a PET (MPC), the second group with a fictional PET, and the third with a non-PET, serving as a control group. Our findings reveal that user trust and data-sharing willingness increased with MPC and the fictional PET, indicating that the high-level description, rather than the technology name, shapes user perception. We conclude that claiming the use of a PET is not an effective method to measure the impact of actually using this technology. However, given their mental model, lay users cannot verify the privacy claims of such descriptions presented in studies or by service providers. This increases the risks of users being deceived into a false sense of privacy, leading them to expose more private data than they otherwise would.

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.

Are mobile app developers actively enabling data collection by advertisement and analytics companies, or are they unaware of the implications of using the provided software development kits (SDKs)? Given that the current mobile app ecosystem inadvertently involves collecting user data, which often infringes upon data protection and privacy standards, the question of the underlying reason for the permissibility of data processing arises. We contribute to this research for both Android and iOS by performing a two-step qualitative analysis. First, we conduct a structured documentation review of five advertisement and five analytics SDKs, focusing on privacy-related information. Subsequently, we implement a set of example apps utilizing the basic functionality of each SDK. This custom utilization of the SDK allows us to perform a fine-grained traffic analysis of each required step from initialization until utilization. Our results show that only little guidance on data protection compliance is provided. The observed network traffic shows that overall data collection by SDKs is similar between operating systems and only requires basic usage by the developer to trigger. We discover that with current SDKs, developers have minimal influence over the collected data, as merely using the basic functionality already results in data collection, with advertisement SDKs collecting more data than analytics SDKs. Overall, we explain the observed data protection infringement in ongoing mobile privacy research by documenting how developers must bear with opaque SDKs that lead to data collection simply due to usage.

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.

As websites grow ever more dynamic and load more of their content on the fly, automatically interacting with them via simple tools like curl is getting less of an option. Instead, headless browsers with JavaScript support, such as PhantomJS and Puppeteer, have gained traction on the Web over the last few years. For various use cases like messengers and social networks that display link previews, these browsers visit arbitrary, user-controlled URLs. To avoid compromise through known vulnerabilities, these browsers need to be diligently kept up-to-date. In this paper, we investigate the phenomenon of what we coin server-side browsers at scale and find that many websites are running severely outdated browsers on the server-side. Remarkably, the majority of them had not been updated for more than 6 months and over 60% of the discovered implementations were found to be vulnerable to publicly available proof-of-concept exploits.

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.

Nowadays, applications expose administrative endpoints to the Web that can be used for a plethora of security sensitive actions. Typical use cases range from running small snippets of user-provided code for rapid prototyping, administering databases, and running CI/CD pipelines, to managing job scheduling on whole clusters of computing devices. While accessing these applications over the Web make the lives of their users easier, they can be leveraged by attackers to compromise the underlying infrastructure if not properly configured.

At the end of 2020, Apple introduced privacy nutritional labels, requiring app developers to state what data is collected by their apps and for what purpose. In this paper, we take an in-depth look at the privacy labels and how they relate to actual transmitted data. First, we give an exploratory statistically evaluation of 11074 distinct apps across 22 categories and their corresponding privacy label or lack thereof. Our dataset shows that only some apps provide privacy labels, and a small number self-declare that they do not collect any data. Additionally, our statistical methods showcase the differences of the privacy labels across application categories. We then select a subset of 1687 apps across 22 categories from the German App Store to conduct a no-touch traffic collection study. We analyse the traffic against a set of 18 honey-data points and a list of known advertisement and tracking domains. At least 276 of these apps violate their privacy label by transmitting data without declaration, showing that the privacy labels’ correctness was not validated during the app approval process. In addition, we evaluate the apps’ adherence to the GDPR in respect of providing a privacy consent form, through collected screenshots, and identify numerous potential violations of the directive.

With the introduction of memory-bound cryptocurrencies, such as Monero, the implementation of mining code in browser-based JavaScript has become a worthwhile alternative to dedicated mining rigs. Based on this technology, a new form of parasitic computing, widely called cryptojacking or drive-by mining, has gained momentum in the web. A cryptojacking site abuses the computing resources of its visitors to covertly mine for cryptocurrencies. In this paper, we systematically explore this phenomenon. For this, we propose a 3-phase analysis approach, which enables us to identify mining scripts and conduct a large-scale study on the prevalence of cryptojacking in the Alexa 1 million websites. We find that cryptojacking is common, with currently 1 out of 500 sites hosting a mining script. Moreover, we perform several secondary analyses to gain insight into the cryptojacking landscape, including a measurement of code characteristics, an estimate of expected mining revenue, and an evaluation of current blacklist-based countermeasures.

The direct client-side inclusion of cross-origin JavaScript resources in Web applications is a pervasive practice to consume third-party services and to utilize externally provided libraries. The downside of this practice is that such external code runs in the same context and with the same privileges as the first-party code. Thus, all potential security problems in the code directly affect the including site. To explore this problem, we present an empirical study which shows that more than 25% of all sites affected by Client-Side Cross-Site Scripting are only vulnerable due to a flaw in the included third-party code. Motivated by this finding, we propose ScriptProtect, a non-intrusive transparent protective measure to address security issues introduced by external script resources. ScriptProtect automatically strips third-party code from the ability to conduct unsafe string-to-code conversions. Thus, it effectively removes the root-cause of Client-Side XSS without affecting first-party code in this respective. As ScriptProtect is realized through a light-weight JavaScript instrumentation, it does not require changes to the browser and only incurs a low runtime overhead of about 6%. We tested its compatibility on the Alexa Top 5,000 and found that 30% of these sites could benefit from ScriptProtect's protection today without changes to their application code.

Low-interaction honeypots (LIHPs) are a well-established tool to monitor malicious activities by emulating the appearance and behavior of a real system. However, existing honeypots share a common problem: Anyone aware of their existence can easily fingerprint and subsequently avoid them.

Cross-Site Scripting (XSS) is an unremitting problem for the Web. Since its initial public documentation in 2000 until now, XSS has been continuously on top of the vulnerability statistics. Even though there has been a considerable amount of research and developer education to address XSS on the source code level, the overall number of discovered XSS problems remains high. Because of this, various approaches to mitigate XSS have been proposed as a second line of defense, with HTML sanitizers, Web Application Firewalls, browser-based XSS filters, and the Content Security Policy being some prominent examples. Most of these mechanisms focus on script tags and event handlers, either by removing them from user-provided content or by preventing their script code from executing.

Cross-Site Request Forgery (CSRF) vulnerabilities are a severe class of web vulnerabilities that have received only marginal attention from the research and security testing communities. While much effort has been spent on countermeasures and detection of XSS and SQLi, to date, the detection of CSRF vulnerabilities is still performed predominantly manually.

The Internet is an ever-growing ecosystem with diverse software and hardware applications deployed in numerous countries around the globe. This heterogenous structure, however, is reduced to a homogenous means of addressing servers, i.e., their IP address. Due to this, analyzing different Internet services for vulnerabilities at scale is easy, leading to many researcher focusing on large-scale detection of many types of flaws. On the other hand, the persons responsible for the administration of said services are as heterogenous as the Internet architecture itself: be it in spoken languages or knowledge of technical details of the services. The notification of vulnerable services has long been treated as a side note in research. Recently, the community has focussed more not only the detection of flaws, but also on the notification of affected parties. These works, however, only analyze a small segment of the problem space. Hence, in this paper, we investigate the issues encountered by the previous works and provide a number of future directions for research, ultimately aiming to allow for an easier means of notifying affected parties about vulnerabilities at scale.

Although studies have shown that at least one in ten Web pages contains a client-side XSS vulnerability, the prevalent causes for this class of Cross-Site Scripting have not been studied in depth. Therefore, in this paper, we present a large-scale study to gain insight into these causes. To this end, we analyze a set of 1,273 real-world vulnerabilities contained on the Alexa Top 10k domains using a specifically designed architecture, consisting of an infrastructure which allows us to persist and replay vulnerabilities to ensure a sound analysis. In combination with a taint-aware browsing engine, we can therefore collect important execution trace information for all flaws. Based on the observable characteristics of the vulnerable JavaScript, we derive a set of metrics to measure the complexity of each flaw. We subsequently classify all vulnerabilities in our data set accordingly to enable a more systematic analysis. In doing so, we find that although a large portion of all vulnerabilities have a low complexity rating, several incur a significant level of complexity and are repeatedly caused by vulnerable third-party scripts. In addition, we gain insights into other factors related to the existence of client-side XSS flaws, such as missing knowledge of browser-provided APIs, and find that the root causes for Client-Side Cross-Site Scripting range from unaware developers to incompatible first- and third-party code.

To ease the burden of repeated password authentication on multiple sites, modern Web browsers provide password managers, which offer to automatically complete password fields on Web pages, after the password has been stored once. Unfortunately, these managers operate by simply inserting the clear-text password into the document's DOM, where it is accessible by JavaScript. Thus, a successful Cross-site Scripting attack can be leveraged by the attacker to read and leak password data which has been provided by the password manager. In this paper, we assess this potential threat through a thorough survey of the current password manager generation and observable characteristics of password fields in popular Web sites. Furthermore, we propose an alternative password manager design, which robustly prevents the identified attacks, while maintaining compatibility with the established functionality of the existing approaches.

The term "phishing" describes a class of social engineering attacks on authentication systems, that aim to steal the victim's authentication credential, e.g., the username and password. The severity of phishing is recognized since the mid-1990's and a considerable amount of attention has been devoted to the topic. However, currently deployed or proposed countermeasures are either incomplete, cumbersome for the user, or incompatible with standard browser technology. In this paper, we show how modern JavaScript API's can be utilized to build PhishSafe, a robust authentication scheme, that is immune against phishing attacks, easily deployable using the current browser generation, and requires little change in the end-user's interaction with the application. We evaluate the implementation and find that it is applicable to web applications with low efforts and causes no tangible overhead.

In recent years, the Web witnessed a move towards sophis- ticated client-side functionality. This shift caused a signifi- cant increase in complexity of deployed JavaScript code and thus, a proportional growth in potential client-side vulnera- bilities, with DOM-based Cross-site Scripting being a high impact representative of such security issues. In this paper, we present a fully automated system to detect and validate DOM-based XSS vulnerabilities, consisting of a taint-aware JavaScript engine and corresponding DOM implementation as well as a context-sensitive exploit generation approach. Using these components, we conducted a large-scale analysis of the Alexa top 5000. In this study, we identified 6167 unique vulnerabilities distributed over 480 domains, show- ing that 9,6% of the examined sites carry at least one DOM- based XSS problem.

This paper presents "BetterAuth", an authentication protocol for Web applications. Its design is based on the experiences of two decades with the Web. BetterAuth addresses existing attacks on Web authentication, ranging from network attacks to Cross-site Request Forgery up to Phishing. Furthermore, the protocol can be realized completely in standard JavaScript. This allows Web applications an early adoption, even in a situation with limited browser support.

Consumption traces collected by Smart Meters are highly privacy sensitive data. For this reason, current best practice is to store and process such data in pseudonymized form, separating identity information from the consumption traces. However, even the consumption traces alone may provide many valuable clues to an attacker, if combined with limited external indicators. Based on this observation, we identify two attack vectors using anomaly detection and behavior pattern matching that allow effective depseudonymization. Using a practical evaluation with real-life consumption traces of 53 households, we verify the feasibility of our techniques and show that the attacks are robust against common countermeasures, such as resolution reduction or frequent re-pseudonymization.

Cross-site scripting (XSS) has emerged to one of the most prevalent type of security vulnerabilities. While the reason for the vulnerability primarily lies on the server-side, the actual exploitation is within the victim's Web browser on the client-side. Therefore, an operator of a Web application has only very limited evidence of XSS issues. In this paper, we propose a passive detection system to identify successful XSS attacks. Based on a prototypical implementation, we examine our approach's accuracy and verify its detection capabilities. We compiled a data-set of 500.000 individual HTTP request/response-pairs from 95 popular web applications for this, in combination with both real word and manually crafted XSS-exploits; our detection approach results in a total of zero false negatives for all tests, while maintaining an excellent false positive rate for more than 80% of the examined Web applications.