Open Bug 671204 Opened 13 years ago Updated 2 years ago

handling of missing disposition types in Content-Disposition header field

Categories

(Core :: Networking, defect, P5)

defect

Tracking

()

People

(Reporter: julian.reschke, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [necko-would-take])

See <http://greenbytes.de/tech/tc2231/#attmissingdisposition2> and <http://greenbytes.de/tech/tc2231/#attmissingdisposition3>: Content-Disposition: x=y; filename=foo.html Content-Disposition: "foo; filename=bar;baz"; filename=qux In both cases, Firefox parses the component before the first semicolon as an unknown disposition type, and thus defaults to "attachment". Other UAs with the exception of Chrome just ignore the header field.
I think we and Chrome are right here and the other UAs have a security bug.... See bug 272541 comment 20.
(In reply to comment #1) > I think we and Chrome are right here and the other UAs have a security > bug.... > > See bug 272541 comment 20. If we are truly concerned about security, shouldn't we consider this as a message we want to drop completely (just as recently introduced for conflicting C-Ls and friends)?
It depends on which attack scenarios we're worried about.
Here's an example of where the behavior of FF is harmful; in that it "understands" a broken header field that is rejected by other browsers: http://stackoverflow.com/questions/11574199/file-download-name-in-chrome/11575090 Maybe we should consider to keep the current behavior of defaulting to "attachment", but at least throw away the filename information?
Given that all other browsers now seem to ignore the C-D header when it's malformed (see http://greenbytes.de/tech/tc2231/#attmissingdisposition and the half-dozen tests below it) I'm much more inclined to ignore malformed C-Ds (i.e. treat them as inline) and not worry about the security angle (i.e that we should assume malformed == site might have wanted 'attachment' semantics). bz:biesi: thoughts?
To be more precise: We would also still fail replies as CORRUPT if they had multiple CDs (including malformed ones) that differ. If only one CD header value is present and is malformed we'd ignore it, which results in 'inline' (i.e. as if no CD header were present). That's fairly straightforward to implement since the logic that compares CD values happens at a different, earlier point than the MIME parsing for them.
I still think that rendering stuff inline when we're not sure is going to open up sites to XSS bugs... but I guess if other UAs are all doing it anyway the battle may be lost. :(
Whiteboard: [necko-would-take]
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.