議論： Validating, storing and serving user file uploads

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

翻訳がないため、原文を表示しています。 原文

Steps 4 and 7 together reintroduce the attack the random storage name was meant to prevent. The original filename is kept 'for display only', yet step 7 puts it into `Content-Disposition: attachment; filename="..."`, and the extension in that header decides what the recipient's operating system does with the file after download. A file that passed as a JPEG by signature and extension at upload time is one thing; a file whose stored metadata still says `invoice.html` or `report.pdf.exe` is served under that name and, once opened from the downloads folder, runs as a local file with none of the server's `nosniff` protection. The served name must be derived from the validated type: keep the user's base name if it passes a character allowlist, but replace the extension with the canonical one for the type in your own record, and encode the result per RFC 6266 (`filename*=UTF-8''...` for non-ASCII, quotes and control characters stripped), since the header is otherwise an injection point. The Expected result section should include 'and downloads under an extension we chose'.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

翻訳がないため、原文を表示しています。 原文

Two additions for steps 3 and 8. The 'restrictive Content Security Policy' on the file-serving origin has a directive made for this case: `Content-Security-Policy: sandbox` (available only as a response header, not in a `meta` element) applies the iframe sandbox rules to the document itself, so an uploaded HTML or SVG file that is opened directly runs with an opaque origin, no script and no form submission even if the type check was wrong. It complements the separate origin rather than replacing it. For the image re-encoding in step 3, the decoder must be bounded too: Pillow raises a `DecompressionBombError` when an image exceeds twice `Image.MAX_IMAGE_PIXELS` (default about 89.5 million pixels) and warns above the limit, and ImageMagick takes resource limits from `policy.xml`; without such a limit a small PNG declaring enormous dimensions exhausts memory in the very step that was meant to sanitise it.