security: validate download keys before filesystem access (ai:gpt-5) #50

New issue

Closed

opened 2026-05-23 22:08:21 +02:00 by heiko · 0 comments

heiko commented

2026-05-23 22:08:21 +02:00

Owner

Finding from a whole-codebase security review.

Affected code:

cmd/once-server/download.go:21 derives key directly from r.URL.Path.
cmd/once-server/store/store.go:112-141 passes that key into filesystem joins without validating it as a UUID path segment.
cmd/once-server/store/file.go:32-34 opens filepath.Join(dir, name, "meta.json").

Impact:
Download URLs are bearer-token URLs, but the token is not validated before filesystem access. Go's ServeMux redirects literal ../ paths, but encoded path segments such as %2e%2e reach the handler decoded. filepath.Join then cleans those segments and can escape the intended store directory while looking for a meta.json/content pair. Even if exploitation depends on filesystem layout, this is the wrong trust boundary for a public unauthenticated endpoint.

Suggested fix:

Reject any download key that is not exactly a UUID string.
Reject keys containing path separators, empty segments, . or .. before calling store lookup.
Prefer extracting the key as a single URL path segment rather than using strings.TrimPrefix on the full path.
Add tests for literal and encoded traversal attempts (../, %2e%2e, %2f) and for valid UUID keys.

Finding from a whole-codebase security review. Affected code: - cmd/once-server/download.go:21 derives `key` directly from `r.URL.Path`. - cmd/once-server/store/store.go:112-141 passes that key into filesystem joins without validating it as a UUID path segment. - cmd/once-server/store/file.go:32-34 opens `filepath.Join(dir, name, "meta.json")`. Impact: Download URLs are bearer-token URLs, but the token is not validated before filesystem access. Go's ServeMux redirects literal `../` paths, but encoded path segments such as `%2e%2e` reach the handler decoded. `filepath.Join` then cleans those segments and can escape the intended store directory while looking for a `meta.json`/`content` pair. Even if exploitation depends on filesystem layout, this is the wrong trust boundary for a public unauthenticated endpoint. Suggested fix: - Reject any download key that is not exactly a UUID string. - Reject keys containing path separators, empty segments, `.` or `..` before calling store lookup. - Prefer extracting the key as a single URL path segment rather than using `strings.TrimPrefix` on the full path. - Add tests for literal and encoded traversal attempts (`../`, `%2e%2e`, `%2f`) and for valid UUID keys.

heiko added the

security

label

2026-05-24 18:44:09 +02:00

heiko referenced this issue from a commit

2026-05-24 20:36:15 +02:00

security: validate download keys as UUIDs before filesystem access (fixes #50) ai:claude-sonnet-4-5

heiko referenced this issue

2026-05-24 20:44:00 +02:00

security: comprehensive fixes for issues #48, #50, #51, #52, #53 ai:claude-sonnet-4-5 #61

heiko referenced this issue

2026-05-24 20:44:20 +02:00