前田です。

アプリケーションだと比較的判断しやすいと思うのですが、ライブラリ
だとどういう使われ方をするかわからないのでuntaintは慎重に行った
方がいいかもしれないですね。
dupしないでuntaintしたりすると、思わぬところで使われていて問題
になったりしそうですし。

Yukihiro Matsumoto wrote:
> |べつに証明を求めているわけではありませんが、なぜ問題が起きなさそうなの
> |か、おおざっぱな理屈は知りたいと思っています。
> 
> redirect文字列はURI.parseで分解される。分解された各要素のう
> ち、address(host名)とport はTCPSocket.newに渡される。
> TCPSocket.new()は(現状では) untaintedな文字列を要求している
> が、host名は存在するホスト名ならば接続に成功するし、存在しな
> いホスト名ならばたんに接続に失敗するだけ。port も存在するサー
> ビス(またはポート番号)ならば成功し、存在しなければ失敗するだ
> け。なので、これらについてはtaintedであることを保存しなくて
> も(チェックをバイパスしても) 信頼性に変化はない。URI の残り
> の部分はopenしたソケットを介してサーバに送りつけるだけで、送
> 信はtaintの有無にかかわらず成功するので、これもuntaintしても
> 同じである。

redirect先との通信が成功するかどうかではなく、redirect先との
通信が何らかのセキュリティ上の問題を引き起こす可能性があるか
どうかを判断の基準にするべきではないでしょうか。
たとえば、仮にopen-uriがPUTをサポートしたとしたら、無条件に
untaintしてredirectするのはまずいですよね。
# RFC2616でもredirectはGET/HEADのみということになってますが。

open-uriの場合は、

        unless OpenURI.redirectable?(uri, redirect)
          raise "redirection forbidden: #{uri} -> #{redirect}"
        end

でredirectが妥当かどうかをチェックしているので、何らかの危険性
があると判断されるようなredirectはここで蹴って、その後でuntaint
するのがよいのではないでしょうか。

-- 
前田 修吾