Bug 237281

Summary:	Sandbox CSP directives allows websites to block execution of browser features implemented in JavaScript
Product:	WebKit	Reporter:	Michael Catanzaro <mcatanzaro>
Component:	WebCore Misc.	Assignee:	Nobody <webkit-unassigned>
Status:	NEW ---
Severity:	Normal	CC:	anhvy2013, bfulgham, bugs-noreply, mcatanzaro, pgriffis, simonepas, webkit-bug-importer, wilander
Priority:	P2	Keywords:	InRadar
Version:	WebKit Nightly Build
Hardware:	PC
OS:	Linux
See Also:	https://bugs.webkit.org/show_bug.cgi?id=192753 https://bugs.webkit.org/show_bug.cgi?id=178040

Description Michael Catanzaro 2022-02-28 10:55:49 PST

It seems web content is able to prevent the application from executing JavaScript using APIs like webkit_web_view_run_javascript() by using the "sandbox" CSP directive, see https://gitlab.gnome.org/GNOME/epiphany/-/issues/1698.

Needless to say, this CSP directive should only block *web content* from executing JS. It shouldn't block the browser itself from executing its own JS. Currently the web content is able to disable browser features, e.g. Epiphany's security warning when focusing an insecure password form, Epiphany's warning before closing a web page with an unsubmitted form, Epiphany's entire password manager, and even things like the code to compute a web app's name and title when creating a new web app. JS is used for a lot of stuff and it has to work.

See also: bug #192753.

Comment 1 Radar WebKit Bug Importer 2022-03-07 10:56:16 PST

<rdar://problem/89917757>

Comment 2 John Wilander 2022-03-21 20:18:10 PDT

Thanks for filing! I don't know if you are writing patches for WebKit these days, Michael. If so, is this something you intend/want to work on?

Comment 3 Michael Catanzaro 2022-03-22 07:05:26 PDT

I looked at it briefly, but not closely enough to prepare a patch. The error is coming from ScriptController::executeScriptInWorld, which decides scripts are not allowed because ScriptController::canExecuteScripts returns false. Maybe we need a new ReasonForCallingCanExecuteScripts for scripts executed by WebKit API that bypass some of the checks.

Comment 4 Michael Catanzaro 2022-07-02 09:11:04 PDT

Somebody is complaining on Matrix that this also breaks WebKit's HTMLMediaElement controls. So it's not just browser-level features, but also WebKit features that are affected.

Comment 5 Michael Catanzaro 2022-07-02 09:12:57 PDT

(In reply to Michael Catanzaro from comment #4)
> Somebody is complaining on Matrix that this also breaks WebKit's
> HTMLMediaElement controls. So it's not just browser-level features, but also
> WebKit features that are affected.

And it means the strategy suggested in my comment #3 would be insufficient to fully fix this. We'd need to identify other places within WebKit that use internal JavaScript and fix those too. I'm not sure what else there would be besides media controls, but I bet there's more I don't know about....