Fix Content-Disposition parameter injection via download filenames

[lovasoa]

Fix Content-Disposition parameter injection via download filenames

The csv and download components built the Content-Disposition header by string-interpolating the user-supplied filename (render.rs#L304-L307 and #L348-L351). A filename containing ;, " or = could inject a second header parameter that some browsers prefer over the intended one.

For example:

select 'csv' as component, 'report.csv; filename*=UTF-8''''evil.html' as filename;
select 1 as a;

produced two parameters, the injected one being agent-preferred:

content-disposition: attachment; filename=report.csv; filename*=UTF-8''evil.html

Fix: build the header with actix-web's structured ContentDisposition type, so the filename is always a single, properly quoted/escaped value:

content-disposition: attachment; filename="report.csv; filename*=UTF-8''evil.html"

A compliant parser (and actix's own ContentDisposition::from_raw) now sees exactly one inert filename value.

Both components share the new attachment_with_filename helper, so the fix is in one place.

Proof

New test test_csv_filename_header_injection parses the response header with ContentDisposition::from_raw (same logic a browser uses) and asserts there is no injected filename* and the payload stays inside a single filename.

Fails on main:

attacker injected a separate filename* parameter: "attachment; filename=report.csv; filename*=UTF-8''evil.html"
test result: FAILED. 0 passed; 1 failed

Passes with the fix, and the full tests/mod.rs suite stays green (64 passed; 0 failed), including the existing test_download_data_url which still asserts attachment; filename="my text file.txt".

cargo fmt --all and cargo clippy --all-targets --all-features -- -D warnings are clean.

Scope / severity

The filename is normally chosen by trusted SQL, so this matters only when an app interpolates untrusted data into a `csv`/`download` `filename`. No SQL change is required by users; CHANGELOG updated.