wgetの--content-dispositionが脆弱じゃないことを確認した

これ実は脆弱で任意のファイル上書きできちゃうんじゃねって思って調べたけど大丈夫だった。
たとえば以下みたいな感じで./tmp/hogehoge.txtってpathのContent-Dispositionに設定しても、hogehoge.txtってのがカレントディレクトリに生成されるだけ。

#!/bin/env ruby
require 'webrick'

srv = WEBrick::HTTPServer.new(:BindAddress => '127.0.0.1', :Port => 20080)
srv.mount_proc("/test"){ |req, res|
  res["Content-Disposition"] = 'attachment; filename="./tmp/hogehoge.txt"'
  res.body = "test"
}
trap("INT"){
  srv.shutdown
}
srv.start

実行例

$ wget --content-disposition http://localhost:20080/test
--2012-11-06 15:34:35--  http://localhost:20080/test
Resolving localhost... 127.0.0.1, ::1, fe80::1
Connecting to localhost|127.0.0.1|:20080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4
Saving to: `hogehoge.txt'

100%[=========================================>] 4           --.-K/s   in 0s      

2012-11-06 15:34:35 (651 KB/s) - `hogehoge.txt' saved [4/4]

追記:
fuba博士いわく「RFC にも将来的にはオプションでありえるかもしれんけど今はディレクトリとか対応するのやめとけって書いてあった」って書いてあったので調べてみたら

   It is important that the receiving MUA not blindly use the suggested
   filename.  The suggested filename SHOULD be checked (and possibly
   changed) to see that it conforms to local filesystem conventions,
   does not overwrite an existing file, and does not present a security
   problem (see Security Considerations below).

   The receiving MUA SHOULD NOT respect any directory path information
   that may seem to be present in the filename parameter.  The filename
   should be treated as a terminal component only.  Portable
   specification of directory paths might possibly be done in the future
   via a separate Content-Disposition parameter, but no provision is
   made for it in this draft.

http://www.ietf.org/rfc/rfc2183.txt

移植性のあるディレクトリパスの指定方法はいつか未来にやる予定みたいなことが書いてあるな。あと既存のファイルを上書きしないよーに提案をしてる感じかな。このドラフトでは。

追記2:
fuba博士にさらにご教授頂いてHTTP/1.1はこっちのRFCとのこと

   o  Recipients MUST NOT be able to write into any location other than
      one to which they are specifically entitled.  To illustrate the
      problem, consider the consequences of being able to overwrite
      well-known system locations (such as "/etc/passwd").  One strategy
      to achieve this is to never trust folder name information in the
      filename parameter, for instance by stripping all but the last
      path segment and only considering the actual filename (where 'path
      segments' are the components of the field value delimited by the
      path separator characters "\" and "/").

http://tools.ietf.org/html/rfc6266#section-4.3

さっきと同じようなことが書いてあって、/etc/passwordみたいなファイル上書きされるとやべぇだろ? それに対する一つの戦略として、filenameパラメーターのフォルダ名の情報をけして信用するなと。たとえば「for instance, stripping all but the last path segment and only considering the actual filename」ってことでファイル名の最後の部分のみを採用する、みたいな