Skip to content

security: fix path traversal and query injection in resource names - #96

Open
tamirse wants to merge 5 commits into
masterfrom
fix/path-traversal-in-resource-names
Open

security: fix path traversal and query injection in resource names#96
tamirse wants to merge 5 commits into
masterfrom
fix/path-traversal-in-resource-names

Conversation

@tamirse

@tamirse tamirse commented Aug 7, 2026

Copy link
Copy Markdown
Collaborator

Caller-supplied resource names and IDs are no longer interpolated directly into request paths. This prevents malicious input containing ../ from retargeting API calls, and ? or # from injecting query parameters or fragments.

Values are now percent-encoded as single path segments, and . .. or empty values are rejected. The HTTP client also includes a backstop to refuse requests that attempt to escape the API base path.

tamirse added 3 commits August 7, 2026 09:58
Caller-supplied resource names and IDs are no longer interpolated directly into request paths. This prevents malicious input containing `../` from retargeting API calls, and `?` or `#` from injecting query parameters or fragments.

Values are now percent-encoded as single path segments, and `.` `..` or empty values are rejected. The HTTP client also includes a backstop to refuse requests that attempt to escape the API base path.
Expands the path traversal protection to cover additional service methods,
including `instances.is_available()` and `clusters.is_available()`, and
various container and job deployment operations.

Enhances path parameter validation to reject unused keys, preventing silent
errors from misspelled or stale parameters. Non-string path values are now
gracefully coerced to strings for backward compatibility.

Reorders token refresh to occur after path validation, preventing unnecessary
network calls when path parameters are invalid.
Strengthens path traversal protection by explicitly rejecting resource names
or IDs that contain relative path segments (`.` or `..`), are empty, or `None`.
Previously, such values were merely percent-encoded, which is insufficient as
`requests` decodes unreserved characters or intermediaries unescape encoded
slashes, re-introducing vulnerabilities.

This also expands protection to `InferenceClient` paths, ensuring they cannot
escape their deployment's base URL. All HTTP verb methods now delegate to a
central `_request` method, standardizing path validation and ensuring
comprehensive coverage.

This introduces two breaking changes:
- Resource names or IDs containing a relative path segment, an empty value,
  or `None` now raise `ValueError`.
- Resource names and IDs are always percent-encoded by the client; pre-encoded
  values will be double-encoded. Callers should pass raw names.
@tamirse
tamirse requested a review from shamrin August 7, 2026 08:01
tamirse added 2 commits August 7, 2026 11:25
Moves path traversal detection to `verda.helpers.has_relative_path_segment` to unify checks across `HTTPClient` and `InferenceClient`, ensuring consistent protection against `.` and `..` segments, even when percent-encoded.

Expands `_encode_path_segment` to explicitly reject path parameters that are not `str`, `int`, or `UUID`, preventing ambiguous coercion (e.g., `bytes` to `"b'abc'"`) that would result in confusing 404s.

Hardens `_add_base_url` to reject paths containing query strings or fragments, preventing URL component injection. Adds a dynamic test to ensure all service methods accepting path parameters are covered by traversal tests.

**Breaking changes:**
- A path value that is not `str`, `int`, or `UUID` now raises `ValueError`.
- A `/` within a resource name is now consistently encoded as `%2F`, ensuring it remains a single path segment. Servers that reject or refuse to decode encoded slashes may break.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant