Comprehensive and representative measurements are crucial to understand security and privacy risks on the Web. However, researchers have long been reluctant to investigate server-side vulnerabilities at scale, as this could harm servers, disrupt service, and cause financial damage. This can lead to operator backlash and problems in peer review, as the boundaries posed by the law, ethics, and operators’ stance towards security research are largely unclear.In this paper, we address this research gap and investigate the boundaries of server-side scanning (3S) on the Web. To that end, we devise five typical scenarios for 3S on the Web to obtain concrete practical guidance. We analyze qualitative data from 23 interviews with legal experts, using German law as a case study, members of Research Ethics Committees, and website and server operators to learn what types of 3S are considered acceptable and which behavior would cross a red line. To verify our findings, we further conduct an online survey with 119 operators.Our analysis of these different perspectives shows that the absence of judicial decisions and clear ethical guidelines poses challenges in overcoming the risks associated with 3S, despite a slight majority (57%) of operators having a positive stance towards such academic research throughout the interviews and the survey. As a first step to mitigate these challenges, we suggest best practices for future 3S research and a pre-registration process to provide a reliable and transparent environment for 3S-based research that reduces uncertainty for researchers and operators alike.

In order to mitigate the effect of Web attacks, modern browsers support a plethora of different security mechanisms. Mechanisms such as anti-Cross-Site Request Forgery (CSRF) tokens or nonces in a Content Security Policy rely on a random number that must only be used once. Notably, those Web security mechanisms are shipped through HTML tags or HTTP response headers from the server to the client side. To decrease the server load and the traffic burdened on the server infrastructure, many Web applications are served via a Content Delivery Network (CDN), which caches certain responses from the server to deliver them to multiple clients. This, however, affects not only the content but also the settings of the security mechanisms deployed via HTML meta tags or HTTP headers. If those are also cached, their content is fixed, and the security tokens are no longer random for each request. Even if the responses are not cached, operators may re-use tokens, as generating random numbers that are unique for each request introduces additional complexity for preserving the state on the server side. This work sheds light on the re-usage of security tokens in the wild, investigates what caused the static tokens, and elaborates on the security impact of the non-random security tokens.

The Web has improved our ways of communicating, collaborating, teaching, and entertaining us and our fellow human beings. However, this cornerstone of our modern society is also one of the main targets of attacks, most prominently Cross-Site Scripting (XSS). A correctly crafted Content Security Policy (CSP) is capable of effectively mitigating the effect of those Cross-Site Scripting attacks. However, research has shown that the vast majority of all policies in the wild are trivially bypassable.

The Web, as one of the core technologies of modern society, has profoundly changed the way we interact with people and data. One of the worst attacks on the Web is Cross-Site Scripting (XSS), in which an attacker is able to inject their malicious JavaScript code into a Web application, giving this code full access to the victimized site. To mitigate the impact of markup injection flaws that cause XSS, support for the Content Security Policy (CSP) is nowadays shipped in all browsers. Deploying such a policy enables a Web developer to whitelist from where script code can be loaded, essentially constraining the capabilities of the attacker to only be able to execute injected code from the said whitelist. As recently shown by Lekies et al., injecting script markup is not a necessary prerequisite for a successful attack in the presence of so-called script gadgets. These small snippets of benign JavaScript code transform non-script markup contained in a page into executable JavaScript, opening the door for bypasses of a deployed CSP. Especially in combination with CSP's logic in handling redirected resources, script gadgets enable attackers to bypass an otherwise secure policy. In this paper, we, therefore, ask the question: is securely deploying CSP even possible without a priori knowledge of all files hosted on even a partially trusted origin? To answer this question, we investigate the severity of the findings of Lekies et al., showing real-world Web sites on which, even in the presence of CSP and without code containing such gadgets being added by the developer, an attacker can sideload libraries with known script gadgets, as long as the hosting site is whitelisted in the CSP. In combination with CSPs matching logic for redirects, this enables us to bypass 10% of otherwise secure policies in the wild. To further answer our main research question, we conduct a hypothetical what-if analysis. Doing so, we automatically generate sensible CSPs for all of the Top 10,000 sites and show that around one-third of all sites would still be susceptible to a bypass through script gadget sideloading due to heavy reliance on third parties that also host such libraries.

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.