Leakuidator: Leaky Resource Attacks and Countermeasures

Abstract

Leaky resource attacks leverage the popularity of resource-sharing services to conduct targeted deanonymization on the web. They are simple to execute because many resource-sharing services are inherently vulnerable due to the trade-offs made between security and functionality. Even though previous work has shown that such attacks can lead to serious privacy threats, defending against this threat is an area that has remained largely unaddressed.

In this work, we advance the state of the art on leaky resource attacks on both attack effectiveness and attack mitigation fronts. We first show that leaky resource attacks have a larger attack surface than what was previously believed, by showing reliable attack implementations that work across a broader range of browsers and by identifying new variants of the attack. We then propose Leakuidator, the first client-side defense that can be deployed right away, without buy-in from browser vendors and website owners. At a high level, Leakuidator identifies potentially suspicious requests made when a webpage is rendered and for each such request: (1) renders the request by first removing cookies from it, and (2) initiates a second request that is identical with the original request (i.e., contains the cookies that were removed), but does not render its response. This additional request maintains compatibility with existing web functionality, such as analytics and tracking services. We have implemented Leakuidator as a browser extension for three Chromium-based browsers. Experimental results show that Leakuidator introduces a small overhead and thus the impact on user experience is minimal. The extension also includes usability knobs, allowing users to reuse past choices and to adjust how strict is the criteria for identifying potentially suspicious requests.

Appendices

A JavaScript-Based Leaky Resource Attack

Script-Based Attack. The attack page can embed the JavaScript code shown in Fig. 7 in order to disclose information about the outcome of the SD-URL request [28]. The response to the SD-URL request is different depending on the user’s state with respect to the target website. In one state, the user is able retrieve the image successfully, triggering the onload callback which informs the attacker that the intended victim has visited the attack page. In the other state, the user is unable to retrieve the image, trigerring the onerror callback.

Fig. 7.

Communication method using JavaScript.

B Drawbacks of Existing Defenses

The SameSite cookie attribute can be used to impose restrictions when cookies associated with a website (i.e., target website) can actually be sent to the target website. When set, this attribute can be assigned three values: strict, lax, and none. If it is set to strict, cookies are sent only when the target website matches the website currently shown in the browser’s URL bar. If it set to lax, cookies will be sent when the condition for the strict value is met, but also when the website in the browser’s URL bar matches the target website after a top-level navigation. This allows, for example, authentication cookies to be sent to an external website when using a single sign-on service. When the SameSite attribute is set to none, the browser will always send cookies along with requests to the target website.

Although setting this cookie attribute to strict or lax could limit the attack surface in theory, our findings (Sect. 4.4) show that many popular sharing services are still vulnerable, because the attribute is either set to none, or not enabled at all. A major reason for this is that the SameSite cookie attribute interferes with services provided by websites, because third party requests require authentication cookies being sent along when embedding the service in another website (e.g., a watch later button on an embedded YouTube video, or personalized service such as favorite locations when embedding GoogleMaps).