Skip to main content

Last Call Review of draft-ietf-httpbis-content-disp-
review-ietf-httpbis-content-disp-secdir-lc-orman-2011-04-06-00

Request Review of draft-ietf-httpbis-content-disp
Requested revision No specific revision (document currently at 09)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-03-15
Requested 2011-03-03
Authors Julian Reschke
I-D last updated 2020-01-21 (Latest revision 2011-03-28)
Completed reviews Secdir IETF Last Call review of -?? by Hilarie Orman
Assignment Reviewer Hilarie Orman
State Completed
Request IETF Last Call review on draft-ietf-httpbis-content-disp by Security Area Directorate Assigned
Completed 2011-04-06
review-ietf-httpbis-content-disp-secdir-lc-orman-2011-04-06-00
Security Review of 

Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol 
  (HTTP)

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG. These comments were written primarily for
the benefit of the security area directors. Document editors and WG
chairs should treat these comments just like any other last call
comments.

The document specifies the syntax of the content-disposition field and
its parameters for http responses.  It is based on the MIME
specification for the same field.

The Content-Disposition header supports a parameter called "filename",
the recommended name for saving the content.  That feature is just
plain dangerous.  A good many exploits are based it.  But, it's not
really the fault of the protocol.  Protocols don't kill people, people
clicking "yes" kill themselves.

The document is clearly written, and it does point out many of the
dangers inherent in trusting arbitrary filenames and file extensions.
However, I think that this feature will continue to be a major source
of vulnerabilities.  

From a security viewpoint, I think the protocol should restrict
filenames to ascii alphabetic characters (no "." or "/"), and that if
the filename does not conform, the receiver SHOULD reject the message
and send an error code back to the sender.  The sender should not be
allowed to specify a file extension.  The receiver SHOULD write the
files into a quarantined disk area using a temporary filename, the
file to be released to the recommended name pending manual review.
But, that would break the world, as would so many security
recommendations.

Hilarie