Content-Disposition
15.5 Content-Disposition Issues
RFC 1806 35, from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very
serious security considerations. Content-Disposition is not part of
the HTTP standard, but since it is widely implemented, we are
documenting its use and risks for implementors. See RFC 2183 49 (which updates RFC 1806) for details.
19.5.1 Content-Disposition
The Content-Disposition response-header field has been proposed as a
means for the origin server to suggest a default filename if the user
requests that the content is saved to a file. This usage is derived
from the definition of Content-Disposition in RFC 1806 35. content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" ( token | quoted-string )
An example is
Content-Disposition: attachment; filename="fname.ext"
The receiving user agent SHOULD NOT respect any directory path
information present in the filename-parm parameter, which is the only
parameter believed to apply to HTTP implementations at this time. The
filename SHOULD be treated as a terminal component only.
If this header is used in a response with the application/octet-
stream content-type, the implied suggestion is that the user agent
should not display the response, but directly enter a `save response
as...' dialog.
See section 15.5 for Content-Disposition security issues.
Content-DispositionレスポンスヘッダーフィールドはRFC 2616で定義されました。
Content-Dispositionレスポンスヘッダーフィールドはユーザーがファイルを保存するコンテンツを要求する意味として提案しました。この使用法はRFC 1806でContent-Dispositionの定義から派生しました。
受信しているユーザーエージェントはfilename-parmパラメーターで任意のディレクトリパス情報にするべきではない。filenameはターミナルコンポーネントとして扱うべき。
もしこのヘッダーがapplication/octet-stream content-typeでレスポンスを使うなら、暗黙の提案はレスポンスを表示するべきでないユーザーエージェントになるが、「レスポンスを名前を付けて保存...」ダイアログに直接入力します。
Content-dispositionはHTTP標準ではないが、多くの場所で実装されています。それと同時にリスクが存在します。
もしdispositionタイプがattachmentなら、これはローカル上のレスポンスを保存するユーザーを促すべき受信者を示します。
Bodypartsはメールメッセージのメインボディから分けることを示す`attachment' を指定することができ、表示は自動にするべきではなく、ユーザーのいくつかの行動に依存します。MUAはアタッチメント、ターミナルキャラクター上、表示もしくはストレージを選択できるユーザーからのアタッチメントのリストに象徴的な表現によってビットマップターミナルのユーザーを代わりに与えます。