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

Issue 610441 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Buried. Ping if important.
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Security



Sign in to add a comment

Security: Upgrade-Insecure-Requests does not perform Navigational Upgrades

Reported by kamikaze.takashi111@gmail.com, May 9 2016

Issue description

DETAILS

Missing spec on Upgrade Insecure Requests(Navigational Upgrades)

Step to reproduce:

1. Go to page which is enabled  "Content-Security-Policy: upgrade-insecure-requests"

2. When a user clicks a http link, chrome will not treat a http link as "https" link.

Expected result:

When a user clicks a http link, chrome will change a http url to https url.


W3C specification has an example....

--------------------------------------

Navigational Upgrades

Megacorp, Inc. isn't quite ready to deliver Strict Transport Security headers [RFC6797], but does want to keep users on secure pages when possible. Happily, this comes for free with upgrade-insecure-requests. That is, they're already delivering pages with the following header: 

Content-Security-Policy: upgrade-insecure-requests


This allows user agents to treat the following HTML code:

<a href="http://example.com/">Home</a>

as though it had been delivered as:

<a href="https://example.com/">Home</a>


Source: http://www.w3.org/TR/upgrade-insecure-requests/#example-navigation


3. Authors should be able to ensure that all internal links correctly send users to the site's secure address, and not to its pre-migration insecure address.

Source:http://www.w3.org/TR/upgrade-insecure-requests/#goals


----------------------------------------------

VERSION
Chrome Version: [50.0.2661.94] + [stable]
Operating System: [Ubuntu 14.04 LTS 64 bit]


I uploaded my poc video to google drive. Please watch it.

https://drive.google.com/open?id=0B5EL3NI3hlsSNlN6V0pyVTRoZ1U

 
Cc: mkwst@chromium.org
Components: Blink>SecurityFeature
Live repro: https://fiddlerbook.com/test/csp/

Version 52.0.2729.1
Status: Untriaged (was: Unconfirmed)
Also repros in Firefox 46.0.1
I have already reported Mozilla security team. They said "this is indeed a bug we should fix." 
Summary: Security: Upgrade-Insecure-Requests does not perform Navigational Upgrades (was: Security: Missing spec on Upgrade Insecure Requests(Navigational Upgrades))
#610188 likely shares the same root cause.

Comment 5 by mkwst@chromium.org, May 10 2016

Cc: -mkwst@chromium.org elawrence@chromium.org
Owner: mkwst@chromium.org
Status: Started (was: Untriaged)
Hrm. The code at https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp&l=678 is supposed to handle this case. Of course, I apparently didn't write tests for it, so this probably regressed in some recent refactoring. :/

Comment 6 by f...@chromium.org, May 10 2016

Labels: Security_Severity-Low Security_Impact-Stable Pri-2
Thanks for the report!

Mike- I'm torn between whether this should be labeled low-severity or just a regular bug related to severity. I'll err on the side of caution and mark it as low-severity for now; please feel free to remove the view restriction if you want.

Comment 7 by mkwst@chromium.org, May 10 2016

Since the impact on HTTPS sites is that the frame isn't loaded (it's blocked as mixed content), I'd suggest that there's little practical risk from a security perspective. There's some more substantial risk from the "Hey, why isn't this doing the thing that I, the developer, asked it to do!", of course.
Bounty reward will not be paid on severity-low.  My question is...Will severity-low bug be eligible for hall of fame? 
Re: #7-- it's true that a same-domain subframe would get blocked as mixed-content, but this bug is broader than that as it also applies to top-level navigations to same-domain sites. Those top-level navigations would not be blocked and take place over a non-secure channel. 
Project Member

Comment 10 by bugdroid1@chromium.org, May 11 2016

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

commit 06d6974d6903554b04ce7e4eaf7a007ad0455f1e
Author: mkwst <mkwst@chromium.org>
Date: Wed May 11 09:57:02 2016

UPGRADE: Correctly handle navigations.

The behavior of 'upgrade-insecure-requests' has regressed for iframes and
navigations due to some recent changes in those bits of the loader. Of
course, I was an idiot, and didn't write layout tests for those pieces,
but relied on unit tests. The unit tests kept working, because they hard
coded the expected inputs! Hooray! The web, however, broke. Bleh.

This patch adjusts things such that iframes and navigations are correctly
upgraded in the presence of the directive.

As a drive-by, it also disables the mixed content warning that we show for
insecure form actions on secure pages if upgrading is active (as part of
the UIR promise is that we won't break your security indicators).

BUG= 610441 , 610188 

Review-Url: https://codereview.chromium.org/1964303003
Cr-Commit-Position: refs/heads/master@{#392890}

[add] https://crrev.com/06d6974d6903554b04ce7e4eaf7a007ad0455f1e/third_party/WebKit/LayoutTests/http/tests/security/resources/post-origin-to-parent.html
[add] https://crrev.com/06d6974d6903554b04ce7e4eaf7a007ad0455f1e/third_party/WebKit/LayoutTests/http/tests/security/upgrade-insecure-requests/form-upgrade.html
[add] https://crrev.com/06d6974d6903554b04ce7e4eaf7a007ad0455f1e/third_party/WebKit/LayoutTests/http/tests/security/upgrade-insecure-requests/iframe-upgrade.https.html
[modify] https://crrev.com/06d6974d6903554b04ce7e4eaf7a007ad0455f1e/third_party/WebKit/Source/core/html/HTMLFormElement.cpp
[modify] https://crrev.com/06d6974d6903554b04ce7e4eaf7a007ad0455f1e/third_party/WebKit/Source/core/loader/FormSubmission.cpp
[modify] https://crrev.com/06d6974d6903554b04ce7e4eaf7a007ad0455f1e/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp

Comment 11 by mkwst@chromium.org, May 11 2016

Status: Fixed (was: Started)
Hopefully fixed. Thanks for the report!
Project Member

Comment 12 by sheriffbot@chromium.org, May 11 2016

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Will this report be listed on Honorable mention? If so, please use "Takashi Suzuki" as reporter's name. This issue has been "restricted" for a while.
Labels: M-52 Release-0-M52
Project Member

Comment 15 by sheriffbot@chromium.org, Aug 17 2016

Labels: -Restrict-View-SecurityNotify
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
Project Member

Comment 16 by sheriffbot@chromium.org, Oct 1 2016

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
Project Member

Comment 17 by sheriffbot@chromium.org, Oct 2 2016

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
Labels: allpublic

Sign in to add a comment