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.

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.

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.