ruby-dev

前田です。

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

それでは、逆に安全だと判断したケース(たとえばschemeがhttpでGET/HEADのみ)
だけuntaintするようにすればよいのではないでしょうか。
# open-uriには無限ループの検出機構はないんですっけ。
それも心配ということであれば、$SAFE >= 1ではredirect先のURLが取り出せる
ような例外を発生させる、という仕様でもよいと思います。

> そして、仮に untaint するにしても潜在的に失われる安全性を少なくするよ
> うにしたいところですが、taint 機構が提供する安全性をいま把握した気にな
> れないため、どう untaint するのがより安全かがわかりません。
> 
> 
>>ユーザが最初にopen-uriに渡すURLがtainted?でないということによって、
>>open-uriがredirect先のURLをuntaintすることを是認したと判断
>>できるわけですから。
>>
>>仮にPUTが無条件にredirectされたとしても、ユーザがそのことを
>>理解して使う(たとえばredirect元URLを無条件に信頼してよいと
>>判断したとか)のであれば、(少なくともライブラリ側としては)
>>問題ないように思います。
> 
> 
> ドキュメントは開発者のいいわけとして重要ですが、できればいいわけ不要な
> ほうがいいと思っています。

taint機構は、($SAFE == 1では)完全な安全性を提供するものではなく、
なるべくうっかりミスを減らすためのものだと思います。
ライブラリの仕様(この場合はredirectされる条件)が明らかになっている
のであれば、それをどう使うかは基本的にアプリケーションプログラマの
責任ではないでしょうか。
もちろん、File.unlinkのように危険性があきらかであれば排除するのが
望ましいと思いますが、ライブラリ側ですべての危険性を考慮するのは
難しいのではないかと思います。

> 根本的なところで、taint 機構が対象としている危険性とはなにか、というと
> ころがよくわかりません。
> 
> perl が参考にならないか、と思って perlsec を読んでみたりもしたのですが、
> あっちは read mode の open が許されていたり、想定されている危険性が違っ
> ている気がしました。

このあたりはどうなんでしょう? > まつもとさん
てっきりPerlを参考にされたものかと思っていました。

-- 
前田 修吾

Thread

Prev Next

In This Thread

Prev Next