Bug or feature? offscreen documents can execute dynamic code through Web Workers.

298 views
Skip to first unread message

BlackGlory

unread,
Nov 20, 2023, 4:22:01 AM11/20/23
to Chromium Extensions
Code:
```js
const script = `console.log(globalThis.origin)`
const blob = new Blob([script], { type: 'application/javascript' })
const url = URL.createObjectURL(blob)
new Worker(url)
```

As far as I know, the same code based on the data protocol cannot bypass CSP:
```js
const script = `console.log(globalThis.origin)`
const url = `data:application/javascript;base64,${btoa(script)}`
new Worker(url)
```

Oliver Dunk

unread,
Nov 20, 2023, 4:38:41 AM11/20/23
to BlackGlory, Chromium Extensions
Hi,

Great question!

Our additional requirements for Manifest V3 prohibit remotely hosted code. This is the case regardless of the mechanism, so using this to execute any remotely hosted code would be a policy violation. For dynamic code that has come from elsewhere, I think that's a bit more of a grey area. If you had a reasonable use case it might be ok, but you should definitely be using the userScripts API or a script contained in a file if those are appropriate.

As far as if this is a bug, we know that not every way to execute remotely hosted code has been patched. This is intentional to make sure that we find a balance between encouraging doing the right thing and not locking down the platform too much. So I think there's probably no need to report this.

Hope that helps,
Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB


--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/500cd115-bfa0-4faf-a431-ffe92a59dbc4n%40chromium.org.

wOxxOm

unread,
Nov 20, 2023, 7:45:44 AM11/20/23
to Chromium Extensions, Oliver Dunk, Chromium Extensions, BlackGlory
>  This is intentional to make sure that we find a balance between encouraging doing the right thing and not locking down the platform too much. So I think there's probably no need to report this.

If this intentional, it's a poor design philosophy and a complete lack of responsibility, so I doubt this is the case. It's definitely something that needs to be reported and a proper responsible adult decision needs to be made about it, even if it's just a note in the documentation.

Oliver Dunk

unread,
Nov 20, 2023, 8:01:19 AM11/20/23
to wOxxOm, Chromium Extensions, BlackGlory
wOxxOm, please remember to follow the code of conduct when replying.

If you have thoughts on design decisions, that's fine, but all of us speak on behalf of the team here. We have already discussed similar issues, for example at https://crbug.com/1463420, and so while you're welcome to open a bug we are unlikely to prioritise this.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

wOxxOm

unread,
Nov 20, 2023, 8:17:03 AM11/20/23
to Chromium Extensions, Oliver Dunk, Chromium Extensions, BlackGlory, wOxxOm
Well, it is a fact that such selective treatment of security sensitive features is not a good design philosophy, so your attempt to misrepresent my criticism as a violation of code looks like misdirection and an attempt to play the victim card.

> we are unlikely to prioritise this.

This is not your decision to make.

wOxxOm

unread,
Nov 20, 2023, 8:26:20 AM11/20/23
to Chromium Extensions, wOxxOm, Oliver Dunk, Chromium Extensions, BlackGlory
While I may have appeared overly blunt due to English not being my native language, but the real message I tried to convey is that you need to treat these issues much more responsibly, at least by mentioning the list of allowed exceptions in the documentation.

Oliver Dunk

unread,
Nov 20, 2023, 9:12:23 AM11/20/23
to wOxxOm, Chromium Extensions, BlackGlory
Always supportive of more documentation, we can definitely consider that.
Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

Jackie Han

unread,
Nov 23, 2023, 12:28:51 AM11/23/23
to wOxxOm, Chromium Extensions, Oliver Dunk, BlackGlory
In my opinion, I think this is a bug.

In MV3, the default CSP is 
"extension_pages": "script-src 'self'; object-src 'self';"
The worker-src fallbacks to the script-src.

In theory, "worker-src 'self'" means that you can't create a worker with a blob url.
To create a worker with a blob url, the CSP should be "worker-src 'self' blob:" (i.e. explicitly add "blob:", but it is not allowed by the minimum CSP)

For example, let's start a localhost web server, and open a localhost web page with 
<meta http-equiv="Content-Security-Policy" content="worker-src 'self'">
<meta http-equiv="Content-Security-Policy" content="worker-src 'self' blob:">
then you can validate that it can't create a worker with a blob url if CSP is worker-src 'self' only.

But the problem is that it works in an extension context without blob: csp.

I created a bug here https://crbug.com/1504703

Jackie Han

unread,
Apr 12, 2024, 1:36:18 PM4/12/24
to wOxxOm, Chromium Extensions, Oliver Dunk, BlackGlory
A few days ago, a developer pointed out that this might be because the browser bypassed the CSP for blob: URL in extensions. I'm not familiar with the implementation, but it feels like it might be. At least in MV3, Chrome should enforce its minimum extension CSP.

BTW, comment #2 and #3 are obvious spam, but I don't have permission to delete them.
Reply all
Reply to author
Forward
0 new messages