Journal InTime

_ WASフォーラム　第5回コンファレンス

7/5のWASフォーラムのコンファレンスで「Ruby on Railsのセキュリティ」というテーマでお話することになりました。

_ Webアプリケーションセキュリティフォーラム

というわけで、発表して来た。

• スライド(PDF)
• スライド原稿(RD)

自分の発表はともかく興味深い話を色々聞けてよかった。 とくに奥さんと高木先生のバトルが面白かった。

追記:

リクエストがあったのでバトルの内容について少し。 (曖昧な記憶に基づく再現で言い回しは違うと思うし、内容にも私の勘違いがあるかもしれません。念のため)

高木先生

Greasemonkeyの説明の部分がよく聞こえなかったんですが。

奥さん

(内容を説明)

高木先生

ええと、「クッキーが漏洩する程度なので問題ない」と聞こえたような気がしたんですが。

私の心の声

(最初から聞こえてたんじゃ…)

奥さん

ローカルファイルにアクセスできたり、任意のコマンドを実行されたりするのに比べれば、ということですね。

高木先生

いや、それは違うと思うんですよ。銀行サイトのクッキーが漏洩したら非常に危険ですよね。同じことをトロイの木馬などで実現するのは相当コストがかかると思うんですが、Greasemonkeyスクリプトでは簡単に実現してしまうわけで、非常に危険だと思います。

奥さん

スクリプトを有効にするドメインを指定できますので、ある程度対策は可能です。

高木先生

私はGreasemonkeyスクリプトのようなものは、スクリプトの内容が読める人が使うものだと思っています。

他にも、JSONPの脆弱性の対策手法は汚いと思うがそもそもJSONPみたいなもが必要なんですか?とか、全ユーザのトラッキングじゃなくて視聴率調査みたいに了解を取った上で何%かのユーザを対象に調査すればいいんじゃないですか?とか、IPアドレスによるトラッキングなんて本当にできるんですかとか?とか面白い応酬が続いていた。

おおざっぱに議論をまとめると、セキュリティと利便性のトレードオフの話ということになるのかな?

さらに追記:

すみません、やっぱり記憶違いがあったようです。 高木先生からのツッコミを引用します。

銀行サイトの件は「cookieが漏洩したら」ではなく、cookie漏洩なしにGreasemonkeyスクリプトならその場でアレコレできちゃって激ヤバ （以下「同じことをトロイで実現するのは面倒だが…」に続く） という話をしたのでした。

[HiromitsuTakagiのブックマークより引用]

_ A Theory of Objects読書会

A Theory of Objects (Monographs in Computer Science)

松江オープンソースラボでA Theory of Objectsの読書会。 といっても、Aさんとまつもとさんと私の3人だけだけど。

Reviewの"2. Class-Based Languages"までAさんに解説してもらったけど、Reviewまでは何とかついていけそう。 Part I以降は式ばっかりでコードが出て来ないのでつらそうだな。

covariance/contravariance/invarianceについて、ある型について

• getのみだったらcovariance
• setのみだったらcontravariance
• get/set両方あったらinvariance

という整理はすっきりしていると思った。

だからメソッドの場合は、戻り値についてはcovarianceを、引数についてはcontravarianceを適用する(つまりSather方式)のが、型システムの安全性を考えると一番自然である。

あとで思い出したけど、Javaの配列型はget/set両方あるのにcovariantなので(本当はinvariantであるべき)型安全性が破綻しているんだな。 配列型で型安全性が破綻していること自体はずっと前に気付いてたんだけど、理論的に整理されてすっきりした。今まで感覚的にsubtype is-a supertypeであるためには…と考えてたんだけど。

この話をパラメタ付型(generic type)に一般化すると、ある型パラメタについて、型パラメタがgetにしか使われない(メソッドの戻り値にしか現れない)ならcovariant、setにしか使われない(メソッドの引数(正確にはin引数)にしか現れない)ならcontravariant、get/set両方ならinvariantであるべきということなんじゃないだろうか。 Reviewをざっと眺めたところではそういう話はなかったけど、後の方で出て来るのかな。 実際にはinvariantな言語が多い気がするけど、そういう言語ってあったっけ。

あと、Betaのinner(superの逆)も面白そう。CLOSのメソッドコンビネーションのaroundみたいな使い方になるらしい。でも単一継承だと(mixinできないので)設計が難しそうだな。

何はともあれ、今回の勉強会が今までの勉強会で一番ラボっぽかった気がする。 次回は7/24(火)なので参加したい人がいたら私に連絡ください。 ついてくのはしんどいと思いますが。

_ Java Genericsに見るvariance

20070710のみずしまさんのコメントより:

Java Genericsでは型のユーザがvarianceを指定できるように
なっています。

ほう。 そういえば、最近のJavaはcovariant return typeもサポートしているそうですね。

型パラメータを? extends Tという形で記述することによって、
covariantな型になります。

List<Integer> ints = new ArrayList<Integer>();
ints.add(1);
List<? extends Number> nums = ints; // OK
nums.add(2); // NG

なるほど、面白い。 一瞬型安全じゃないのではと思ったのですが、配列の時のように実 行時にArrayStoreExceptionのような例外が発生するわけではなく、 コンパイル時にエラーになるんですね。

でもList<? extends Number>がList<Number>とcompatibleでない(null以外のaddができないので当然)のが、使い勝手的にどうなんだろう。 参照しかしない部分では(List<Number>ではなく)List<? extends Number>を要求するようなインタフェイスにするというスタイルでコーディングすれば、List<Integer>を渡せるわけだけど、そういう書き方は一般的なのかなあ。