Issue metadata
Sign in to add a comment
|
Sec-Metadata header causing issues with some sites
Reported by
limenet...@gmail.com,
Jul 9
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3472.3 Safari/537.36 Example URL: https://www.sbb.ch/ Steps to reproduce the problem: 1. Load e.g. https://www.sbb.ch/ 2. Redirected to a "400 Bad Request" page 3. Use other browser to access site What is the expected behavior? Site should load as usual What went wrong? A few weeks ago, I started to encounter problems when loading prominent web sites in Switzerland, such as the federal railways https://www.sbb.ch/, the 3D-Secure site for the bank UBS https://3dsec.cardcenter.ch, or even the government's website where they post notices for military training exercises https://www.vtg.admin.ch/content/vtg-internet/de/aktuell/mitteilungen/schiessanzeigen.zensa_detail.html/4202.010.html Instead of loading content as normal, these websites would redirect me to a 400 Bad Request page, e.g. https://www.sbb.ch/errors/400.html?al_req_id=W0MhpKwc5-kAASthtt4AAASI or https://www.vtg.admin.ch/error_path/400.html?al_req_id=W0Mg0sCouiIAADLtPVoAAABj At first, I assumed the federal railways (sbb.ch) had troubles with their infrastructure (happens every now and then) but then I encountered the same error when tying to authorize a credit card payment using 3D-Secure through https://3dsec.cardcenter.ch [URL redacted] Since switching to Incognito mode didn't change the result (still getting a 400 Bad Request immediately due to a 303 See Other) and all of the URLs would work fine using Firefox or Edge on the same computer or Chrome 67 in the same network yet on a different machine, I started to think the bug was related to Chrome 69 (and not due to an extension, being blocked etc.). I then proceeded to copy the request from the Network tab in the DevTools: curl 'https://sbb.ch/' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3472.3 Safari/537.36' -H 'Sec-Metadata: cause="forced", destination="document", target="top-level", site="cross-site"' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: en-US,en;q=0.9,de-CH;q=0.8,de;q=0.7' -H 'Cookie: AL_SESS-S=ATFIEtJdvGG0cJYA!WWcQU8Pj1X7jGci!MU0SjXzwMz0gCaI_Vb0Z_hvvw6q6rn4dmud' --compressed After deleting the headers one-by-one and then adding them back, I was able to narrow it down to the single Sec-Metadata header added recently to Chrome/Chromium: https://groups.google.com/a/chromium.org/forum/#!topic/Blink-dev/tNwA_l_o9lc https://bugs.chromium.org/p/chromium/issues/detail?id=843478 https://www.chromestatus.com/feature/5155867204780032 In other words, a number of (big) sites are having troubles with the new Sec-Metadata header and return a 400 Bad Request completely preventing users from accessing these sites. This bug can be reproduced by running: curl 'https://sbb.ch/' -H 'Sec-Metadata: cause="forced", destination="document", target="top-level", site="cross-site"' Since the 400 Bad Reuqest URLs mentioned previously all contain the query parameter al_req_id, they all seem to be using the same (reverse) proxy / web server. A quick search led me to https://github.com/SpiderLabs/owasp-modsecurity-crs but this is just a hunch. I realize I might be posting this in the wrong place and it is not a Chrome/Chromium bug per se, so please let me know if I should post it somewhere else. Let me know if you need anything! Did this work before? Yes 68 Chrome version: 69.0.3472.3 Channel: dev OS Version: 10.0 Flash Version:
,
Jul 9
I tried to find out more about al_req_id and it turns out to be a simple Apache Log request ID and may or may not have anything to do with ModSecurity/owasp-modsecurity-crs. A few days ago, I notified sbb.ch about this problem and also sent this link today, but haven't heard anything from them yet. I'll try to find other examples and notify the companies (and point them to this issue) hoping to find out what's causing this issue.
,
Jul 9
,
Jul 9
Interesting, this is helpful feedback! First, note that the header should be behind the "Experimental Web Platform Features" flag (chrome://flags/#enable-experimental-web-platform-features). Turning that off should allow you to browse normally. Second, the behavior is strange. With the example you've given, any one key-value pair works fine (`Sec-Metadata: abc="efg"`), but multiple key-value pairs returns a 400 (`Sec-Metadata: abc="efg", hij="klm"`). That happens for any header (at least, any I spot-checked). This might be a problem for Structured Headers in general. I'll poke mnot@.
,
Jul 9
Glad I was able to provide helpful feedback! Thank you for the flag! I wasn't aware of what led to the change and I've reverted it back so I can avoid this issue for the time being. I've notified the affected 3dsec.cardcenter.ch hoping they'd be able to provide some insight into what is causing this issue on their side. This is the first time I've encountered a Structured Header and it definitely piqued my curiosity!
,
Jul 10
Unable to reproduce the issue on chrome reported version# 69.0.3472.3 using Windows-10 with steps mentioned below: 1) Launched chrome reported version and navigated to URL: https://www.sbb.ch/ 2) Page got loaded successfully without any issues. @Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triagign it. Thanks!
,
Jul 10
@viswa.karala Thank you for your feedback. As per https://bugs.chromium.org/p/chromium/issues/detail?id=861678#c4 this behavior is due to a flag set to "enabled": > First, note that the header should be behind the "Experimental Web Platform Features" flag (chrome://flags/#enable-experimental-web-platform-features). Could you please try to reproduce the bug with this flag enabled?
,
Jul 10
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 10
This does not need triage or bisecting. The issue is clear: some specific servers don't like the header format of an as-yet-unshipped feature. This isn't a Chrome bug, it's an issue we'll need to resolve in the HTTP WG as the Structured Headers proposal works its way through the process. I'll leave this open to track that conversation, but there's nothing concrete we're going to do about it right this moment.
,
Jul 10
OK, this is really weird. It does feel like a WAF of some kind, so I tried vanilla ModSecurity with the OWasp rules out of the box, but that header didn't trigger anything suspicious. Will chat with some folks there just to make sure. I can only get to sbb.ch and vtg.admin.ch; the other site gives me a 403 for everything. Those two sites have very similar forms of redirection when this happens: "<html><body>Please follow <a href="/errors/400.html?al_req_id=W0RP6qwc5-kAAVuKQdIAAAPb">this link</a></body></html>" I don't see that precise form of redirect body message in ModSecurity, modsecurity-apache or Apache httpd source. Narrowing down what triggers it, it seems like this is the minimal case for sbb.ch: > curl 'https://sbb.ch/' -H 'Foo: a="b", c="d"' If you do any of the following, it won't trigger: * remove either of the parameters (including its value) * remove either parameter's value (e.g., bare a or a=) * Remove the quotes around "b" * Remove *all* of the double-quotes For vtg.admin.ch, it's this (note that it appears to be server-wide): > curl 'https://www.vtg.admin.ch/' -H 'Foo: a="b", target="1"' Here, if you do any of the following, it won't trigger: * Remove the "a" parameter and value * remove either parameter's value (e.g., bare a or a=) * Remove the quotes around "b" * Rename "target" to anything else (including "starget" or "targets") * Remove *all* of the double-quotes * Remove the space after the comma So that feels like these are similar but not exactly same regexes looking for particular parameters on *all* request headers (or at least unrecognised ones). Given that they're both Swiss state institutions, it might be that they've got a common vendor. I'll dig in a bit more, there are a few more things I want to look at here.
,
Jul 10
A friend with more Swiss context than I have says that they're pretty separate sites, and SBB isn't part of the government. I'm going to kick off a small-scale scan (maybe top 50,000 sites) to get a sense of how common this is.
,
Jul 16
I'm making some progress, and have identified a handful of other sites affected. They're almost all in Switzerland (and a few in Oman), so the suspicion of a Swiss vendor seems like a good lead. Am chasing a few different leads to find if there's a common culprit.
,
Jul 16
I remember having similar issues (as with sbb.ch) with their French counterpart, sncf.com (and related sites, such as oui.sncf). Unfortunately, I currently can't verify this, but maybe it helps finding the culprit.
,
Jul 19
Hi The problem with this header is that Airlock (https://www.ergon.ch/de/angebot/airlock) currently blocks these kind of requests. Both Websites (sbb.ch and 3dsec.cardcenter.ch) use this product which can be verified due to the "AL_SESS-S" Cookie you see in these requests. Airlock currently blocks the requests in his default configuration: - "(default HTML_004b) Known HTML attribute in quoted context in HTTP header value" was triggered by header "Sec-Metadata: cause=forced, destination="", target=subresource, site=same-origin" - th:BLOCK , violated deny rule "(default HTML_004b) Known HTML attribute in quoted context in HTTP header value" , group "(default) HTML Injection in Header Value" , attack type "HTML injection": deny rule was triggered by request on mapping I am in contact with Ergon to find out what needs to be changed to allow these requests since they don't seem to be bad at all.
,
Jul 19
Rolf, thanks very much - happy to talk to Ergon if it helps. FWIW, all of the sites that I've seen this problem on have behaviours and headers very similar to sbb.ch; I suspect they all have Airlock in common (and they're mostly clustered in Switzerland).
,
Jul 19
,
Jul 20
No need to talk to Ergon - Ergon talks to you ;-) As Rolf mentioned it's actually Airlock WAF that blocks/blocked those requests. The Sec-Metadata header has enough similarity to an HTML-injection, since target="top-level" is a known HTML attribute. We changed the ruleset for the upcoming Airlock WAF release coming in about 4 weeks: https://www.airlock.com/en/announcing-airlock-waf-71/ so the header Sec-Metadata will be whitelisted. In the meantime we support our customers in adapting rulesets for older versions not to block such requests. Since the header is only availabe in Chrome 69 and it is disabled by default we don't think it's necessary to adapt rulesets for older versions - for the moment. People using expierimental features know what they are doing. What are the plans for the Sec-Metadata header? When will it be enabled by default? We think it could be a good instrument to leverage the security to actually check the header and benefit from the content. We would possibly implement suitable logic / rules when the header will be rolled out to the masses. What are the plans therefor?
,
Jul 20
Thanks, Erwin! Regarding deployment plans, I don't think there is a concrete date; there will be some discussion among browser vendors about the specification and how it relates to other similar proposals (e.g. Cross-Origin-Resource-Policy - https://github.com/whatwg/fetch/issues/687), and based on that we may see implementations shipping sooner or later*. FWIW we're actively working on enabling security restrictions based on Sec-Metadata for Google applications so I'm hoping it won't take too long. When it comes to using Sec-Metadata to make security decisions, it does seem like WAFs would be in a reasonable position to do this. For example, if an application is entirely self-contained and its resources shouldn't be directly loaded by other sites, it could potentially log/block requests that are site="cross-site" and target="subresource"; of course the rules could also be much more complex than this. [*] Note that developer interest is a factor in such discussions so if you or your customers have a preference for one of these mechanisms, it might help to express it in one of the spec bugs.
,
Jul 27
I can see the same issue now on dev/canary channel for Chrome OS. However, the experiment is already disabled there, yet it sends that header. This makes my Chromebook unusable for ebanking/surfing.
,
Jul 27
killerfoxi@: If chrome://flags/#enable-experimental-web-platform-features isn't enabled, Chrome shouldn't be sending the header. If Chrome is sending the header anyway, we should ask it to stop sending the header. :) Could you post the command-line from chrome://version ?
,
Jul 31
,
Jul 31
I encountered this with https://www.1822direkt.com (my bank) which fails on my dev Chromebook with no remedy. The flag was already disabled and the header is still sent. It's clear that it's Sec-Metadata because the presence of it in a curl invocation triggers the 400 error. The command-line looks like this: /opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=30.0.0.142 --ui-prioritize-in-gpu-process --use-gl=egl --enable-native-gpu-memory-buffers --enable-webgl-image-chromium --enable-features=Pepper3DImageChromium,PointerEvent,EnableBackgroundBlur,Crostini,ExperimentalCrostiniUI --gpu-sandbox-failures-fatal=yes --enable-logging --log-level=1 --use-cras --enable-wayland-server --user-data-dir=/home/chronos --login-profile=user --has-chromeos-keyboard --enable-touchview --enable-voice-interaction --guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg --guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg --child-wallpaper-large=/usr/share/chromeos-assets/wallpaper/child_large.jpg --child-wallpaper-small=/usr/share/chromeos-assets/wallpaper/child_small.jpg --default-wallpaper-large=/usr/share/chromeos-assets/wallpaper/oem_large.jpg --default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/oem_small.jpg --default-wallpaper-is-oem --arc-availability=officially-supported --enable-arc-oobe-optin --enterprise-enrollment-initial-modulus=15 --enterprise-enrollment-modulus-limit=19 --login-user=[redacted] --login-profile=[redacted] --flag-switches-begin --disable-features=SystemTrayUnified --flag-switches-end --policy-switches-begin --isolate-origins=[redacted] --policy-switches-end --vmodule=*arc/*=1,*/assistant/*=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,*night_light*=1,update_engine=1,component_updater_service=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2 --enable-features=Pepper3DImageChromium,PointerEvent,EnableBackgroundBlur,Crostini,ExperimentalCrostiniUI --disable-features=SystemTrayUnified
,
Aug 3
It's the same as pkern. It's disabled and yet sent. Command Line /opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=30.0.0.142 --ui-prioritize-in-gpu-process --use-gl=egl --enable-native-gpu-memory-buffers --enable-webgl-image-chromium --enable-features=Pepper3DImageChromium,PointerEvent,EnableBackgroundBlur,Crostini,ExperimentalCrostiniUI --gpu-sandbox-failures-fatal=yes --enable-logging --log-level=1 --use-cras --enable-wayland-server --user-data-dir=/home/chronos --login-profile=user --has-chromeos-keyboard --enable-touchview --enable-voice-interaction --guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg --guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg --child-wallpaper-large=/usr/share/chromeos-assets/wallpaper/child_large.jpg --child-wallpaper-small=/usr/share/chromeos-assets/wallpaper/child_small.jpg --default-wallpaper-large=/usr/share/chromeos-assets/wallpaper/oem_large.jpg --default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/oem_small.jpg --default-wallpaper-is-oem --arc-availability=officially-supported --enable-arc-oobe-optin --enterprise-enrollment-initial-modulus=15 --enterprise-enrollment-modulus-limit=19 --login-user=[redacted] --login-profile=[redacted] --flag-switches-begin --flag-switches-end --policy-switches-begin --isolate-origins=[redacted] --policy-switches-end --vmodule=*arc/*=1,*/assistant/*=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,*night_light*=1,update_engine=1,component_updater_service=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2 --enable-features=Pepper3DImageChromium,PointerEvent,EnableBackgroundBlur,Crostini,ExperimentalCrostiniUI
,
Aug 10
I also encountered this problem. Our own website caused 400 because of this header. After searching, it is because the AWS gateway is converted, the conversion
{
“Sec-Metadata“: ”cause=forced, destination=“”, target=subresource, site=same-origin”
}
is wrong, so it cannot be parsed normally. I hope to help you.
,
Aug 14
I think we can resolve this by dropping the `target` attribute, as that seems to be the thing that WAFs are throwing on most commonly. Taking care of that in https://chromium-review.googlesource.com/c/chromium/src/+/1172137 and https://github.com/mikewest/sec-metadata/commit/de7530709176c56956a5f696b52244f25f86e4fd.
,
Aug 14
In the meantime, can we maybe fix the behvaiour on dev/canary channel? Like putting it behind the correct flags? That is not working properly right now.
,
Aug 15
I'll add advice to Structured Headers to avoid using HTML attribute names as identifiers in requests headers, since it might trigger some WAFs. Regarding comment 27 -- can you give more details? Is AWS changing the request header?
,
Aug 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c3dade0056461bb4d59c542164c58fb6f3409930 commit c3dade0056461bb4d59c542164c58fb6f3409930 Author: Mike West <mkwst@chromium.org> Date: Thu Aug 16 11:46:31 2018 Sec-Metadata: Remove the 'target' attribute. This patch removes the 'target' attribute by replacing it with a new 'destination' value that distinguishes between top-level and nested navigations. Spec: https://github.com/mikewest/sec-metadata/commit/de7530709176c56956a5f696b52244f25f86e4fd Bug: 861678, 843478 Change-Id: I2bf5df1b93fb2c7c341cbe6da30d99bb19d40626 Reviewed-on: https://chromium-review.googlesource.com/1172137 Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Reviewed-by: Philip Jägenstedt <foolip@chromium.org> Commit-Queue: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#583605} [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/content/browser/frame_host/navigation_request.cc [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/embed.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/fetch.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/font.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/iframe.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/img.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/object.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/redirect/cross-site/cross-site.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/redirect/cross-site/same-origin.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/redirect/cross-site/same-site.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/redirect/same-origin/cross-site.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/redirect/same-origin/same-origin.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/redirect/same-origin/same-site.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/redirect/same-site/cross-site.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/redirect/same-site/same-origin.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/redirect/same-site/same-site.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/report.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/resources/echo-as-json.py [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/resources/echo-as-script.py [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/script.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/serviceworker.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/sharedworker.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/style.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/track.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/window-open.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/worker.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/xslt.tentative.https.sub.html [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/navigation/form-targets-cross-site-frame-get-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/navigation/form-targets-cross-site-frame-no-referrer-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/navigation/form-targets-cross-site-frame-post-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/navigation/form-with-enctype-targets-cross-site-frame-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/navigation/post-basic-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/navigation/post-frames-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/navigation/post-frames-goback1-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/navigation/post-goback1-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/navigation/rename-subframe-goback-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-leak-path-on-redirect-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-allowed-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-allowed-with-redirect-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-default-ignored-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-default-ignored-with-redirect-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-get-allowed-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-get-allowed-with-redirect-expected.txt [modify] https://crrev.com/c3dade0056461bb4d59c542164c58fb6f3409930/third_party/blink/renderer/core/loader/base_fetch_context.cc
,
Sep 17
This is still a problem blocking many Swiss websites: axa.ch (largest insurance) raiffeisen.ch (3rd largest retail bank) in addition to the already noted ones: sbb.ch What is the status of making the setting to disable work?
,
Sep 17
Same. I would like to have this fixed (even just make it possible to disable it).
,
Oct 11
I just ran into this with bcge.ch with version 70.0.3538.41. Verifying the sites mentioned above, I see that axa.ch and admin.ch work, but sbb.ch and raiffeisen.ch are also broken. Can we put this behind a flag as requested above? Are the sites redirecting to the error page using an older ruleset (as mentioned in #c18 above)?
,
Oct 15
www.movistar.es (Telefónica) is experience the same behavior. Repro: curl -i 'https://www.movistar.es/ ' -H 'Sec-Metadata: cause="forced", destination="document", target="top-level", site="same-origin"' Getting a 400 Error with curl and with Chrome 69.0.3497.100 (Build oficial) (64 bits) (cohort: Stable)
,
Oct 16
1. aaj@ is going to turn off an experiment that was enabling this header for a subset of users, even when the experimental web platform features flag was off. 2. It looks like the assumption above that the `target` identifier was the problem is incorrect. As mnot@ noted above, removing quotes from the values seems like a substantive fix for the sites we've seen above. For example, dropping the quotes from #35's Telefónica example (`curl -i 'https://www.movistar.es/ ' -H 'Sec-Metadata: cause=forced, destination=document, target=top-level, site=same-origin'`) works just fine, as do similar tests on `sbb.de` and `sncf.com`. As of https://github.com/httpwg/http-extensions/commit/35c3e2592a9c240c10064650bc3560e619c5ad10, we can use identifiers as dictionary values again, so I'm going to drop the quotes and see how that works. Mark, y'all might want to do a bit more scanning for dictionary entries with string values generally? Perhaps changing the delimiter might be more web-compatible?
,
Oct 16
Please note that sbb.de != sbb.ch :). Maybe it was just a mistake in the comment or it was actually testing the wrong site :). Glad to hear that this experiment is behind a flag soon again!
,
Oct 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a7da8836628ac8b7a42480b03ed3d374ff403cb2 commit a7da8836628ac8b7a42480b03ed3d374ff403cb2 Author: Mike West <mkwst@chromium.org> Date: Wed Oct 17 06:51:12 2018 Convert 'Sec-Metadata' dictionary values to identifiers. Spec changes: * https://github.com/mikewest/sec-metadata/commit/4e80053af5a7494bc0f34afd30f990e5a79ae2ee * https://github.com/mikewest/sec-metadata/commit/279d75c9dc1117fb75581970e9fd1335e329b63c Bug: 861678 Change-Id: I7f272ba2e923a0d219e7a8ba62072860ba3d8319 Reviewed-on: https://chromium-review.googlesource.com/c/1282603 Reviewed-by: Andy Paicu <andypaicu@chromium.org> Reviewed-by: Camille Lamy <clamy@chromium.org> Commit-Queue: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#600304} [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/content/browser/frame_host/navigation_request.cc [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/content/browser/shared_worker/shared_worker_service_impl.cc [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/fetch.tentative.https.sub.html [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/report.tentative.https.sub.html [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/resources/helper.js [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/external/wpt/fetch/sec-metadata/xslt.tentative.https.sub-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/navigation/form-targets-cross-site-frame-get-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/navigation/form-targets-cross-site-frame-no-referrer-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/navigation/form-targets-cross-site-frame-post-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/navigation/form-with-enctype-targets-cross-site-frame-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/navigation/post-basic-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/navigation/post-frames-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/navigation/post-frames-goback1-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/navigation/post-goback1-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/navigation/rename-subframe-goback-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-leak-path-on-redirect-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-allowed-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-allowed-with-redirect-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-default-ignored-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-default-ignored-with-redirect-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-get-allowed-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-get-allowed-with-redirect-expected.txt [modify] https://crrev.com/a7da8836628ac8b7a42480b03ed3d374ff403cb2/third_party/blink/renderer/core/loader/base_fetch_context.cc
,
Oct 17
How soon do you expect these changes to go out? This bug is also affecting access to a number of websites in the US. I've verified that this bug is breaking the TD bank login page and the Citibank account summary page (by causing some XHRs to fail). E.g., https://onlinebanking.tdbank.com/ tries to load https://onlinebanking.tdbank.com/ngp_api/v1/security/configuration/edid via XHR, but the XHR comes back for 400 Bad Request because of the Sec-Metadata header. Similarly, a number of requests to online.citi.com (e.g., https://online.citi.com/US/REST/accountsPanel/getCustomerAccounts.jws) are failing with 500 errors because of the header.
,
Oct 17
,
Oct 17
Thanks for the useful repro cases! I have a CL in flight to disable the Sec-Metadata experiment for the subset of users that had it enabled via Finch; between this and Mike's fix in https://chromium.googlesource.com/chromium/src.git/+/a7da8836628ac8b7a42480b03ed3d374ff403cb2 this should be fixed soon.
,
Oct 24
> Mark, y'all might want to do a bit more scanning for dictionary entries with string values generally? Perhaps changing the delimiter might be more web-compatible? I think the trigger here was using a dictionary syntax with certain keywords; e.g., "target." I'm not optimistic about changing the syntax, since the conditions that triggered this were so general; any other syntax we choose might equally cause issues (especially since it might not "look right."). It'd be good to engage with WAF folks to come up with some principles on what they scan requests for, so the this doesn't end up ossifying the Web. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by mmenke@chromium.org
, Jul 9Components: -Internals>Network Blink>SecurityFeature