New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 797465 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 9
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac
Pri: 1
Type: Bug-Security



Sign in to add a comment

Referrer Policy bypass using Navigation Timing API

Reported by s.h.h.n....@gmail.com, Dec 23 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36

Steps to reproduce the problem:
1. Go to https://vuln.shhnjk.com/noref_nav.html

What is the expected behavior?
Referrer is not leaked.

What went wrong?
Referrer is indeed not leaked, but Navigation Timing API holds previous URL when redirected, which defeats Referrer Policy.

Did this work before? N/A 

Chrome version: 63.0.3239.108  Channel: stable
OS Version: OS X 10.13.2
Flash Version:
 
Cc: est...@chromium.org
Components: Blink>PerformanceAPIs>NavigationTiming
Labels: Security_Impact-Stable OS-Android OS-Chrome OS-iOS OS-Linux OS-Windows
Interesting, thanks for the report. 
Labels: M-65 Security_Severity-Low
Real world example:
Login to flickr (login.yahoo.com has "Referrer Policy: origin-when-cross-origin"), and then type following to the console.

>document.referrer
"https://login.yahoo.com/"

>performance.getEntriesByType("navigation")[0].toJSON().name
"https://login.yahoo.com/account/challenge/password?done=https%3A%2F%2Fapi.login.yahoo.com%2Foauth2%2Frequest_auth%3Fclient_id%3Ddj0yJmk9NTJmMkVmOFo3RUVmJmQ9WVdrOVdXeGhVMWx3TjJFbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD01OA--%26redirect_uri%3Dhttps%253A%252F%252Fwww.flickr.com%252Fsignin%252Fyahoo%252Foauth%252F%253Fredir%253Dhttps%25253A%25252F%25252Fwww.flickr.com%25252F%26response_type%3Dcode%26scope%3Dopenid%252Csdpp-w%26nonce%3Dc89cbe1f1b[reducted]caeb85fe7d9%26.scrumb%3D0&src=oauth2&crumb=Vc9W[reducted]n8&redirect_uri=https%3A%2F%2Fwww.flickr.com%2Fsignin%2Fyahoo%2Foauth%2F%3Fredir%3Dhttps%253A%252F%252Fwww.flickr.com%252F&authMechanism=primary&display=login&yid=[reducted]&sessionIndex=QQ--&acrumb=zDP[reducted]YZ"

And Navigation Timing API leak has some more strength.
1. It can contain hashes.
2. Redirect status code URL can be retained.

PoC without Referrer Policy
https://test.shhnjk.com/location.php?url=//shhnjk.com/#test

>document.referrer //referrer doesn't catch redirect URL
""

>performance.getEntriesByType("navigation")[0].toJSON().name
"https://test.shhnjk.com/location.php?url=//shhnjk.com/#test"


I think this is Medium, per https://chromium.googlesource.com/chromium/src/+/master/docs/security/severity-guidelines.md ("A bug that allows an attacker to reliably read or infer browsing history").
Status: Available (was: Unconfirmed)
Reproduction confirmed in M63 to M65. 

In terms of severity, the Guidelines around allowing the "attacker to reliably read or infer browsing history" might be better stated as "allowing the attacker to reliably read or infer browsing history beyond what is normally exposed by the web platform." Because referrers are, by default, sent from HTTPS sites to HTTPS sites, the only scenarios impacted by this are those where the site is using Referrer Policy to disable the default behavior.
>Because referrers are, by default, sent from HTTPS sites to HTTPS sites, the
>only scenarios impacted by this are those where the site is using Referrer
>Policy to disable the default behavior.

This is totally different from referrer, so it will leak previous URL even if redirect is from HTTPS to HTTP.

PoC
https://test.shhnjk.com/location.php?url=http://shhnjk.com/#test

>performance.getEntriesByType("navigation")[0].toJSON().name
"https://test.shhnjk.com/location.php?url=//shhnjk.com/#test"

Available for 2 months :(
Cc: igrigo...@chromium.org
Owner: tyoshino@chromium.org
Assigning to tyoshino@ for triage.
Project Member

Comment 8 by sheriffbot@chromium.org, Feb 20 2018

Status: Assigned (was: Available)
Labels: -Security_Severity-Low Security_Severity-Medium
Sorry for the delay, OP.

I'm bumping this up to Severity Medium here; exposure of the URL from HTTPS to HTTP contexts is bad and exposure of the URL Fragment certainly seems very bad (due to the risk of token leaks, etc).
Project Member

Comment 10 by sheriffbot@chromium.org, Feb 21 2018

tyoshino: Uh oh! This issue still open and hasn't been updated in the last 60 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 11 by sheriffbot@chromium.org, Feb 21 2018

Labels: -Pri-2 Pri-1
Cc: kinuko@chromium.org
Project Member

Comment 13 by sheriffbot@chromium.org, Mar 7 2018

tyoshino: Uh oh! This issue still open and hasn't been updated in the last 74 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: -kinuko@chromium.org
Owner: kinuko@chromium.org
Assigning to kinuko@ for triage.
In PerformanceNavigationTiming we initialize PerformanceResourceTiming with ResourceTimingInfo::InitialURL(), while we probably need to set the final response URL.

 https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/timing/PerformanceNavigationTiming.cpp?sq=package:chromium&l=24
Owner: npm@chromium.org
Thanks for the details.

npm@ will be back shortly, assigning to him.
Yes, that makes sense. I think there is an easy fix for this. Just to be clear, for the example using https://test.shhnjk.com/location.php?url=//shhnjk.com/#test the output of performance.getEntriesByType("navigation")[0].toJSON().name should be 'https://shhnjk.com/#test', right?
Hmm actually my change breaks the resource-timing layout tests because the navigation and resource timing URLs are calculated in the same place. The ResourceTiming spec [1] says that the |name| is the URL from the resource request, even if the fetch causes a redirect. And in the NavigationTiming spec [2] the |name| is computed in step 11 but updated if the redirect occurs. So they are supposed to calculate |name| differently. Ilya, can you confirm this?  

[1] https://w3c.github.io/resource-timing/#sec-performanceresourcetiming
[2] https://w3c.github.io/navigation-timing/#processing-model
I suspect this will pass the bots because there's no tests for the |name| of navigation timing.
https://chromium-review.googlesource.com/c/chromium/src/+/996579
> Hmm actually my change breaks the resource-timing layout tests because the navigation and resource timing URLs are calculated in the same place. The ResourceTiming spec [1] says that the |name| is the URL from the resource request, even if the fetch causes a redirect. And in the NavigationTiming spec [2] the |name| is computed in step 11 but updated if the redirect occurs. So they are supposed to calculate |name| differently. Ilya, can you confirm this? 

Yes, I believe that's correct. The difference here is that in NavTiming we don't want to leak the previous URL that led to the current page. In RT, the site knows the original URL and needs to lookup the timing based on that, not on the post-redirect URL (which it doesn't know).. perhaps there should be a "final url" field, but that's a separate discussion.

As such, current fix fixes one thing but breaks another. :(
Per my CL in #19 we can set the response Url just for PerformanceNavigationTiming, which won't affect ResourceTiming. I'll just need to add a test for the |name| attribute of navigation.
Project Member

Comment 22 by bugdroid1@chromium.org, Apr 6

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/87e204e0aaf7445afbd0d50af6849d857517ae70

commit 87e204e0aaf7445afbd0d50af6849d857517ae70
Author: Nicolas Pena <npm@chromium.org>
Date: Fri Apr 06 14:46:02 2018

Fix the |name| of PerformanceNavigationTiming

Previously, the |name| of a PerformanceNavigationTiming entry was the initial
URL (the request URL). After this CL, it is the response URL, so for example
a url of the form 'redirect?location=newLoc' will have 'newLoc' as the |name|.

Bug:  797465 
Change-Id: Icab53ad8027d066422562c82bcf0354c264fea40
Reviewed-on: https://chromium-review.googlesource.com/996579
Reviewed-by: Yoav Weiss <yoav@yoav.ws>
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548773}
[modify] https://crrev.com/87e204e0aaf7445afbd0d50af6849d857517ae70/third_party/WebKit/LayoutTests/external/wpt/navigation-timing/nav2_test_redirect_server.html
[modify] https://crrev.com/87e204e0aaf7445afbd0d50af6849d857517ae70/third_party/WebKit/Source/core/timing/PerformanceNavigationTiming.cpp

Status: Fixed (was: Assigned)
Marking as Fixed per the test in #5
Project Member

Comment 24 by sheriffbot@chromium.org, Apr 10

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-unpaid reward-500
*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************
Thanks for the report! The VRP panel decided to award $500 for this. Cheers!
Thanks awhalley@!
I would love to hear your comment on https://bugs.chromium.org/p/chromium/issues/detail?id=821640#c11 if possible.

Thanks!
Labels: -reward-unpaid reward-inprocess
Labels: -M-65 Release-0-M67 M-67
Labels: CVE-2018-6134 CVE_description-missing
Project Member

Comment 32 by sheriffbot@chromium.org, Jun 8

Labels: Merge-Request-68
Project Member

Comment 33 by sheriffbot@chromium.org, Jun 8

Labels: -Merge-Request-68 Hotlist-Merge-Review Merge-Review-68
This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Hotlist-Merge-Review -M-67
Looks like adding the milestone prompts the bot to request a merge even if it is not needed. This is already in M67.
Labels: -Merge-Review-68 M-67
Project Member

Comment 36 by sheriffbot@chromium.org, Jul 17

Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment