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)
Core
Networking
Tracking
()
NEW
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.
Comment 1•13 years ago
|
||
I think we and Chrome are right here and the other UAs have a security bug....
See bug 272541 comment 20.
Reporter | ||
Comment 2•13 years ago
|
||
(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)?
Comment 3•13 years ago
|
||
It depends on which attack scenarios we're worried about.
Reporter | ||
Comment 4•12 years ago
|
||
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?
Comment 5•12 years ago
|
||
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?
Comment 6•12 years ago
|
||
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.
Comment 7•12 years ago
|
||
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. :(
Updated•9 years ago
|
Whiteboard: [necko-would-take]
Comment 8•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•