Hi, > 1. Introduce an "untrusted" mode or flag in browser CLI tools for > opening external URLs > 2. Extend xdg-open to support passing this "untrusted" flag or context > to the browser > 3. Modify desktop environments or applications to invoke xdg-open with > the "untrusted" option when appropriate
As was said by Solar Designer, if a "safe" version is needed,
it should probably be the default when going through URI scheme
registrations. This is because, as you said, this kind of issue
lies in the interaction between several components (URI sources,
URI sinks and URI go-betweens such as xdg-open) and it would
certainly be possible to find a way to bypass the behavior
otherwise.
For the sake of argument, we could mitigate right now with a
wrapper script such as (http-open-wrapper.py):
#!/usr/bin/python3
import sys
from html import escape
import os
from tempfile import NamedTemporaryFile
argv = sys.argv[1:]
uri = argv[-1]
if uri.startswith("http://";) or uri.startswith("https://";):
body = f'<a href="{escape(uri)}">Follow link</a>'
body += '<script>document.querySelector("a").click()</script>'
f = NamedTemporaryFile(delete=False, delete_on_close=False,
suffix=".html", mode="wt")
f.write(body)
f.flush()
argv[-1] = f.name
os.execvp(argv[0], argv)
os._exit(255)
with the caveat that you now have a dangling .html file hanging
around.
You would overwrite the existing MIME type registrations:
[Desktop Entry]
Comment=
-Exec=/home/john/firefox/firefox
+Exec=/home/john/http-open-wrapper.py /home/john/firefox/firefox
Icon=/home/john/firefox/browser/chrome/icons/default/default128.png
Name=Firefox
NoDisplay=false
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
StartupWMClass=firefox-nightly
X-KDE-SubstituteUID=false
X-KDE-Username=
However this kind of "safer" URI opening would would break *many*
legitimate use cases, right? This is exemplified by:
./http-open-wrapper.py https://setcookie.net/
wich does not receive SameSite=Strict cookies (as expected).
Scenario:
1. you receive a legitimate email from a webapp with a link,
https://myapp.example.com/foo;
2. you click on the link;
3. you opens "xdg-open --untrusted https://myapp.example.com/foo";;
4. this (somehow) triggers non-same-site navigation;
5. because you did not send the SameSite=Strict cookie,
you appear to be logged out of the webapp;
6. because you are non-tech-savy, you are left wondering what is
the issue.
This assumes that the webapp is not completely well-behaved
in regard to its cookie handling but this is the kind of
webapp SameSite protections are intended to cater for.
Regards,
Gabriel
OpenPGP_signature.asc
Description: OpenPGP digital signature
