Before Qt 5.11.2, for unique origins, we always got QUrl() and thus passed it
through.
With Qt 5.11.2, only missing origins (browser-initiated requests) get an empty
initiator, while unique origins get QUrl("null"):
https://codereview.qt-project.org/#/c/234849/https://bugreports.qt.io/browse/QTBUG-69372
In theory, those should be locked down (as an unique origin is e.g. a sandboxed
iframe) and never have access to any other content.
However, thanks to a Qt bug, XHR on qute:// pages has QUrl("null") as origin as
long as the URL scheme is not registered. We can only do the registering once
Qt 5.12 is out.
Since unique origins were effectively already allowed on Qt 5.11.0/.1, we pass
them through here as well until Qt 5.12.
See #4198
In ffc29ee043 (part of v1.0.0), a
qute://settings/set URL was added to change settings.
Contrary to what I apparently believed at the time, it *is* possible for
websites to access `qute://*` URLs (i.e., neither QtWebKit nor QtWebEngine
prohibit such requests, other than the usual cross-origin rules).
In other words, this means a website can e.g. have an `<img>` tag which loads a
`qute://settings/set` URL, which then sets `editor.command` to a bash script.
The result of that is arbitrary code execution.
Fixes#4060
See #2332
It looks like chrome-error://chromewebdata/ triggers another invalid scheme
load which is why the endless loop happens. When we install a custom scheme
handler for chrome-error:// we can at least show an error page.
Before, we just returned the same data for both, but then we'll run into
same-origin restrictions as qute:history and qute:history/data are not the same
host.
