Duplicated script request when using CSP meta in iframe
Reported by
grizl...@gmail.com,
Oct 25
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36 Steps to reproduce the problem: 1. Page dynamically creates a same domain iframe (about:blank) with JavaScript. 2. CSP meta tag is inserted into the iframe using `document.write()`. It doesn’t even need any value, just `<meta http-equiv="Content-Security-Policy" />` is enough. 3. Then a `<script>` tag (script1.js) is inserted into the iframe also via `document.write()`. 4. `script1.js` contains a `document.write()` which inserts another `<script>` tag `script2.js`. 5. Both script1.js and script2.js have `Cache-Control: no-store, no-cache` header set. 6. Second request for `script1.js` occurs in the network pannel as soon as `script2.js` is requested (appended to the DOM). The script is not executed twice, only requested as the console log defined in `script1.js` only appears once. See a live example: https://s3.amazonaws.com/onecreative-static-qa-us-east-1/craft-team/chrome-csp-bug/page.html It shows 2 requests for script1.js in the Network panel. Works fine in other browsers. What is the expected behavior? script1.js is being requested only once. What went wrong? Script is being requested twice when iframe has CSP meta tag. See steps to reproduce for more details. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 70.0.3538.67 Channel: stable OS Version: OS X 10.13.6 Flash Version:
,
Oct 25
,
Oct 25
Not Mac-only. cc-ing someone who knows CSP.
,
Oct 25
,
Oct 26
,
Oct 30
Has anybody by any chance been able to look at this? We wanted to improve security for ads, but this is currently preventing us from doing so as it is causing double counting of ad requests.
,
Nov 1
Able to reproduce the issue on reported chrome version #70.0.3538.67, latest stable #70.0.3538.77 and latest chrome #72.0.3597.0 using Windows 10, Ubuntu 17.10 and Mac OS 10.13.6. Observed that in network tab it shows 2 requests for script1.js, after reloading the page. The behavior is seen from old M-60builds (#60.0.3090.0). This is a non-regression issue, hence marking it as untriaged and requesting someone from the dev team to look into the issue. Thanks.!
,
Nov 5
I think what happens here is that when we insert the meta tag, the preload scanner is disabled (cf https://codereview.chromium.org/2242223003) but for the second document.write() it's used anyways, and so we end up preloading script1.js again.
,
Nov 5
I think this is fundamentally a bug in HTMLPreloadScanner::Scan, where we normally scan to the end and extract all the preloads, except when we've found a meta CSP tag, when we abort early: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/parser/html_preload_scanner.cc?rcl=1d00cca61c503c3f4cb355e2e6f3c6f82b123260&l=976 By re-using the same preload scanner, we keep the text in its buffer and when we scan again we re-use it when we do the second document.write. By this time script1 has already loaded, and the preload for it does not successfully coalesce into the existing resource (not 100% sure why, possibly related to cache-control no-store).
,
Nov 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7841106b3762a842a46ec2604e0534e58b5e94ee commit 7841106b3762a842a46ec2604e0534e58b5e94ee Author: Charlie Harrison <csharrison@chromium.org> Date: Tue Nov 06 06:00:33 2018 Clear the preload buffer when encountering a csp meta tag Bug: 898795 Change-Id: I143b0705647563e732e662701f3878126139cb1a Reviewed-on: https://chromium-review.googlesource.com/c/1318419 Commit-Queue: Charlie Harrison <csharrison@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Cr-Commit-Position: refs/heads/master@{#605607} [modify] https://crrev.com/7841106b3762a842a46ec2604e0534e58b5e94ee/third_party/blink/renderer/core/html/parser/html_preload_scanner.cc [modify] https://crrev.com/7841106b3762a842a46ec2604e0534e58b5e94ee/third_party/blink/renderer/core/html/parser/html_preload_scanner_test.cc
,
Nov 6
Should be fixed. Please re-open if the issue still occurs.
,
Nov 6
Thanks a lot for quick fix. Can I test this by using Canary or how could I test it? Is this going to land in v72, so it will be released on Jan 29th, 2019?
,
Nov 6
You can see what releases a given commit lands in using chromiumdash: https://chromiumdash.appspot.com/commit/7841106b3762a842a46ec2604e0534e58b5e94ee This should go out in the next canary. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by grizl...@gmail.com
, Oct 25