Announcing Tauri 1.3.0
此内容尚不支持你的语言。
The Tauri team is excited to announce the 1.3 release. This version includes security improvements, new features and important bug fixes.
Upgrading
Make sure to update both NPM and Cargo dependencies to the 1.3.0 release. You can update the dependencies with:
npm install @tauri-apps/cli@latest @tauri-apps/api@latest
yarn upgrade @tauri-apps/cli @tauri-apps/api --latest
pnpm update @tauri-apps/cli @tauri-apps/api --latest
cargo update
What’s in 1.3.0
NSIS
The Tauri CLI can now create Windows application installers using NSIS. This new bundle target is also available on macOS and Linux as an experimental feature, so you can cross-compile your Windows installer. Documentation on the latter will be published soon.
Tauri 1.3 Audit
The internal audit was performed by @tweidinger and @chippers, who are involved in most security topics at the Tauri project. It was performed during paid time at CrabNebula and we are grateful to be able to spend parts of our work time contributing to the open source project and making it a more secure environment :heart:.
We manually audited over 45 PRs. Some PRs (e.g. #5544) lead us to diving into very old RFCs (RFC6068 and RFC3966), NSIS documentation (e.g. #6039) and many other external resources. We documented questions, notes and findings in markdown files and shared these notes with the responsible developers to ensure appropriate fixes.
The changes from a security perspective and findings of the audit are summarized in the following sub-sections.
External API Access #5918
This was by far the most impactful and time consuming PR we investigated. This PR introduces a streamlined way for applications to allow external domains access to the Tauri IPC layer1 and usage majorly impacts the security model of a Tauri application. Security impact2 depends on exposure3 of the feature, enabled Tauri commands and the capabilities of an adversary4.
We consider this new feature similar to driving a very fast race car without any safety features enabled and urge developers to very very carefully consider if they really need this exposure.
Before this addition was merged, a semi-known vulnerability was (ab)used by application developers to achieve the same functionality. To make the whole community aware of this risk we published a security advisory to give a heads up. Applications are affected if they allow users to navigate to arbitrary domains or have an open redirect vulnerability5. If you implement such a feature you should update to the 1.3 release as fast as possible.
The initial PR changes allowed wildcards (https://*
) and glob patterns, which we believe are helpful but shouldn’t be exposed to all Tauri developers. We concluded that the risk of over-exposure, like the allow list toggle to enable all Tauri API endpoints, does not justify this permissive exposure. The final implementation allows to configure specified (sub)domains6 (eg: example.com
) to gain remote access to the Tauri IPC.
The few edge use cases, which require wildcards or even further exposure can be implemented by custom Rust code which is able to dynamically modify the IPC access. We now expose this remote IPC scope in a similar fashion as the fs
or http
scope.
Assuming a fully trusted web service on https://trusted.example
it is now possible to configure the security scope to allow certain windows or even plugins access to custom implemented commands and optionally the inbuilt Tauri API:
"security": { "dangerousRemoteUrlIpcAccess": [ { "windows": ["main", "settings"], "domain": "trusted.example", "plugins": ["trusted-plugin"], "enableTauriAPI": false }, ],}
Shared domains MUST NOT be used for this in any circumstances. We do not limit access to paths or specific files. You can only scope with trusted (sub)domains6. Another very risky catch is that developers must be sure that the domain ownership does not change over the lifetime of the application. Domain takeover could lead to compromised user devices.
Browser Arguments #5799
Due to certain webview features not enabled nor being accessible, a community contribution introduced the possibility to add additional arguments to the webview process, which is created in a new window.
This feature was exposed to the frontend in the window
endpoint. We found that this exposure was highly risky, as most webviews have very impactful features and flags that can be allowed via the process arguments.
All of the following threat model assumptions are based on the Tauri window creation being allowed in the allowlist
of the tauri.conf
and therefore exposed to the frontend. This PR affects Windows only, therefore there is no impact on the other supported operating systems.
An adversary with the capabilities to create windows and pass command line arguments to the webview can elevate their privileges to escape the strict sandboxing of Tauri and the webview.
The flags allow to enable several dangerous webview features, from loading profiles outside of the current default profile folder (stealing browser sessions from the device) to disabling security measurements of the webview (eg: certificate validation, sandboxing, webdriver/headless mode, device management endpoints, …).
We found an old but gold and still unique documentation reference at https://peter.sh/experiments/chromium-command-line-switches/, which helped us understand possible risks on Windows, as the Webview2 uses the same flags.
The feature was then changed to be only exposed on the rust side. Tauri application developers can use this to implement custom commands to invoke webview windows with use case specific arguments.
Possible ZipSlip #4674
We found that the components to extract remote bundler files like the Webview2 installer were manually extracting single files with the extract_zip
function, which uses ZipFile::name()
instead of ZipFile::enclosed_name()
as recommended in the documentation. Files which had names like ../../../../foo.sh
could be extracted outside of the intended directory on the filesystem. This kind of vulnerability is called ZipSlip.
As the function was only used on verified and trusted files the impact here was nearly zero. Regardless we changed the implementation to facilitate the proper extraction method.
Bundler Hardening #6039
The bundler was not escaping content passed to the handlebars::Handlebars::render()
, which could cause unwanted code execution during the bundler phase. This was also a low impact issue but was promptly fixed.
Other changes
New
additional_browser_args
option when creating windows #5799- Add
is_minimized()
window method. #5618 - Add
title
getter on window. #5515 - content protection APIs #5513
- Added
Builder::device_event_filter
andApp::set_device_event_filter
methods. #5562 - Add
WindowsAttributes::app_manifest
to specify the application manifest on Windows. #5730 - Add support for Cargo’s workspace inheritance. #5775 #6144
- Added window’s
url()
getter. #5914 - Added
Window::on_navigation
. #5686 - Allow setting the text of the dialog buttons. #4383
- Implement
SystemTray::with_tooltip
andSystemTrayHandle::set_tooltip
for Windows and macOS. #5938 - Add dylib support to
tauri.bundle.macOS.frameworks
. #5732
Enhancements
- On Windows, the
msi
installer’sLaunch App
checkbox will be checked by default. #5871 - Add
--png
option for theicon
command to generate custom icon sizes. #5246 - On Windows, change webview theme based on Window theme for more accurate
prefers-color-scheme
support. #5874 - Remove default features from Cargo.toml template. #6074
- Add a method to the
WindowBuilder
struct to recreate windows from tauri.conf.json configurations.#6073 - Improve the error message when
rustc
couldn’t be found. #6021 - Added support for pre-release identifiers and build numbers for the
.msi
bundle target. Only one of each can be used and it must be numeric only. The version must still be semver compatible according to https://semver.org/. #6096 - Add
--ci
flag and respect theCI
environment variable on thesigner generate
command. In this case the default password will be an empty string and the CLI will not prompt for a value. #6097 - Skip the password prompt on the build command when
TAURI_KEY_PASSWORD
environment variable is empty and the--ci
argument is provided or theCI
environment variable is set. d4f89af18d69fd95a4d8a1ede8442547c6a6d0ee
Fixes
- Fix
tauri info
panicking when parsing crates version on a newly created project without aCargo.lock
file. #5873 - Fix building apps with unicode characters in their
productName
. #5872 - Sync
__TAURI_METADATA__.__windows
across all windows. #5615 - Fix resize glitch when double clicking a custom titlebar in the top resize area. #5966
- Disable cursor mouse events on Linux. #6025
- Fix serialization of js
Map
when used ininvoke
. #6099
Footnotes
-
Inter-Process Communication, in this instance the communication between the Tauri core and the frontend code run inside the webview. ↩
-
Security Impact: What is the theoretical biggest impact of this threat combination? This highly depends on correct scoping of Tauri API endpoints and hardening of custom implemented Tauri commands. ↩
-
Exposure: Describes the exposed scope items of this feature to either an user or adversary. It is possible to restrict exposure to only certain domains, windows or only to custom implemented commands. ↩
-
Adversary Capabilities: Which kind of privileges has the adversary? Can range from tricking user into entering malicious input to code execution in the frontend via cross-site-scripting (which is the highest privilege for frontend code in our case). Common capabilities are described in the OWASP documentation. ↩
-
An application can be exploited if it parses user input for making an URL redirection decision, which is then not properly validated. Wikipedia Source ↩
-
see the Reqwest reference ↩ ↩2
© 2024 Tauri Contributors. CC-BY / MIT