No abstract

No abstract

JavaScript is used by web developers to enhance the interactivity of their sites, offload work to the users' browsers and improve their sites' responsiveness and user-friendliness, making web pages feel and behave like traditional desktop applications. An important feature of JavaScript, is the ability to combine multiple libraries from local and remote sources into the same page, under the same namespace. While this enables the creation of more advanced web applications, it also allows for a malicious JavaScript provider to steal data from other scripts and from the page itself. Today, when developers include remote JavaScript libraries, they trust that the remote providers will not abuse the power bestowed upon them.In this paper, we report on a large-scale crawl of more than three million pages of the top 10,000 Alexa sites, and identify the trust relationships of these sites with their library providers. We show the evolution of JavaScript inclusions over time and develop a set of metrics in order to assess the maintenance-quality of each JavaScript provider, showing that in some cases, top Internet sites trust remote providers that could be successfully compromised by determined attackers and subsequently serve malicious JavaScript. In this process, we identify four, previously unknown, types of vulnerabilities that attackers could use to attack popular web sites. Lastly, we review some proposed ways of protecting a web application from malicious remote scripts and show that some of them may not be as effective as previously thought.

No abstract

Abstract. Code injection attacks that target the control-data of an application have been prevalent amongst exploit writers for over 20 years. Today however, these attacks are getting increasingly harder for attackers to successfully exploit due to numerous countermeasures that are deployed by modern operating systems. We believe that this fact will drive exploit writers away from classic control-data attacks and towards data-only attacks. In data-only attacks, the attacker changes key data structures that are used by the program's logic and thus forces the control flow into existing parts of the program that would be otherwise unreachable, e.g. overflowing into a boolean variable that states whether the current user is an administrator or not and setting it to "true" thereby gaining access to the administrative functions of the program. In this paper we present ValueGuard, a canary-based defense mechanism to protect applications against data-only buffer overflow attacks. ValueGuard inserts canary values in front of all variables and verifies their integrity whenever these variables are used. In this way, if a buffer overflow has occurred that changed the contents of a variable, ValueGuard will detect it since the variable's canary will have also been changed. The countermeasure itself can be used either as a testing tool for applications before their final deployment or it can be applied selectively to legacy or high-risk parts of programs that we want to protect at run-time, without incurring extra time-penalties to the rest of the applications.

Browser extensions enable rich experience for the users of today's web. Being deployed with elevated privileges, extensions are given the power to overrule web pages. As a result, web pages often seek to detect the installed extensions, sometimes for benign adoption of their behavior but sometimes as part of privacy-violating user fingerprinting. Researchers have studied a class of attacks that allow detecting extensions by probing for Web Accessible Resources (WARs) via URLs that include public extension IDs. Realizing privacy risks associated with WARs, Firefox has recently moved to randomize a browser extension's ID, prompting the Chrome team to plan for following the same path. However, rather than mitigating the issue, the randomized IDs can in fact exacerbate the extension detection problem, enabling attackers to use a randomized ID as a reliable fingerprint of a user. We study a class of extension revelation attacks, where extensions reveal themselves by injecting their code on web pages. We demonstrate how a combination of revelation and probing can uniquely identify 90% out of all extensions injecting content, in spite of a randomization scheme. We perform a series of large-scale studies to estimate possible implications of both classes of attacks. As a countermeasure, we propose a browser-based mechanism that enables control over which extensions are loaded on which web pages and present a proof of concept implementation which blocks both classes of attacks. Probing attack: Previous works [55], [53] have focused on non-behavioral detection, based on a browser extension's listed WARs. The WARs are public resources which can be fetched from the context of a web page using a predefined URL, consisting of a public extension ID (or Universally Unique Identifier (UUID)) and the path to that resource. With the predefined URL to fetch a WAR from an extension, a web page can mount a probing attack, designed to detect an extension by probing for WARs, since a response with the probed WAR indicates the corresponding extension is installed. This attack can be seen in Figure 1a where 1 denotes the requests made by the attacker to probe for an installed browser extension. If the browser extension is in the browser context, the attacker will get a response consisting of the requested WAR (denoted by 2). This attack can be magnified by probing for a set of browser extensions' resources, thereby enumerating

No abstract

No abstract