New issue
Advanced search Search tips

Issue 901477 link

Starred by 7 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 16
Cc:
EstimatedDays: ----
NextAction: 2018-11-14
OS: Mac
Pri: 2
Type: Bug

Blocking:
issue 751996



Sign in to add a comment

"Origin Policy Error Interstitial" on every google.pl page

Reported by mic...@bentkowski.info, Nov 2

Issue description

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

Steps to reproduce the problem:
I use Chrome Canary (72.0.3599.0) with enable-experimental-web-platform-features flag turned on.

When I browsed today to google.pl, I started getting "Origin Policy Error Interstitial" error (screenshot attached) on every single page of https://google.pl. This doesn't happen on https://google.com or other country-specific TLDs. 

I am not sure what I did when it started.

Submitting the bug per Mike West's request: https://twitter.com/mikewest/status/1058421401701490688

What is the expected behavior?

What went wrong?
"Origin Policy Error Interstitial" is shown on every google.pl page on both incognito and non-incognito mode.

Did this work before? N/A 

Chrome version: 72.0.3599.0  Channel: canary
OS Version: OS X 10.14.0
Flash Version:
 
Zrzut ekranu 2018-11-2 o 18.44.42.png
83.9 KB View Download
Labels: Needs-Triage-M72
Owner: vogelheim@chromium.org
Status: Assigned (was: Unconfirmed)
vogelheim@: Mind taking a look? :)
For the record: it doesn't happen anymore.

It seems that Canary has updated in the meantime (now I have: 72.0.3601.0) and, well, no longer getting the error; google.pl works fine now.
Blocking: 751996
Labels: -Needs-Triage-M72 Build-Official
Status: Started (was: Assigned)
Very sorry about this, and thanks for the report. This should not have triggered (and a more meaningful error interstitial is in the works).

Apparently Michal is not alone: https://www.reddit.com/r/chrome/comments/9u0pxm/origin_policy_error_interstitial/

I'm presently confused in how this could have triggered in either case. I'm also confused why it would no longer reproduce, since none of the relevant code should have been touched in the past days. Investigating...


@Michal: Did you restart the browser before it stopped happening? If so, did you also happen to restart the browser while the bug kept occurring?
(I'm asking because this presently uses an in-memory cache which does not live across restarts; so I wonder whether that cache was corrupted.)
Doesn't reproduce locally, but that's maybe not surprising since the reporter reports it stopped happening there as well.
There were no changes to origin policy handling in the reported version range. 

There were several changes to parsing & handling of response headers in the general vicinity, although none of them look problematic or related to this case.
If I'm not wrong, I restarted the browser a few times before it stopped working. I probably wouldn't have reported the bug if restart had been enough to fix it.

I tried to remember what exactly I did to make it start happening but no luck so far.
Michal: Thank you. That does exclude one possible error cause. :)

My thoughts so far:


I tried to reproduce with:
- tip-of-tree, debug: no repro
- 72.0.3599.0, release: no repro (version from this report)
- 72.0.3595.2, release: no repro (version from Reddit post)

I'm still unsure how this triggered. I did check in all experiments that the 'origin policy' header is sent in the request, but in none of them did Chrome find one in the response.

There's a unit tests (browser test) to ensure that this doesn't trigger if the server doesn't reply with the right header.

Both reports have in common that the destination was a Google website. It is conceivable that the problem was on that end. (That's rather unlikely, but it would explain why it might be consistently observable and then consistently disappeared, without any applicable change in the code or by the user.)

Okay, so I did a little test. I run Chrome through a proxy and set the proxy to add a "Sec-Origin-Policy: 1" header to all HTTP responses. And then the "Origin Policy Error Interstitial" started to appear again. 

Interestingly, when I disabled adding the header, the error still happened since Chrome couldn't download https://www.google.pl/.well-known/origin-policy/1. 

So perhaps what originally happened was that Google servers added the header to responses for short time? I surely didn't use anything else that Google Search when it happened the first time.
Sorry for double post, but after some more tests, it seems that when a response with "Sec-Origin-Policy: 1" is cached, then the "Origin Policy Error Interstitial" could indeed survive the browser restart.
Thank you for investigating. Most of this is expected behaviour, though:

If a domain has advertised an Origin Policy (in the case of your later tests, via the proxy), then the browser is supposed to apply the policy until the domain removes it (with Sec-Origin-Policy: 0). That's one of the key features of Origin Policy: There have repeatedly been security issues where a domain forgot to apply their CSP on some pages (say, the 404 error page), and thus inadvertently left parts of their site open to attacks. Origin Policy is meant to provide a robust response to that, by ensuring that once the domain has declared its policy it will be applied to all requests on that domain. (The current implementation only caches this in-memory, which is why - currently - restarts are relevant.)


Your observations are 100% consistent with the server (inadvertently) advertising a policy and then not removing it again.

I'm honestly not very sure at this point, but I'm still leaning against that explanation: I couldn't find the header name anywhere in Google's source code; and they tend to experiment with new features on less important sub-domains first.

The other alternative I'm considering is that something in the header parsing in Chrome is/was broken, and the browser "found" a Sec-Origin-Policy header despite it not being there. 


Unfortunately, I'm so far not very successful in proving/disproving either case. The only good news is that I didn't find any additional mentions of "Origin Policy Error Interstitial" on the internet. :)

I just started seeing this for google.com searches in Version 72.0.3602.2 (Official Build) dev on Linux. I have the "Experimental Web Platform Features" flag enabled.

A browser restart has fixed it for me (for now, anyways), but a friend has been mentioning seeing this in the MacOS beta channel for the past few days on both google.com and google.ca.
I can reproduce this with all https://www.google.co.jp/search navigations in Version 72.0.3604.0 (Official Build) canary (64-bit) fe3741e1a9b3222dc9fef636d9ecafa9e093f254-refs/branch-heads/3604@{#1}

NetLog dump attached.


chrome-net-export-log.json
541 KB View Download
> a friend has been mentioning seeing this in the MacOS beta channel for the past few days on both google.com and google.ca.

I should have also mentioned that the place where I’ve run into this is macOS 
#13 + #14 + #15: Thanks for chiming in. It seems I was a bit too optimistic.

Double extra thanks for the netlog in #14. To me, that indeed looks like the server at some point echoes the sec-origin-policy: header (lines 1863 + 1864), which would be... weird.

I'll keep investigating...
The netlog contains the following QUIC_SESSION entry:

t=115700 [st=1834]    QUIC_CHROMIUM_CLIENT_STREAM_READ_RESPONSE_HEADERS
                      --> :status: 200
                          accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b2
                          accept-encoding: gzip, deflate, br,gzip(gfe)
                          accept-language: en-US,en;q=0.9,ja;q=0.8
                          alt-svc: quic=":443"; ma=2592000; v="44,43,39,35"
                          cache-control: max-age=0
                          content-encoding: br
                          content-length: 93582
                          content-type: text/html; charset=UTF-8
                          cookie: [976 bytes were stripped]
                          date: Thu, 08 Nov 2018 06:01:02 GMT
                          dnt: 1
                          expires: Thu, 08 Nov 2018 06:01:02 GMT
                          sec-metadata: cause=forced, destination=document, site=cross-site
                          sec-origin-policy: 1
                          server: gws
                          set-cookie: [89 bytes were stripped]
                          strict-transport-security: max-age=31536000
                          upgrade-insecure-requests: 1
                          user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3604.0 Safari/537.36,gzip(gfe)
                          x-client-data: CJa2yQEIorbJAQirncoBCLmdygEI4aXKAQiKp8oBCLCnygEIv6fKAQjsp8oBGPmlygE=
                          x-frame-options: SAMEORIGIN
                          x-xss-protection: 1; mode=block

To me it looks like the headers from Chrome's request were echoed back verbatim in the response.
I asked another dev (Thanks Adam!) to help me analyse the netlog. In the offending request (as well as other requests in the same log), it looks like some of the request headers are being erroneously copied into the response. For the sec-origin-policy: header that has the result of effectively locking down the site, observed here.

We can't currently determine whether this happens on the server, or on the network processing within Chrome.

Adam called this a "a fairly common mistake" :-] so I guess one consequence is that I'll change the origin policy request header to not be identical to the origin policy response header. (That would help here, but isn't the core of the issue.)
I'll change the request header to announce Origin Policy capability using the sentinel value for deleting a policy, to make sure that echoing request headers in the response won't cause a lock-down of the entire site. (crrev.com/c/1328982) This is a purely defensive measure and doesn't solve the underlying bug, bug based on Adam's assessment "a fairly common mistake" it's probably worth it. That should make the 'Origin Policy Error Interstitial' go away.


1, This is technically against the OP spec so I'll try to fix the spec, and/or track whatever other solution the spec ends up with. This will be tracked elsewhere, likely on the W3C WICG bug tracker.

2, I'll keep trying to fix the underlying problem but - if it turns out to be a server-side issue and outside of Chrome/Chromium - that work will be tracked elsewhere.
OP spec issue is tracked here: https://github.com/WICG/origin-policy/issues/40
Project Member

Comment 21 by bugdroid1@chromium.org, Nov 12

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

commit 5421fc28c90bd861efe078b397cc14af008fed78
Author: Daniel Vogelheim <vogelheim@chromium.org>
Date: Mon Nov 12 16:19:10 2018

[Origin Policy] Change request header default to "0".

Change the client header announcing OP capability to use the value "0". This
is meant to mitigate an apparently reasonably common bug where the header value
is blindly copied into the request (as observed in the referenced bug).

Bug: 751996,  901477 
Change-Id: I85c67cfdad3d15fc8e76e62bf1f84323faa1f790
Reviewed-on: https://chromium-review.googlesource.com/c/1328982
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607246}
[modify] https://crrev.com/5421fc28c90bd861efe078b397cc14af008fed78/content/browser/frame_host/origin_policy_throttle.cc
[modify] https://crrev.com/5421fc28c90bd861efe078b397cc14af008fed78/content/browser/frame_host/origin_policy_throttle_unittest.cc

Labels: Merge-Request-71
M71 merge request for #c21, per review comment here:
     https://groups.google.com/a/chromium.org/d/msg/chromium-reviews/1BwRj7GaQeQ/kY0Obc5iBQAJ

I'm unsure if this matches beta back-merge criteria. Here's the info I have on the bug & its fix:

- Stability risk: Should be minimal. It's only a one-line change in non-test code.

- Frequency of occurrence: Likely also low, since it requires a specific switch to be set (--enable-experimental-web-platform-features), but that one is fairly common among web developers.

- Severity if it occurs: If it occurs, it locks down the affected site completely until browser restart. This so far affects Google Search properties only; but Google Search is a fairly popular web page. Google Search is also the default search engine for Chrome, which makes this whole thing a tad embarrassing.


Cc: vogelheim@chromium.org
 Issue 904448  has been merged into this issue.
Addendum for Merge-Request-71: We've now got 4 independent reports within a few days.
NextAction: 2018-11-13
Pls update bug with canary result tomorrow.

Also is this M71 regression?
The NextAction date has arrived: 2018-11-13
Regression: Yes, this is a regression and did not occur on M70 (or earlier).

Canary result: n/a. The fix landed in 72.0.3609.0, which isn't out yet.
NextAction: 2018-11-14
Thank you,pls update bug with canary result tomorrow.
Project Member

Comment 29 by sheriffbot@chromium.org, Nov 13

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

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
The NextAction date has arrived: 2018-11-14
72.0.3609.* was apparently skipped, but 72.0.3610.0 is now in canary.
We have not received any new bug reports in that version.

A cursory look through crash reports suggests no observed crashers in related code, either. (Not sure how that version is generally doing.)

Labels: -Merge-Review-71 Merge-Approved-71
Approving merge to M71 branch 3578 based on comment #31. Pls merge ASAP if canary data continue to look good. Thank you.
Labels: -Merge-Approved-71 Merge-Merged-71-3578
The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/8c355c981eaec984dba844f43ab228308d62cc7a

Commit: 8c355c981eaec984dba844f43ab228308d62cc7a
Author: vogelheim@chromium.org
Commiter: vogelheim@chromium.org
Date: 2018-11-15 16:23:32 +0000 UTC

[Origin Policy] Change request header default to "0".

Change the client header announcing OP capability to use the value "0". This
is meant to mitigate an apparently reasonably common bug where the header value
is blindly copied into the request (as observed in the referenced bug).

Bug: 751996,  901477 
Change-Id: I85c67cfdad3d15fc8e76e62bf1f84323faa1f790
Reviewed-on: https://chromium-review.googlesource.com/c/1328982
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#607246}(cherry picked from commit 5421fc28c90bd861efe078b397cc14af008fed78)
Reviewed-on: https://chromium-review.googlesource.com/c/1338103
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#690}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
Project Member

Comment 34 by bugdroid1@chromium.org, Nov 15

Labels: merge-merged-3578
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8c355c981eaec984dba844f43ab228308d62cc7a

commit 8c355c981eaec984dba844f43ab228308d62cc7a
Author: Daniel Vogelheim <vogelheim@chromium.org>
Date: Thu Nov 15 16:23:32 2018

[Origin Policy] Change request header default to "0".

Change the client header announcing OP capability to use the value "0". This
is meant to mitigate an apparently reasonably common bug where the header value
is blindly copied into the request (as observed in the referenced bug).

Bug: 751996,  901477 
Change-Id: I85c67cfdad3d15fc8e76e62bf1f84323faa1f790
Reviewed-on: https://chromium-review.googlesource.com/c/1328982
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#607246}(cherry picked from commit 5421fc28c90bd861efe078b397cc14af008fed78)
Reviewed-on: https://chromium-review.googlesource.com/c/1338103
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#690}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/8c355c981eaec984dba844f43ab228308d62cc7a/content/browser/frame_host/origin_policy_throttle.cc
[modify] https://crrev.com/8c355c981eaec984dba844f43ab228308d62cc7a/content/browser/frame_host/origin_policy_throttle_unittest.cc

Status: Fixed (was: Started)
The fix should be in M71 beta (>= 71.0.3578.58, not out yet) and M72 dev (>= 72.0.3609.0). If the "Origin Policy Error Interstitial" re-occurs in any of those fixed versions, please re-open this bug.

Future spec changes are tracked on GitHub, per comment 20.

The root cause appears to be the server erroneously copying request headers into the response. I'm working with other devs to fix that, but so far with nothing to show for.

Marking this as 'fixed', since from Chromium's perspective it should be.
Cc: clamy@chromium.org carlosil@chromium.org
 Issue 906907  has been merged into this issue.
Cc: viswa.karala@chromium.org iclell...@chromium.org
 Issue 906655  has been merged into this issue.
I saw this yesterday for google.dk and google.de but not for google.no
#38: Kenneth:
- Was this a beta version?
  (The current M71 Beta is still on 71.0.3578.44 and thus still affected. The next beta release should contain the client-side fix.)
- Do you have --enable-experimental-web-platform-features (or an equivalent chrome://flags/ setting) enabled?

On "for google.dk and .de, but not .no": The error occurs non-deterministally, maybe every 1 in 10 searches. But once the error condition has been hit, the interstitial will show 100% of the time (until the next restart).

(The server-side issue is, unfortunately, not yet resolved.)
Current beta is now 71.0.3578.62 (on most platforms), which should mitigate this issue.
Project Member

Comment 41 by bugdroid1@chromium.org, Nov 29

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

commit c0162c1b508aadbf4b98d39793e68e681db6b028
Author: Daniel Vogelheim <vogelheim@chromium.org>
Date: Thu Nov 29 10:35:16 2018

[Origin Policy] Updated, less flippant Origin Policy Interstitial text.

Bug: 751996,  901477 
Change-Id: Ia150dc83158bae7db8160bddf0377328ff1b2b11
Reviewed-on: https://chromium-review.googlesource.com/c/1344131
Reviewed-by: Carlos IL <carlosil@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#612133}
[modify] https://crrev.com/c0162c1b508aadbf4b98d39793e68e681db6b028/chrome/test/origin_policy/origin_policy_browsertest.cc
[modify] https://crrev.com/c0162c1b508aadbf4b98d39793e68e681db6b028/components/security_interstitials/core/browser/resources/interstitial_origin_policy.html

IS CL listed at #41 need a merge to M71?
#42: No, I think not. With the back-merged fixes, users shouldn't be seeing the message under any reasonable circumstances, and so far I haven't been getting any reports to the contrary.

I assigned that CL to this bug since it is a consequence from it, but a low(er) urgency consequence.
OK, thank you.

Sign in to add a comment