I modified the form tag in the page and found that if you remove the target="blank" attribute this resolves the problem.

<form action="https://www.paypal.com/cgi-bin/webscr" method="post" rel="noopener" role="form">
...
</form>

It does look like this is working in 63, and broken in 64 (up through Canary).

Arthur, this seems like it might be related to the `form-action` changes you made in relation to PlzNavigate? Would you mind triaging this?

+Andy as well

Since this is literally costing me money, I've just removed the target="blank" attribute. Just wanted to point that out in case someone wonders why they can't repro.

I can reproduce (Before you updated your website).

I think is it impossible my last change caused this. My last change removed one part blocking URL, it can only block less URLs than it used to do, not more.

I will take a look as soon as I have some time.

Ok, thanks. If it's not your change, then please reassign to Andy. :)

For what it worth:

* There is a form submission to "https://www.paypal.com/cgi-bin/webscr" targetting a new blank window.
* There are no redirects.
* The CSP is "form-action 'self' accounts.google.com www.paypal.com".
* The blocked URL is https://www.paypal.com/cgi-bin/webscr

I don't think the URL must be blocked by this policy. Maybe a regression in the renderer side URL <-> CSP matching algorithm? The browser side one is theoretically not called here because there are no redirects.

I would be happy to reassign this issue to Andy ;-)

I don't have it in front of me anymore, but I believe that the initial form submission results in a 302 redirect to a different page on `https://www.paypal.com/`, and that the enforcement would be on the browser-side. *shrug*

Andy, would you mind taking a look? Maybe this bug can hop back and forth between you two a bit. ;)

mkwst, you are right. That's a URL after https://www.paypal.com/cgi-bin/webscr that is blocked. So there is a redirect. Sorry about this.

Two things are stranges.
* It looks like the CSP matching algorithm on the browser side if wrong.
* It looks like the CSP of the calling frame are inherited by the navigating frame after about:blank.

I'm not sure, but an issue I reported earlier today might be relevant:  Issue #807207 

Is that issue behind a security flag, I can't view it?

Please add me to the cc list if it's relevant. 

arthursonzogni@

* Seeing that target="blank" avoids the issue it seems clear that there's a bug in the CSP matching on the server side.

* What do you mean after `about:blank`, the first request is a redirect right? Unless I'm missing something that seems like working as intended to me.

I have checked and confirmed that the issue has started occuring because of https://chromium-review.googlesource.com/c/chromium/src/+/765969 which fixed a bug where the content layer CSP did not inherit the CSP properly. I believe that the issue is in CSP matching algorithm and the only reason it worked before is because it did not inherit the CSP in the first place.

^ I meant there's a bug in the CSP matching on the BROWSER side not SERVER side. Bit tired today :D.

dragory.up@  I can't view the issue you mentioned either and I have permission to view security flagged issues.

 Issue 807207  has been merged into this issue.

Since the other issue was merged here, I'll post these here as well:

Example code to reproduce: https://gist.github.com/Dragory/a7b9215e56304890ab5ac5b841465c29
Live version: https://dragory.net/misc/csp-bug.php

Arthur, could you have a look at the form-action matching algorithm and see why it does not seem to behave properly?

Also the issue does not need bisection anymore

Yes, I will take a look today.

mkwst: Can you explain to me how CSP are inherited when a new window is created?
I think the new window is created with URL="about:blank" first. I think it uses CSP of its opener.
Then the window navigates and the CSP are updated to be the one of the loaded document.
Am I right?

Whenever a new document is created, if it has a local scheme (which includes the "about:" scheme) it inherits the CSP from it's parent/opener. When the document is replaced the CSP is replaced as well. And yes the new window URL is initially "about:blank" and then the navigation commits and the document is replaced.

So basically yes you are correct.

Thanks for the live example dragory@ (comment 16)! It is appreciated.

I took a look, this is more or less the same as  issue 798698 , but after the redirects.

If I revert...
https://chromium-review.googlesource.com/c/chromium/src/+/765969
... then it works.

Since this CL, CSP's are correctly inherited to the new window when it is on about:blank URL.
CSP are inherited but 'self' is not inherited. Hence the bug.
_______

An explanation for the two reproductions case:

# comment 16:
  * CSP = "form-action 'self'".
  * URL = "https://dragory.net/misc/csp-bug.php"
  * self = undefined

  Internally 'self' is undefined because no URL has been committed yet, we are temporarily on a blank page while the document loads. The page is blocked.

# comment 1:
  * CSP = "form-action 'self' accounts.google.com www.paypal.com".
  * URL =  "https://www.paypal.com/XXXXX"
  * self = undefined.

The URL is using the https scheme and the CSP source "www.paypal.com" doesn't one. The CSP source "www.paypal.com" could be upgraded to "https://www.paypal.com" if the 'self' source's scheme is 'http' or 'https'. The issue is that 'self' is not defined here, so no upgrade is possible.
_______

I can't disable checks like I did in the previous fix. I really need to define 'self', even before there is any document committed.

andypaicu@: Thanks! Our two messages crossed.

I see... this behaviour is currently correct according to the spec.

There are open issues now (https://github.com/w3c/webappsec-csp/issues/259, https://github.com/w3c/webappsec-csp/issues/248, https://github.com/w3c/webappsec-csp/issues/260) challenging the usefulness of the behaviour as defined so we probably have to wait until those are resolved.

I will move them up on my queue to get them solved on way or the other and then we can see if this is a Won'tFix or we will have to modify our matching algorithm to fit new spec changes.

Your patch is great Andy, there are no issues with it.
BTW: thanks for these links!

I am working on correctly setting 'self' before there are any document committed yet.

I plan to put in RenderFrameHostImpl constructor:
_______________________________________________________________________________
 |
1|// Content-Security-Policy: The CSP source 'self' is usually the origin of the
2|// last committed document. When they are still no committed document yet
3|// (i.e. immediatly after window.open()), 'self' is the origin of the opener.
4|if (FrameTreeNode* opener = frame_tree_node_->opener()) {
5|  CSPContext::SetSelf(opener->current_origin());
6|}
_|____________________________________________________________________________

I initially thought it would be very difficult to get the opener origin, but it turns out it is quite easy.
I will work on a patch and a set of tests.

arthursonzogni@, wanted to confirm, do we have any major impact on M64 stable roll out with this bug? Also the fix can wait for M65?

Thank you!

FYI: I am working on a fix here:
https://chromium-review.googlesource.com/c/chromium/src/+/895589

manoranjanr@:
> arthursonzogni@, wanted to confirm, do we have any major impact on M64 stable roll out with this bug? Also the fix can wait for M65?

I've been searching the internet for discussions about this bug. I haven't seen anything for the moment other than this report here.
Also I don't have access to  issue 807207 .
It would be weird if it didn't affect more people.

It happens when:
* A form submission use target="_blank"
* There is a redirect.
* |    one of the CSP source is 'self' 
  | or one of the CSP source doesn't specify the URL scheme (like http/https/ftp/...)

mkwst@ What do you think? M64 was released one week ago, can we wait 4 more weeks before releasing the fix?

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

commit 08357eedcc386b14bb39d06ed93c00b3cabb09d3
Author: arthursonzogni <arthursonzogni@chromium.org>
Date: Fri Feb 02 10:46:01 2018

CSP: initial blank page inherits 'self'.

Content-Security-Policy: The CSP source 'self' is usually the origin of
the current document. Immediately after an new window or new frame is
created, there are no current document. In this case, the origin used is
the one of the opener (in case of a new window) or the parent (in case of a
new iframe).

For you intention: The frame's CSP are already the one of its opener when
there are still no committed document. It makes sense to do the same
with 'self'.

Several web platform tests are added.

Bug:  807206 
Change-Id: I2acf66d9b6d63d4efb14370a4d0ff2206c943aeb
Reviewed-on: https://chromium-review.googlesource.com/895589
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534017}
[modify] https://crrev.com/08357eedcc386b14bb39d06ed93c00b3cabb09d3/content/browser/frame_host/render_frame_host_impl.cc
[add] https://crrev.com/08357eedcc386b14bb39d06ed93c00b3cabb09d3/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/form-action-src-allowed-target-blank.sub.html
[add] https://crrev.com/08357eedcc386b14bb39d06ed93c00b3cabb09d3/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/form-action-src-allowed-target-frame.sub.html
[add] https://crrev.com/08357eedcc386b14bb39d06ed93c00b3cabb09d3/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/form-action-src-redirect-allowed-target-blank.sub.html
[add] https://crrev.com/08357eedcc386b14bb39d06ed93c00b3cabb09d3/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/form-action-src-redirect-allowed-target-frame.sub.html
[add] https://crrev.com/08357eedcc386b14bb39d06ed93c00b3cabb09d3/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/support/post-message-to-opener.sub.html
[add] https://crrev.com/08357eedcc386b14bb39d06ed93c00b3cabb09d3/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/support/post-message-to-parent.sub.html

Bug was fixed by the last CL.

I am requesting a merge for M65.
M65 beta is today, So I also need to wait for it to be on Canary for 1 day and be verified.

Severity: medium. Some form submission are blocked even if they are white-listed.
Patch is simple (~4 lines). It shouldn't crash or regress something.

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Pls merge your change to M65 branch 3325 before 2:00 PM PT tomorrow, Monday (02/25/18) so we can pick it up for last dev release on Tuesday. Thank you.

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

commit c347a0ffe146268cc1ca0709c18051c5658bf16f
Author: arthursonzogni <arthursonzogni@chromium.org>
Date: Mon Feb 05 08:50:40 2018

CSP: initial blank page inherits 'self'.

Content-Security-Policy: The CSP source 'self' is usually the origin of
the current document. Immediately after an new window or new frame is
created, there are no current document. In this case, the origin used is
the one of the opener (in case of a new window) or the parent (in case of a
new iframe).

For you intention: The frame's CSP are already the one of its opener when
there are still no committed document. It makes sense to do the same
with 'self'.

Several web platform tests are added.

Bug:  807206 
Change-Id: I2acf66d9b6d63d4efb14370a4d0ff2206c943aeb
Reviewed-on: https://chromium-review.googlesource.com/895589
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#534017}(cherry picked from commit 08357eedcc386b14bb39d06ed93c00b3cabb09d3)
Reviewed-on: https://chromium-review.googlesource.com/901242
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#291}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/c347a0ffe146268cc1ca0709c18051c5658bf16f/content/browser/frame_host/render_frame_host_impl.cc
[add] https://crrev.com/c347a0ffe146268cc1ca0709c18051c5658bf16f/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/form-action-src-allowed-target-blank.sub.html
[add] https://crrev.com/c347a0ffe146268cc1ca0709c18051c5658bf16f/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/form-action-src-allowed-target-frame.sub.html
[add] https://crrev.com/c347a0ffe146268cc1ca0709c18051c5658bf16f/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/form-action-src-redirect-allowed-target-blank.sub.html
[add] https://crrev.com/c347a0ffe146268cc1ca0709c18051c5658bf16f/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/form-action-src-redirect-allowed-target-frame.sub.html
[add] https://crrev.com/c347a0ffe146268cc1ca0709c18051c5658bf16f/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/support/post-message-to-opener.sub.html
[add] https://crrev.com/c347a0ffe146268cc1ca0709c18051c5658bf16f/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/form-action/support/post-message-to-parent.sub.html

For what it's worth, this bug has broken a bunch of internal admin pages for Dropbox but no user facing pages.

(Though we've worked around the bug by adding https://www.dropbox.com to our form-action CSP, so this doesn't affect us anymore.)