Browsers' built-in tools that crumble web cookies that track you around the internet can be bypassed or rendered ineffective by malicious websites.
In a paper presented at the USENIX Security Symposium this week, a trio of researchers from KU Leuven in Belgium describe how they developed a framework to analyze the enforcement of browser-based policies governing third-party requests.
First-party requests refer to network requests for resources – text, images, videos, and the like – from the domain associated with the visited website. Third-party requests refer to network requests for resources from websites other than the one displayed in the browser address bar. When websites run ads, they generally include code that makes third-party requests to ad servers.
Modern browsers will place cookie files in response to both first- and third-party requests and they do so in a way that's open to security risks, like cross-site request forgery and cross-site script inclusion, and to privacy abuse, like third-party tracking.
To mitigate these threats, the various browsers implement policies that disallow certain behavior. For example, a developer creating a website can set the
SameSite attribute on the site's cookie to indicate that it should accompany only first-party requests. Other examples include the tracking protection modes offered by Firefox and Safari and browser extensions that try to restrict third-party cookies.
Gaps in the system
The boffins from Belgium – Gertjan Franken, Tom Van Goethem and Wouter Joosen – used their testing framework and found that for 7 browsers, 31 ad blocking extensions and 15 anti-tracking extensions, the defenses put in place to prevent cookie abuse have gaps. Their test data is available on a website associated with their paper.
"Overall, we found that browser implementations exhibited a highly inconsistent behavior with regard to enforcing policies on third-party requests, resulting in a high number of bypasses," they state in their paper.
A number of the issues identified qualify as bugs, which they reported to concerned parties. For example, the researchers found that the option to block third-party cookies in Microsoft's Edge browser simply didn't work.
"For Edge, we found that, surprisingly, the option to block third-party cookies had no effect: all cookies that were sent in the instance with default settings, were also sent in the instance with custom settings," the paper says.
An Edge bug report was supposedly filed about this issue but the associated URL returns a page not found error.
For Firefox, the researchers found that the browser's Tracking Protection can be bypassed to allow cross-site requests to blacklisted domains and that requests initiated by the deprecated AppCache API can't easily be distinguished from requests coming from browser background processes, making such requests difficult to block.
Tor blimey, governor
Chrome, Safari and Opera all had issues too, as did the Tor browser. The Cliqz browser, a Firefox fork tuned for privacy, was tripped by the inclusion of a data: URL as the value of an img src attribute. The researchers suggest this confused the browser engine and prevented third-party cookies from being removed.
Here's the offending code:
<img src="data:image" / svg+xml , <svg> <image xlink:href= 'https: // third-party.com / leak '> </ image> </ svg> ">
The same held true for the ad blocking and anti-tracking extensions tested – a group that includes AdBlock Plus, Disconnect, Ghostery, and uBlock Origin, among others. For each one, there was at least one way to bypass promised protection.
"Because PDFs can be included in iframes, and thus made invisible to the end user, and because it can be used to send authenticated POST requests, this bypass technique could be used to track users or perform cross-site attacks without raising the attention of the victim," they observe in their paper.
Google bod wants cookies to crumble and be remade into something more secureREAD MORE
At the time they disclosed the issue, PDFium only sent requests and wasn't set up to receive response data. However, the researchers spotted a placeholder comment in the Chromium PDF handling source code indicating the intent to return a response, which could open the door to cross-site script injection and cross-site timing attacks.
Back in March when Google's engineers were discussing the researchers' bug report, it appeared the issue might not be easy to fix. Google software engineer Robert Cronin explained that PDFium qualifies as an extension even though it is built into the browser and extensions cannot modify other extensions for security reasons. The only real work around at the time was to use a different PDF rendering tool.
The KU Leuven trio argues that their findings demonstrate the need to continually test browsers as new features get added to ensure that privacy promises conform with capabilities. ®