[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFyT70jJBgFDN1nreS1D6xp5QdXjJ8aLiJSbGfN8PTo5F1tChw@mail.gmail.com>
Date: Mon, 23 Jun 2025 20:59:46 +0900
From: grape mingijung <mingijung.grape@...il.com>
To: oss-security@...ts.openwall.com
Subject: xdg-open bypassing SameSite=Strict
Hello,
I would like to share a security concern involving the behavior of the
xdg-open command, which is widely used in operating systems. This behavior
may allow bypassing the SameSite=Strict cookie policy enforced by modern
browsers.
This issue has already been reported to distros under embargo, which has
now expired, making public disclosure appropriate at this time.
The reason this issue was initially reported to Linux distros is that it
resides in a *gray area between the OS, the xdg-open utility, and browser
security policies*—making it unclear where the mitigation responsibility
lies.
------------------------------
■ Summary:
xdg-open is commonly used by desktop applications to open URLs in the
system's default web browser. Many applications—such as email clients and
messaging tools—rely on this mechanism to handle external links.
However, when a browser launches via xdg-open to open a URL, it interprets
the navigation as if the user *manually typed the URL into the address bar*.
As a result, SameSite=Strict cookies are included in the request.
This behavior differs from in-browser link navigation (e.g., clicking a <a>
tag), where SameSite=Strict cookies are intentionally excluded to enforce
CSRF protections.
------------------------------
■ Security Impact:
Consider the following example: an email client parses a DOM element such as
<a href="https://evil.com?csrf=strict_cookie">,
and the user clicks this link. The application uses xdg-open to launch the
browser.
In this case, the browser treats the request as a user-initiated top-level
navigation, and SameSite=Strict cookies are sent—allowing the CSRF attack
to succeed.
In contrast, if the same email is opened directly in the browser and the
same <a> tag is clicked, SameSite=Strict cookies are *not* sent, and the
CSRF attempt fails.
This creates an inversion of expected behavior: *navigating via xdg-open
can result in weaker security than navigating from within the browser
itself.*
------------------------------
■ Recommendations:
During discussions with several Linux distro security teams, the following
suggestions were raised:
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
In summary, it was suggested that the *browser should be updated first*,
followed by gradual support at the xdg-open and system levels.
Accordingly, the issue has been forwarded to *browser vendors*, who are
currently reviewing it and exploring potential fixes.
------------------------------
■ Current Status:
Major browser vendors have been notified and are aware of the issue.
Discussions are ongoing to determine an appropriate solution.
Although no specific fix has been finalized, the need for action is
acknowledged.
We will continue to share updates on this issue, including browser-side
responses or mitigation strategies, via the oss-security mailing list.
Best regards,
Mingi Jung
Powered by blists - more mailing lists
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.
