ruby-dev

In article <42CF1918.5000603@ruby-lang.org>,
  Shugo Maeda <shugo@ruby-lang.org> writes:

> たとえば、RFCではredirect先にPUTしてはいけないことになっている
> わけですが、仮にPUTがredirectされたとすると、本来はIPアドレス
> ベースでPUTが制限されているURLにデータの書き込みをさせることが
> できてしまったりする危険性がないでしょうか。
>
> OpenURI.redirectable?の仕様が明らかになっていて、redirect先の
> URLが一定の条件をみたす場合にuntaintしてredirectされることを
> ユーザが理解して使うのであれば、問題ないように思います。

いろいろと考えているのですが、untaint することによってどんな安全性を
失うのかを把握できた気になりません。そのため、OpenURI.redirectable? が
その失った安全性をどの程度回復できるのか判断できません。

たとえば、OpenURI.redirectable? はメソッド (GET, PUT, etc.) を受け取ら
ないので、上であげられた PUT の危険性は防げず、別のコードを書くことに
よって防がなければならないように思います。つまり、その危険性は
OpenURI.redirectable? では回復できません。もちろん、PUT の redirect を
防ぐためにはそのためのコードを書けばいいわけですが、失われる安全性はそ
れだけとは限りません。

そして、仮に untaint するにしても潜在的に失われる安全性を少なくするよ
うにしたいところですが、taint 機構が提供する安全性をいま把握した気にな
れないため、どう untaint するのがより安全かがわかりません。

> ユーザが最初にopen-uriに渡すURLがtainted?でないということによって、
> open-uriがredirect先のURLをuntaintすることを是認したと判断
> できるわけですから。
> 
> 仮にPUTが無条件にredirectされたとしても、ユーザがそのことを
> 理解して使う(たとえばredirect元URLを無条件に信頼してよいと
> 判断したとか)のであれば、(少なくともライブラリ側としては)
> 問題ないように思います。

ドキュメントは開発者のいいわけとして重要ですが、できればいいわけ不要な
ほうがいいと思っています。

> ライブラリがuntaintする際のおおざっぱな指針としては、
>
> (1) untaint前には明らかな危険性はチェックによって排除する。
> (2) どのようなデータが自動的にuntaintされ、どのような処理に
>     利用されるかをドキュメントに明記し、ユーザがライブラリ
>     に渡したパラメータがtainted?でないことによって、リスク
>     を受け入れたと判断する。
>     (ただし、(1)によるチェックでuntaintが無条件に安全である
>     と判断できる場合はドキュメントに記述する必要はない。)
>
> といったところでしょうか。
> # 問題があればご指摘ください。

根本的なところで、taint 機構が対象としている危険性とはなにか、というと
ころがよくわかりません。

perl が参考にならないか、と思って perlsec を読んでみたりもしたのですが、
あっちは read mode の open が許されていたり、想定されている危険性が違っ
ている気がしました。
-- 
[田中 哲][たなか あきら][Tanaka Akira]

Thread

Prev Next

In This Thread

Prev Next