security: force attachment or block active uploaded content (ai:gpt-5) #52

New issue

Closed

opened 2026-05-23 22:09:19 +02:00 by heiko · 0 comments

heiko commented

2026-05-23 22:09:19 +02:00

Owner

Finding from a whole-codebase security review.

Affected code:

cmd/once-server/upload.go:133 stores the client-provided multipart Content-Type for single-file uploads.
cmd/once-server/upload.go:154 stores a fixed application/zip type for generated archives.
cmd/once-server/download.go:90-95 returns the stored type and only adds Content-Disposition: attachment when the type does not start with text/.

Impact:
An authenticated uploader can upload active text content such as text/html and send the once link to another user. After the recipient confirms the POST download, the browser may render the response as same-origin HTML/JavaScript because the server deliberately omits Content-Disposition for text/*. For users who also have Basic-auth credentials cached for the same origin, that script can make same-origin authenticated requests.

Suggested fix:

Prefer Content-Disposition: attachment for all downloads, including text/*.
Add X-Content-Type-Options: nosniff.
Consider forcing application/octet-stream unless the type is server-detected and known safe.
If inline display is required, add a restrictive CSP such as sandbox/default-src none and block active content types explicitly.
Add tests for text/html uploads to assert they are not rendered inline as active same-origin content.

Finding from a whole-codebase security review. Affected code: - cmd/once-server/upload.go:133 stores the client-provided multipart `Content-Type` for single-file uploads. - cmd/once-server/upload.go:154 stores a fixed `application/zip` type for generated archives. - cmd/once-server/download.go:90-95 returns the stored type and only adds `Content-Disposition: attachment` when the type does not start with `text/`. Impact: An authenticated uploader can upload active text content such as `text/html` and send the once link to another user. After the recipient confirms the POST download, the browser may render the response as same-origin HTML/JavaScript because the server deliberately omits `Content-Disposition` for `text/*`. For users who also have Basic-auth credentials cached for the same origin, that script can make same-origin authenticated requests. Suggested fix: - Prefer `Content-Disposition: attachment` for all downloads, including `text/*`. - Add `X-Content-Type-Options: nosniff`. - Consider forcing `application/octet-stream` unless the type is server-detected and known safe. - If inline display is required, add a restrictive CSP such as sandbox/default-src none and block active content types explicitly. - Add tests for `text/html` uploads to assert they are not rendered inline as active same-origin content.

heiko added the

security

label

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

heiko referenced this issue from a commit

2026-05-24 20:35:50 +02:00

security: force Content-Disposition attachment for all downloads (fixes #52) ai:claude-sonnet-4-5

heiko referenced this issue from a commit

2026-05-24 20:43:23 +02:00

Merge branch 'fix/52-attachment-headers' into security/all-fixes

heiko referenced this issue

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