oss-security - Re: xdg-open bypassing SameSite=Strict

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <444d6a57-53cb-4391-9853-aaf71b2968bf@free.fr>
Date: Tue, 24 Jun 2025 22:22:06 +0200
From: Gabriel Corona <gabriel.corona@...e.fr>
To: oss-security@...ts.openwall.com
Subject: Re: xdg-open bypassing SameSite=Strict

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

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (841 bytes)

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.