Issue metadata
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 descriptionDETAILS 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
,
May 9 2016
Also repros in Firefox 46.0.1
,
May 9 2016
I have already reported Mozilla security team. They said "this is indeed a bug we should fix."
,
May 10 2016
#610188 likely shares the same root cause.
,
May 10 2016
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. :/
,
May 10 2016
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.
,
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.
,
May 10 2016
Bounty reward will not be paid on severity-low. My question is...Will severity-low bug be eligible for hall of fame?
,
May 10 2016
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.
,
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
,
May 11 2016
Hopefully fixed. Thanks for the report!
,
May 11 2016
,
Jun 7 2016
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.
,
Jul 20 2016
,
Aug 17 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
,
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
,
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
,
Oct 2 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, May 9 2016Components: Blink>SecurityFeature