traktofon
commented
7 years ago Hi chocolateboy, thanks for the report.
In my understanding, the bug was triggered by the HTML parser (which indeed only processes web pages), but this parser was running as a module for nginx, and the nginx process was also handling other types of requests, so that actually memory related to those requests could be disclosed. As far as I understand this section of the CF incident report, plenty of non-HTML data was disclosed.
Example scenario: User requests to load an image from a website behind CF, but needs to send his session token/cookie along to have access to the image (think okcupid). The requested resource is an image, but the request headers might have been leaked through cloudbleed.
The false positives you mention is, in my opinion, a different problem. Namely, if any request in the context of a tab is served by CF, the whole tab is "tainted". In a sense, this is correct: the page does use CF because some part of it is using CF. But I agree, this is potentially confusing for the user.
My suggestion is the following:
- For each tab, bin the requests served by CF by domain.
- If the tab's primary domain is affected, use red icon. If only 3rd party domains affected, use yellow icon.
- Show details about affected domains when clicking on the icon.
Let me know if this approach would be acceptable for you.
chocolateboy
The bug was in a HTML parser and only affected web pages, but the addon currently checks headers for all resources.
This results in a non-Cloudflare page like http://stackexchange.com/, which is not affected, being flagged because it includes images from http://stack.imgur.com/, which are behind CF. The same will be true for any pages which include non-HTML resources from a CF-fronted site.