fix: validate devtoolsOptionsUri in extensionEnabledState handler

[adilburaksen]

Summary

handleExtensionEnabledState() in _devtools_extensions.dart reads devtoolsOptionsUri directly from query parameters and passes it without validation to DevToolsOptions.setExtensionEnabledState(), which creates the target file and any missing parent directories.

// Before fix — no URI validation
final devtoolsOptionsFileUri = Uri.parse(devtoolsOptionsFileUriString);
// → passes directly to File.fromUri(devtoolsOptionsFileUri) in extension_enablement.dart

An untrusted caller that can reach the DevTools server (e.g., another local process, or a browser tab via cross-origin requests) can create or overwrite any file writable by the server process:

GET /api/extensionEnabledState?
    devtoolsOptionsUri=file:///home/user/.ssh/authorized_keys
    &extensionName=pwned&enabled=true

The resulting file content is a valid YAML map:

extensions:
  pwned: enabled

Fix

Reject requests where devtoolsOptionsUri:

• does not use the file: scheme, or
• does not end with devtools_options.yaml

Both conditions are required for a legitimate DevTools options file. Any other value is rejected with HTTP 400.

Impact

Without the fix, any local process or browser tab able to reach the DevTools HTTP server can create or overwrite arbitrary files on the developer's machine with attacker-controlled YAML content.

[gemini-code-assist]

Code Review

This pull request adds validation for the devtoolsOptionsUri query parameter to ensure it is a local file URI pointing to a devtools_options.yaml file, mitigating potential file overwrite vulnerabilities. Feedback was provided to tighten the path validation logic, as the current implementation could match unintended filenames.

[adilburaksen]

Friendly nudge — open ~18 days. Validates devtoolsOptionsUri in extensionEnabled to prevent the file-write primitive. Happy to address any feedback or add coverage if that helps move it along.

[kenzieschmoll]

will this forward slash work with windows file schemes?

[kenzieschmoll]

Please also add an entry to the devtools_shared changelog.

[adilburaksen]

Thanks for the review. Addressed both points in the latest commit:

• Windows file schemes: replaced the path.endsWith('/devtools_options.yaml') check with p.basename(uri.toFilePath()). toFilePath() resolves to the host's native path so the file-name match works for both / and \ separators, which fixes the forward-slash concern. I also require an empty URI host, which rejects UNC paths (file://server/share/...) and keeps toFilePath() from throwing on a non-local authority.
• Changelog: added an entry to packages/devtools_shared/CHANGELOG.md and bumped the package version to 13.0.2.

The existing apiExtensionEnabledState tests build the URI via Uri.file(...).toString(), so they still pass the new validation (file scheme, empty host, exact file name).