629094 - Block Abuse of HTTP Status Codes to Expose Private Information (original) (raw)
Open Bug 629094 Opened 14 years ago Updated 2 years ago
Block Abuse of HTTP Status Codes to Expose Private Information
Categories
(Core :: DOM: Core & HTML, enhancement)
Tracking
()
| Webcompat Priority | | | ---------------------- | | | Performance Impact | | | a11y-review | | | Accessibility Severity | | | Webcompat Score | |
| Tracking | Status | | | ------------------- | ------ | | | relnote-firefox | | | | thunderbird_esr115 | | | | thunderbird_esr128 | | | | firefox-esr115 | | | | firefox-esr128 | | | | firefox132 | | | | firefox133 | | | | firefox134 | | |
People
(Reporter: david, Unassigned)
Reset Assignee to default
References
()
Details
Bug Flags:
| | behind-pref | | | | | ------------------ | | | | | | firefox-backlog | | | | | | sec-bounty | | | | | | sec-bounty-hof | | | | | | in-qa-testsuite | | | | | | in-testsuite | | | | | | qe-verify | | | |
Crash Data
Security
(public)
This bug is publicly visible.
User Story
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 Build Identifier: The problem is detailed at the cited Web page. Effectively, the page's author (Mike Cardwell) has developed a technique to allow the host of a Web site to determine if a visitor to that site is also logged-on to another site. Cardwell states: "When you visit my website, I can automatically and silently determine if you're logged into Facebook, Twitter, GMail and Digg. There are almost certainly thousands of other sites with this issue too, but I picked a few vulnerable well known ones to get your attention. You may not care that I can tell you're logged into GMail, but would you care if I could tell you're logged into one or more porn or warez sites? Perhaps http://oppressive-regime.example.org/ would like to collect a list of their users who are logged into http://controversial-website.example.com/?" His test page correctly determined whether I was logged-in to GMail, Twitter, and Facebook. Reproducible: Always With the attention being given to user privacy (e.g., do not track in bug #628197, reducing the UA string fingerprint in bug #572650), this too should be a priority.
> The problem is detailed at the cited Web pageHad the author not removed all the comments you would have seen my comments on his blog... For images, his attack is overcomplicated and unnecessary. You can just directly detect whether the image is there or not. "Fixing" this means disallowing cross-site linking of images, period. For scripts, we should think about what to do here, but chances are that once again the only fix would be to disallow cross-site linking of scripts completely. Neither is really an option due to the number of sites that would break. None of this has anything to do with networking. I urge you to contact GMail, Twitter, and Facebook and get them to fix their servers to not leak this information, by the way!
Component: Networking → DOM
QA Contact: networking → general
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
(In reply to comment #1) [...]> I urge you to contact GMail, Twitter, and Facebook and get them to fix their > servers to not leak this information, by the way!IIUC, Google replied that it was "expected behaviour". Don't know about the others.
It's expected behavior for the _browser_, sure. As in "Browsers are expected to load images, even when linked cross-site". Nothing says gmail needs to allow cross-site linking to its images, however.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.