Open
Bug 891629
Opened 11 years ago
Updated 2 years ago
Blocking storage of HSTS data for third-party domains (when requested)
Categories
(Core :: Security, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: jbonneau, Unassigned)
Details
(Keywords: privacy)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36 Steps to reproduce: 1) Disable third-party cookies 2) Load a page firstparty.com which loads a resource from a third-party HSTS domain https://thirdparty.com 3) Attempt to access http://thirdparty.com Actual results: The HSTS pin set for thirdparty.com is retained, so the request is re-written to http://thirdparty.com Expected results: The HSTS pin should not have been stored since the user requested no third-party storage of data. This applies to other scenarios like blocking a specific site from setting cookies, or blocking all sites. The ability to set HSTS pins could potentially be used for tracking through the use of subdomains-a site can set up N subdomains https://1.example.com, https://2.example.com, etc. and then direct a user to a unique subset of these domains which will set HSTS pins with includeSubdomains set. The site can then direct users to load a resources from http://test.x.example.com for x in [1, N] and the loads will fail for domains which had HSTS pins set, recovering the a unique fingerprint from a set of 2^N possibilities... See https://bugzilla.mozilla.org/show_bug.cgi?id=648186, though the important point here is that HSTS data should not be stored for third-party domains or other situations where the user has requested not to have data stored which can be used for tracking...
Summary: HSTS → Blocking storage of HSTS data for third-party domains (when requested)
Updated•11 years ago
|
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•