T09 · Insecure Skill Coding Practices
- Location
references/ipc-commands.md:28- Finding
Webview-Controlled Arbitrary File Write Through IPC Command
- Content
View full analysis
Vulnerability Details
File Location:
references/ipc-commands.md, lines 28-31
Vulnerability Type: Unrestricted file write
Risk Level: HighVulnerable Code:
rust #[tauri::command] async fn save_file(path: String, contents: String) -> Result<(), String> { std::fs::write(&path, contents).map_err(|e| e.to_string()) }The corresponding frontend example at line 43 demonstrates that the path is supplied directly by the webview:
ts await invoke("save_file", { path: "/tmp/out.txt", contents: "hi" });Technical Analysis
The IPC command accepts an arbitrary path and file contents from the frontend and passes them directly to
std::fs::write. It does not:- Restrict writes to a dedicated application directory.
- Reject absolute paths or
..traversal components. - Canonicalize and validate the destination or its parent directory.
- protect against symbolic-link redirection.
- Enforce an allowlist of permitted filenames or extensions.
- Prevent overwriting an existing sensitive file.
Tauri capability controls can determine whether a webview may invoke this custom command, but they do not automatically restrict filesystem paths accessed internally by the Rust implementation. Once the command is callable, it writes with all filesystem privileges of the application process.
This exceeds the minimum privilege required for a typical “save file” example because the frontend receives authority to select any destination writable by the current user.
Attack Path
- An attacker compromises frontend execution through an XSS flaw, malicious bundled dependency, or other webview code-injection weakness.
- The compromised frontend invokes
save_file. - The attacker supplies an absolute path or traversal-based destination and attacker-controlled contents.
- The Rust backend writes to that destination with native application privileges.
- Depending on writable ...[truncated 661 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not accept an unrestricted filesystem path from the webview. Accept a logical filename or application-specific resource identifier instead.
- Resolve destinations beneath a dedicated directory such as the application data directory.
- Reject absolute paths, parent-directory components, platform-specific path prefixes, and embedded separators where filenames alone are expected.
- Canonicalize the approved parent directory and destination parent, then verify that the resolved destination remains beneath the approved root.
- Defend against symbolic-link and time-of-check/time-of-use attacks by using platform-appropriate no-follow and exclusive-create operations when relevant.
- Decide explicitly whether overwriting is permitted; otherwise use create-new semantics.
- Apply filename, extension, and size limits.
- Consider using Tauri’s scoped filesystem APIs so filesystem access is represented explicitly in capabilities.
- Add tests for absolute paths,
../traversal, symlink redirection, Windows path prefixes, and overwrite attempts.