[tahoe-lafs-trac-stream] [tahoe-lafs] #827: Put file download links ('?save=true') in WUI directory listings
tahoe-lafs
trac at tahoe-lafs.org
Tue Aug 13 23:00:07 UTC 2013
#827: Put file download links ('?save=true') in WUI directory listings
-------------------------+-------------------------------------------------
Reporter: | Owner: davidsarah
davidsarah | Status: assigned
Type: defect | Milestone: 1.12.0
Priority: major | Version: 1.5.0
Component: code- | Keywords: security usability capleak docs
frontend-web | download easy
Resolution: |
Launchpad Bug: |
-------------------------+-------------------------------------------------
Changes (by daira):
* milestone: 1.11.0 => 1.12.0
Old description:
> Typical behaviour of web browsers for a retrieved over HTTP[S], is to
> decide based on its inferred MIME type whether to display it, pass it to
> some plugin/helper app, or treat it as a download (either pass it to a
> download manager or prompt the user to save it locally). The inferred
> MIME type is arrived at by rules that '''no-one''' understands; the HTTP
> spec says that the HTTP Content-Type takes precedence, but browsers
> deliberately violate that in some cases, and the result can even vary
> nondeterministically depending on network delays.
>
> Sometimes it's useful to override this behaviour and force the browser to
> treat the file as a download, regardless of its inferred MIME type. This
> can be done using the Content-Disposition HTTP header, e.g. "Content-
> Disposition: attachment; filename=suggested_name".
>
> (Well, not actually force, but strongly hint. I think all the common
> browsers now implement this; IE has had some bugs
> http://support.microsoft.com/kb/279667 but I think they are all pre-IE6.)
>
> Content-Disposition is specified in:
> * http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1
> * http://tools.ietf.org/html/draft-reschke-rfc2183-in-http-00
>
> (The "very serious security considerations" mentioned in
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.5 are
> scaremongering. A server can't do anything with {{{Content-Disposition:
> attachment}}} that can't also be done via the MIME type.)
>
> To close this ticket,
> * add an optional parameter to the webapi that will force a download.
> * modify Tahoe directory listings to include 'download' and 'view'
> links.
>
> Note that if the most prominant link for a non-directory file was the
> download link, that would allow the WUI to be used from a browser (with
> some care on the part of users) without necessarily being vulnerable to
> the same-origin attacks described in #615. Users would only be vulnerable
> to these attacks if they click the view link, or if they view the
> downloaded local files in a browser that treats all file URLs as same-
> origin (or has some other related bug such as
> http://www.mozilla.org/security/announce/2009/mfsa2009-30.html ).
New description:
Typical behaviour of web browsers for a retrieved over HTTP[S], is to
decide based on its inferred MIME type whether to display it, pass it to
some plugin/helper app, or treat it as a download (either pass it to a
download manager or prompt the user to save it locally). The inferred MIME
type is arrived at by rules that '''no-one''' understands; the HTTP spec
says that the HTTP Content-Type takes precedence, but browsers
deliberately violate that in some cases, and the result can even vary
nondeterministically depending on network delays.
Sometimes it's useful to override this behaviour and force the browser to
treat the file as a download, regardless of its inferred MIME type. This
can be done using the Content-Disposition HTTP header, e.g. "Content-
Disposition: attachment; filename=suggested_name".
(Well, not actually force, but strongly hint. I think all the common
browsers now implement this; IE has had some bugs
http://support.microsoft.com/kb/279667 but I think they are all pre-IE6.)
Content-Disposition is specified in:
* http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1
* http://tools.ietf.org/html/draft-reschke-rfc2183-in-http-00
(The "very serious security considerations" mentioned in
http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.5 are
scaremongering. A server can't do anything with {{{Content-Disposition:
attachment}}} that can't also be done via the MIME type.)
To close this ticket,
* add an optional parameter to the webapi that will force a download.
* modify Tahoe directory listings to include 'download' and 'view' links.
Note that if the most prominant link for a non-directory file was the
download link, that would allow the WUI to be used from a browser (with
some care on the part of users) without necessarily being vulnerable to
the same-origin attacks described in #615. Users would only be vulnerable
to these attacks if they click the view link, or if they view the
downloaded local files in a browser that treats all file URLs as same-
origin (or has some other related bug such as
http://www.mozilla.org/security/announce/2009/mfsa2009-30.html ).
--
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/827#comment:17>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list