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

Issue 610188 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

Security: form submissions will not be upgraded from upgrade-insecure-requests

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

Issue description

VULNERABILITY DETAILS

Step to reproduce:

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

2. When I submit a form witch is "action" = http url, form submissions will not be upgraded.

Expected result:

I tested on Firefox nightly(49.0a1).

When I submit a form witch "action" = http url,  Firefox changed http to https. I think this is the solution.

W3C specification stated...

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

4.1. Upgrade request to a potentially secure URL, if appropriate

We will not upgrade cross-origin navigation requests, with the exception of form submissions. Form submissions will be upgraded to mitigate the risk of data leakage via plaintext submissions.

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

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

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

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

(I tested this html file on my local server.)


<!DOCTYPE HTML>
<head>
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
<title>upgrade test</title>
</head>
<body>

<h1>upgrade test</h1>

<form method="POST" action="http://vk.com">
 <div>name<input type="text" name="name"></div>
 <div>password<input type="text" name="password"></div>
 <input type="submit" value="submit">
 <input type="reset" value="reset">
</form>

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


 
I forgot to include </body> and </html> tags on last. Please allow me to post my test case html again. I am really sorry.

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

<!DOCTYPE HTML>
<head>
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
<title>upgrade test</title>
</head>
<body>

<h1>upgrade test</h1>

<form method="POST" action="http://vk.com">
 <div>name<input type="text" name="name"></div>
 <div>password<input type="text" name="password"></div>
 <input type="submit" value="submit">
 <input type="reset" value="reset">
</form>

</body>
</html>


Comment 2 by f...@chromium.org, May 9 2016

Components: Security Blink>SecurityFeature
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam OS-All Type-Bug
Owner: mkwst@chromium.org
Status: Available (was: Unconfirmed)
Thanks for the report! 

Triaging this as a security-related bug, rather than a vulnerability.

Mike, can you PTAL?
Project Member

Comment 3 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 4 by mkwst@chromium.org, May 11 2016

Status: Fixed (was: Available)

Sign in to add a comment