T09 · Insecure Skill Coding Practices
- Location
references/good-patterns.md:198- Finding
Unrestricted Frontend-Triggered Arbitrary File Write
- Content
View full analysis
.rs use crate::error::ResultExt; #[tauri::command] pub fn write_file(path: String, content: String) -> Result<(), String> { std::fs::write(&path, content).into_string_msg("Failed to write file") } ``` The command is included in the generated IPC handler: ```rust .invoke_handler(tauri::generate_handler![ // System commands commands::write_file, commands::save_file_dialog, commands::open_file_dialog, ``` ### Technical Analysis Both `path` and `content` originate from the frontend IPC caller. The backend passes the path directly to `std::fs::write` without validation, canonicalization, an allowlisted root directory, or proof that the user selected the destination through a trusted native dialog. Tauri capability rules governing `tauri-plugin-fs` do not constrain direct Rust standard-library filesystem calls. Consequently, registering this command exposes the native process's filesystem privileges directly to the WebView. This guidance also contradicts the Skill's prohibition in `SKILL.md:220` against raw filesystem writes using user-supplied paths. ### Attack Path 1. An attacker gains script execution in the WebView through an application vulnerability, compromised frontend dependency, unsafe remote content, or another XSS-equivalent path. 2. The attacker calls the registered `write_file` Tauri command. 3. The attacker supplies an arbitrary user-writable destination and chosen content. 4. The Rust backend writes the content using the application's native privileges. 5. The attacker may overwrite configuration files, shell initialization files, application data, or `~/.ssh/authorized_keys`, depending on operating-system permissions. ...[truncated 754 chars]- Remediation
View remediation
