Detecting cross-origin redirects using the performance API
Categories
(Core :: Performance, defect, P3)
Tracking
()
People
(Reporter: dattasohom1, Assigned: sefeng)
References
Details
(Keywords: privacy, sec-low, Whiteboard: [reporter-external] [client-bounty-form][post-critsmash-triage][adv-main100+])
Attachments
(3 files)
Found this while digging around while reporting a similar bug in Chrome. When advanced tracking protection is turned off, we can detect whether or not a cross-origin URL is a redirect using the difference of performance.getEntriesByName(...)[0].fetchStart - performance.getEntriesByName(...)[0].startTime
.
Reproduction steps:
- Download the attached index.html file.
- Run a python HTTP server by running
python -m http.server
in the same directory as the index.html file. - Open http://localhost:8000/index.html in Firefox
- Open the javascript console
- https://google.com should be correctly identified as a redirect, whereas, https://www.google.com should be identified as a URL without a redirect.
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 2•1 year ago
|
||
Not sure what you mean by "advanced tracking protection is turned off"... is that just a typo for "enhanced" (ETP is disabled for the site) or do you mean it happens in "Standard" ETP as opposed to "strict" (advanced?) ETP? Odds are the first, but it's good to be clear.
Please let us know the link to the Chromium issue. I'm sure we can't see it if you've filed it as a security bug, but it's handy to be able to tie the issues later and double-check.
Reporter | ||
Comment 3•1 year ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #2)
Not sure what you mean by "advanced tracking protection is turned off"... is that just a typo for "enhanced" (ETP is disabled for the site) or do you mean it happens in "Standard" ETP as opposed to "strict" (advanced?) ETP? Odds are the first, but it's good to be clear.
It was a typo for "Enhanced Tracking Protection" :)
That being said, I appear to have misinterpreted the following warning Request to access cookie or storage on “<URL>” was blocked because it came from a tracker and content blocking is enabled.
as the PoC not working. The exploit detects redirects with ETP enabled also. ETP is probably blocking 'credential': 'include'
in my index.html
PoC which caused the misunderstanding.
Please let us know the link to the Chromium issue. I'm sure we can't see it if you've filed it as a security bug, but it's handy to be able to tie the issues later and double-check.
https://bugs.chromium.org/p/chromium/issues/detail?id=1290150 is the bug (it is filed a security bug, yeah)
Comment 4•1 year ago
•
|
||
Chrome apparently landed a fix recently
https://chromium.googlesource.com/chromium/src/+/e96b9f57d8d9e32bf9cb748524735d7903271755%5E%21/
That includes also some changes to a wpt, so perhaps we have even a test for this.
Updated•1 year ago
|
Assignee | ||
Comment 6•1 year ago
|
||
Given the recent Fetch spec updates, Step 8.1 in
https://fetch.spec.whatwg.org/#finalize-and-report-timing specifies
that start time(StartTime) and post-redirect start time(FetchStart) should
be start time when TAO check fails.
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
![]() |
||
Comment 7•1 year ago
|
||
Make FetchStart uses StarTime when TAO check fails for PerformanceResourceTiming r=smaug
https://hg.mozilla.org/integration/autoland/rev/c02b29bea3fc334e7567776ea41a508eef74bdea
https://hg.mozilla.org/mozilla-central/rev/c02b29bea3fc
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 8•11 months ago
|
||
I tried to reproduce the issue on Firefox 98.0a1 (2022-01-24), and got this response:
- https://google.com/ is a redirect? index.html:10:25
- https://www.google.com/ is not a redirect
On the latest Beta, 100.0b8, with the steps from Comment 0, is displayed:
- https://google.com/ is not a redirect index.html:13:25
- https://www.google.com/ is not a redirect
From Comment 0, it doesn't look like the expected result. Is there anything that I'm missing, or is this the expected behavior?
Updated•11 months ago
|
Reporter | ||
Comment 9•11 months ago
|
||
(In reply to Mihai Boldan, QA [:mboldan] from comment #8)
I tried to reproduce the issue on Firefox 98.0a1 (2022-01-24), and got this response:
- https://google.com/ is a redirect? index.html:10:25
- https://www.google.com/ is not a redirect
On the latest Beta, 100.0b8, with the steps from Comment 0, is displayed:
- https://google.com/ is not a redirect index.html:13:25
- https://www.google.com/ is not a redirect
From Comment 0, it doesn't look like the expected result. Is there anything that I'm missing, or is this the expected behavior?
That is the expected behaviour (being unable to detect if a redirect has occured in the newer version)
Comment 10•11 months ago
|
||
Thanks Sohom Datta for the confirmation.
Based on the comments from above, I'm marking this issue as Verified Fixed.
Updated•11 months ago
|
Updated•11 months ago
|
Comment 11•11 months ago
|
||
Updated•11 months ago
|
Updated•11 months ago
|
Updated•7 months ago
|
Description
•