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%.

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.

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.

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.

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.

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.

Recently, the live-monitor MATor for formally analyzing user anonymity within the Tor network has been proposed (CCS'14). However, this monitor only considers adversaries that compromise part of the Tor network itself, not Internet infrastructural adversaries. In this work we present a formal technique for analyzing Tor against malicious or overly curious network infrastructure.