feat(core): allow configuring remote domains with IPC access, closes #5088 by lucasfernog · Pull Request #5918 · tauri-apps/tauri

lucasfernog · 2022-12-26T18:34:51Z

What kind of change does this PR introduce?

Does this PR introduce a breaking change?

Yes, and the changes were approved in issue #___
No

Checklist

When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
I have added a convincing reason for adding this feature, if necessary

Other information

Sytten

Thanks for taking on this challenge. I left some comments, some are blocking IMO.

Apart from those comments, I remember there was a reason why I didnt reuse the same function to inject the scripts in the window, but I don't remember why...

Sytten · 2022-12-26T22:58:56Z

core/tauri-utils/src/config.rs

+#[serde(rename_all = "camelCase", deny_unknown_fields)]
+pub struct ExternalCommandAccessScope {
+  /// The url to allow, matched against the webview URL using a glob pattern.
+  pub url: Url,


The reason I used a string here is to allow URL patterns. In our case we need to allow all URLs (*) but there is a more "legitimate" use case to allow all sub domains of a particular domain (*.example.com). Since it is converted into a glob anyway down the line it is fine.

Since in the general use case this is extremely fragile, it should be hard to allow all domains. Non pentest/security apps are the exception with edge cases and deliberately 'insecure' settings.

Sytten · 2022-12-26T23:01:23Z

core/config-schema/schema.json

        }
      ]
    },
+    "ExternalCommandAccessScope": {


Unsure if the name should change since it also whitelist plugin

Sytten · 2022-12-26T23:02:03Z

core/tauri-utils/src/config.rs

+  /// loaded malicious or compromised sites could start executing commands on the user's device.
+  ///
+  /// This configuration allows a set of external urls to have access to the Tauri commands.
+  /// Wildcards patterns are accepted and can be used to allow either all paths or


AFAIK if you use an URL, this is not true anymore. But like I said I prefer the glob.

It should still work, we use the same logic for the HTTP allowlist.

I will need to test but I am pretty certain the Url parser rejects a single *?

yes but you can do https://* (or https://**?) with effectively the same effect.

Edit: stuff like https://*.domain.com also works

I guess this is good for official TaurI, wont cut it for us since we also need to support http but I will maintain my fork.

well, you can also do http://... of course. Sure, it's a bit annoying if you want to support both protocols at the same time because it only accepts a single url (especially if we take into account the other convo about finer allowlist-like control)

Yup, thus my recommendation to keep it as a free string

Allowing http is super dangerous. And we could also allow an array of urls on the same scope.

I mean sure but at the same time this feature is an escape hatch and its made abundantly clear with the name that its dangerous. Http is perfectly acceptable for a lot of use cases like local installations or forwarded via an SSH tunnel.

How about only allowing https:// in the normal configuration while you could still manipulate the state (and scope) from rust core if you really really need to and understand the implications?
The same goes for wildcards like https://* and only allow https://example.tld/* or https://*.example.tld this way the already insecure feature is still somewhat reasonable.

Sytten · 2022-12-26T23:07:25Z

core/tauri/src/window.rs

+          return Ok(());
+        }
+
        if let Some(module) = &payload.tauri_module {


Hummm I don't like that. Currently there is no check for modules like fs. I think we should do something similar to plugin where we can whitelist each module.

I thought about adding an allowlist configuration object for each external access scope, but maybe the root allowlist can be used for that instead? Any reason a Tauri app should have multiple allowlists, one for each URL?

Also this can be confusing since you'd need to enable the allowlist on the root object to add it to the binary, and also allow it in the external access scope.

Yes this is important since it relates to security. Let me give you our usecase.

We have a first in-app window that manages the connections of the user. That window has access to the filesystem to store the configuration.

The user the clicks on a connection which opens a second window with the external URL. We really do not want this window accessing the filesystem directly. We just want it to access certain carefully crafted commands that are safe to call.

This is why I originally only allowed commands and even then I wanted to build a way to limit which commands could be called

Though I agree there could be a default to allow it to take the same values as the general allow list for modules.

Yeah I think we should add an option to block all Tauri APIs. That's easy and won't bloat the codebase with runtime allowlist checks.

Pushed a change to address this.

Sytten · 2022-12-26T23:09:46Z

core/tauri/src/window.rs

+          }
          manager.extend_api(invoke);
        } else {
          manager.run_invoke_handler(invoke);


Since we forked Tauri to ship our patched version, I had some ideas. I think whitelisting which command can be run would be really cool, but not a blocker for this PR.

See the message above. Also, it would need a lot of code to add this :(

This can come in a subsequent PR, happy to pitch in for the implementation

austenc · 2023-01-01T20:53:13Z

This PR opens up some really cool possibilities. Also, I know it's probably still a WIP.

After trying it out I think that the messaging and/or error related to the windows part of the config can be improved. More specifically, it wasn't clear what value to use for windows -- the app's name (the "title" of the window), or main.

Originally had something like this in my tauri.conf.json:

"dangerousExternalCommandAccess": [
    {
      "url": "https://my-localhost-app-url",
      "windows": ["my-app-name"]
    }
]

When changed to "windows": ["main"] it works.

Not sure whether it's a matter of improving the Scope not defined error message, or whether it's a documentation thing, but that was a tiny papercut I ran into. Thanks again for the work on this!

lucasfernog · 2023-01-03T17:32:09Z

@austenc we do mention it's the window labels, see https://github.com/tauri-apps/tauri/pull/5918/files#diff-ff73997dde3dc4965aa0c59ce0b37c7d208ae5b6b7686bf19e14d93c98cc1bacR1116. I'll improve the error message though.

austenc · 2023-01-03T18:35:35Z

Thanks for helping out a rust noob :) And thanks again for the work on this feature, really great!

1zun4secondary · 2023-01-14T15:41:59Z

How do I exactly use this tauri pull request?
I imported the library into my rust-project via
tauri = { git = "https://github.com/tauri-apps/tauri.git", branch = "feat/remote-ipc", features = ["api-all"] }
which worked out.

But when I run npm run tauri dev, it will say:

Error `tauri.conf.json` error on `tauri > security`: Additional properties are not allowed ('dangerousExternalCommandAccess' was unexpected)

Which makes sense, because the NPM tauri-cli library is still the v1.2.2. I don't know much about NPM, so I was wondering how I can use this pull request now?

FabianLars · 2023-01-15T18:42:26Z

@1zun4 see https://tauri.app/v1/guides/faq#how-can-i-use-unpublished-tauri-changes (Using the Tauri CLI from source) - i recommend using the cargo cli instead since it's easier to use a git version imo.

Oh and make sure to also use the tauri-build crate from git.

required pull request tauri-apps/tauri#5918

1zun4secondary · 2023-01-30T22:06:53Z

@1zun4 see https://tauri.app/v1/guides/faq#how-can-i-use-unpublished-tauri-changes (Using the Tauri CLI from source) - i recommend using the cargo cli instead since it's easier to use a git version imo.

Oh and make sure to also use the tauri-build crate from git.

Thank you very much! It works flawless with my application. Looking forward for it being merged.

When changed to "windows": ["main"] it works.

Not sure whether it's a matter of improving the Scope not defined error message, or whether it's a documentation thing, but that was a tiny papercut I ran into. Thanks again for the work on this!

... took me a while to figure it out... haha

required pull request tauri-apps/tauri#5918

ddx95 · 2023-03-08T08:59:49Z

Hello, is there any way to modify/add dynamically a value to the dangerousExternalCommandAccess field from the main.rs ? I would need, for example, to get my remote server address from another configuration file, a environment variable or a register key.

tm1000 · 2023-03-12T17:24:00Z

What's the status of this PR?

prestomation · 2023-03-23T03:52:46Z

Looks like there is lots of interest in this feature. What can the community to do help it land?

nothingismagick

First of all, this is an approach that removes security features that underly the entire premise of Tauri - all of us can agree on this. It is basically permitting people to drive a motorcycle without a helmet.

To that extent I would propose that we empower the individual to KNOW that this is going on and DENY such permissive use, especially in "*" wildcard situations.

One idea to harden this is to use a model similar to the way our Isolation pattern works, where the app sends an authorization to the remote, and the remote has to reply properly or tauri IPC execution is prevented.

I think @tauri-apps/wg-security must absolutely sign off on this before it enters canon, especially since this modifies the isolation.js guardrails as well.

lucasfernog · 2023-03-23T11:18:03Z

The security team has been auditing this PR and the finds will be public soon - along with the proposed solution to improve security.

Sytten · 2023-03-23T13:29:07Z

Can't wait for their input, I still stand with the review I made 3 months ago. This feature is an escape hatch for "dangerous" usecases, so for me it should allow users to whitelist each element as they wish. It should be very specific in its definition but broad in what it allows (like: I want to allow plugin X for all websites). It should definitely not be used 99% of the time. Our usecase for it was to be able to allow loading remote UI that can interact with some whitelisted tauri commands. It would even be ok with a compiler warning if this feature is used.

lucasfernog · 2023-04-05T19:19:52Z

One thing I did not touch is usage of remote URLs with the isolation protocol enabled. Since we can't inject the isolation protocol scripts (?) it does not work at all right now.

tillmann-crabnebula

Minor documentation changes but implementation looks good to me 👍

core/tauri/src/window.rs

tooling/cli/schema.json

lucasfernog · 2023-04-07T00:49:37Z

@tillmann-crabnebula I've pushed some changes to make this work with the isolation pattern.

I'm planning on merging this and release 1.3 next week if we can get all blog posts ready.

lucasfernog · 2023-04-07T15:46:08Z

We had to change the approach here from "configuring remote URLs with glob patterns" to "configuring domains" for security reasons. If you need to allow ALL URLs, that is super dangerous and you'll need to do so by listening to the navigation event via WindowBuilder::on_navigation and manually adding the domain to the scope.

core/config-schema/schema.json

tweidinger · 2022-12-27T00:32:30Z

core/tauri-utils/src/config.rs

+#[serde(rename_all = "camelCase", deny_unknown_fields)]
+pub struct ExternalCommandAccessScope {
+  /// The url to allow, matched against the webview URL using a glob pattern.
+  pub url: Url,


Since in the general use case this is extremely fragile, it should be hard to allow all domains. Non pentest/security apps are the exception with edge cases and deliberately 'insecure' settings.

core/tauri-utils/src/config.rs

tweidinger · 2023-01-09T08:17:56Z

core/tauri-utils/src/config.rs

+  /// loaded malicious or compromised sites could start executing commands on the user's device.
+  ///
+  /// This configuration allows a set of external urls to have access to the Tauri commands.
+  /// Wildcards patterns are accepted and can be used to allow either all paths or


How about only allowing https:// in the normal configuration while you could still manipulate the state (and scope) from rust core if you really really need to and understand the implications?
The same goes for wildcards like https://* and only allow https://example.tld/* or https://*.example.tld this way the already insecure feature is still somewhat reasonable.

Sytten · 2023-04-11T13:22:18Z

Thats fair, at least there is a way to do it. I will give it a try this week. When is it planned to be released?

lucasfernog · 2023-04-11T13:28:53Z

We're working to release it this week.

1zun4secondary · 2023-04-11T19:10:41Z

huuray

This was cherry picked from ee71c31, keeping only the logic to block remote URLs from using the IPC. PR: #5918

A regression introduced in the last commit from #5918.

limitedmage · 2023-04-28T16:39:18Z

Hello, will this be released for v1.x or will this have to wait until v2.0?

FabianLars · 2023-04-28T16:44:49Z

It will be part of v1.3

taruri 优先使用 pwa 应用 tauri-apps/tauri#5918

Implemented upgrade to Tauri version 1.3, eliminating the need for utilizing the "feat/remote-ipc" branch. Instead, we can now leverage the newly introduced "dangerousRemoteDomainIpcAccess" option in the "tauri.conf.json" file, which was introduced in version 1.3.0. For further details, please refer to the relevant pull request at the following link: tauri-apps/tauri#5918. While this feature has undergone testing and is confirmed to be functional, it is imperative to conduct further testing to ensure its reliability. If any issues are encountered during usage, kindly report them for further investigation and resolution. Your feedback is greatly appreciated.

luucasrb · 2023-06-04T14:31:48Z

Can we have this feature in the next branch as a 2.0 feature? I would love to use it in my context, but I cannot downgrade to the 1.x.

FabianLars · 2023-06-04T15:02:17Z

@luucasrb It already is in the next branch. iirc it was also part of alpha.9 but not 100% sure about that.

luucasrb · 2023-06-08T00:59:43Z

Thanks, you are right. My confusion was that the dangerousRemoteDomainIpcAccess config is only in the v1 docs but not in the next docs.

JVariance · 2023-09-13T06:56:31Z

We had to change the approach here from "configuring remote URLs with glob patterns" to "configuring domains" for security reasons. If you need to allow ALL URLs, that is super dangerous and you'll need to do so by listening to the navigation event via WindowBuilder::on_navigation and manually adding the domain to the scope.

I want to add domains inside on_navigation, but I just don't succeed. Can you give me an example, how I can do it?

feat(core): allow configuring remote URLs with IPC access, closes #5088

e3142f2

lucasfernog requested a review from a team as a code owner December 26, 2022 18:34

lucasfernog mentioned this pull request Dec 26, 2022

Allow external URLs to access IPC commands #5139

Closed

Sytten suggested changes Dec 26, 2022

View reviewed changes

add option to disable tauri API

d46af2a

improve error message [skip ci]

cac7dd5

FabianLars mentioned this pull request Jan 11, 2023

[bug] unable to emit events on webview from external url #6043

Closed

1zun4secondary pushed a commit to CCBlueX/LiquidLauncher that referenced this pull request Jan 30, 2023

Added support for webview download

1d39c11

required pull request tauri-apps/tauri#5918

SenkJu pushed a commit to CCBlueX/LiquidLauncher that referenced this pull request Jan 31, 2023

Added support for webview download

82a37f5

required pull request tauri-apps/tauri#5918

FabianLars mentioned this pull request Mar 2, 2023

Can Tauri load remote content? #986

Closed

nothingismagick reviewed Mar 23, 2023

View reviewed changes

nothingismagick requested a review from a team March 23, 2023 11:19

lucasfernog added 3 commits March 25, 2023 10:49

Merge remote-tracking branch 'origin/dev' into feat/remote-ipc

ab4b49d

rename disable_tauri_api to enable_tauri_api

0c637bf

use navigation handler to determine current url

94dd60c

amrbashir mentioned this pull request Mar 28, 2023

[bug] Not receiving chrome window notification when loading external url through Tauri #6574

Closed

lucasfernog added 3 commits March 31, 2023 10:35

fix tests [skip ci]

4882e1d

lint [skip ci]

ebabdad

add Rust API to extend config, change url glob to domain str

da88867

lucasfernog mentioned this pull request Apr 5, 2023

[bug] window.__TAURI_IPC__ is not a function when not using a dev server #6594

Closed

fix windows test [skip ci]

bd3d007

tillmann-crabnebula reviewed Apr 6, 2023

View reviewed changes

core/tauri/src/window.rs Outdated Show resolved Hide resolved

tooling/cli/schema.json Outdated Show resolved Hide resolved

lucasfernog added 3 commits April 6, 2023 13:25

fix docs

adac470

add doc link to error message

51b6880

feat: work with isolation pattern

de18585

lucasfernog changed the title ~~feat(core): allow configuring remote URLs with IPC access, closes #5088~~ feat(core): allow configuring remote domains with IPC access, closes #5088 Apr 7, 2023

Merge branch 'dev' into feat/remote-ipc [skip ci]

42fe73e

tweidinger approved these changes Apr 11, 2023

View reviewed changes

lucasfernog merged commit ee71c31 into dev Apr 11, 2023

lucasfernog deleted the feat/remote-ipc branch April 11, 2023 11:50

lucasfernog added a commit that referenced this pull request Apr 12, 2023

feat(core): block remote URLs from accessing the IPC

fa90214

This was cherry picked from ee71c31, keeping only the logic to block remote URLs from using the IPC. PR: #5918

lucasfernog added a commit that referenced this pull request Apr 12, 2023

feat(core): block remote URLs from accessing the IPC

58ea0b4

This was cherry picked from ee71c31, keeping only the logic to block remote URLs from using the IPC. PR: #5918

lucasfernog added a commit that referenced this pull request Apr 12, 2023

feat(core): block remote URLs from accessing the IPC

9c0593c

This was cherry picked from ee71c31, keeping only the logic to block remote URLs from using the IPC. PR: #5918

lucasfernog added a commit that referenced this pull request Apr 12, 2023

fix(core): IPC remote domain check bypassed by isolation iframe usage

1b8716a

A regression introduced in the last commit from #5918.

lucasfernog mentioned this pull request Apr 12, 2023

fix(core): IPC remote domain check bypassed by isolation iframe usage #6691

Merged

13 tasks

baiy added a commit to baiy/Ctool that referenced this pull request May 21, 2023

taruri 版本提升

063dc21

taruri 优先使用 pwa 应用 tauri-apps/tauri#5918

Uh oh!

Conversation

lucasfernog commented Dec 26, 2022

What kind of change does this PR introduce?

Does this PR introduce a breaking change?

Checklist

Other information

Uh oh!

Sytten left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FabianLars Dec 27, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FabianLars Dec 27, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

austenc commented Jan 1, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lucasfernog commented Jan 3, 2023

Uh oh!

austenc commented Jan 3, 2023

Uh oh!

1zun4secondary commented Jan 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FabianLars commented Jan 15, 2023

Uh oh!

1zun4secondary commented Jan 30, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ddx95 commented Mar 8, 2023

Uh oh!

tm1000 commented Mar 12, 2023

Uh oh!

prestomation commented Mar 23, 2023

Uh oh!

nothingismagick left a comment

Sytten left a comment •

edited

Loading

FabianLars Dec 27, 2022 •

edited

Loading

FabianLars Dec 27, 2022 •

edited

Loading

austenc commented Jan 1, 2023 •

edited

Loading

1zun4secondary commented Jan 14, 2023 •

edited

Loading

1zun4secondary commented Jan 30, 2023 •

edited

Loading