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