|主に精神論http://subtech.g.hatena.ne.jp/mala/20110624/1308881526http://b.hatena.ne.jp/entry/http://subtech.g.hatena.ne.jp/mala/20110624/1308881526「使い方の問題」とか「こういうコード書いてるなら他にも問題がある」という反応がいくつかある。Resigからの最初の返事もだいたいそんな反応だった。$()関数に渡している全てのWebサイトやjQueryを使ったライブラリにはXSS脆弱性があります」と、書いたのは、単に事実をそのまま述べただけであって、俺はこの問題を「入力値をそのまま$()に渡すのが悪い」「バリデーションやエスケープをしないのが悪い」というふうに考えていない。ようにprefixが付いていたり、location.hashをそのまま使う場合でも、location.hashは#で始まることが保証されている(idセレクタとして動作することが期待されているが、ライブラリ使用者が想定しているidセレクタとして動作する条件とjQueryの仕様が合致していないという問題)。それは、リンク先のサンプルとか実例とか見てもらえればわかると思う。Elementが生成されるという可能性について想定していない。idセレクタかCSSセレクタで、DOM生成する機能はないし、$()にDOM生成の機能があること自体を知らない可能性だってある。HTMLっぽい文字列を渡せばDOM生成した上でappendChildされる。$()でDOM生成する機能を知らなくたってjQueryを使うことは出来る。使う側の問題でしょ、という考え方は、使う側に何かしらの過失があったならば、どんなひどい目にあっても仕方ないみたいな考え方が根底にあるように思える。それはとても危険な考え方であるように思う。人によっては「生肉焼かないで食ったら腹壊して当たり前でしょ、死んでも文句言えないわ」ぐらいに捉えているかもしれない。俺の感覚だと「パスタのゆで時間を間違えて料理が不味くなるのは仕様だけど、ゆで時間間違えて人が死んだらおかしいわ」ぐらい。単なるバグやエラーと、セキュリティ上の問題は切り分けて考えないといけない。ライブラリを設計する際は、想定外の値が入力されて「エラーを引き起こす」ことがあっても、それが致命的な脆弱性にならないように配慮されているべきだ、と考える。いう風になっていない事例はたくさんあるし、セキュリティに関する話で言うと、インジェクション系の話は大体そういう問題だ。ライブラリの仕様がイケていない、けれど使う側の注意や努力でカバーできてしまうために、責任転嫁され問題が先送りされてしまう。jQuery側を修正しても多くのライブラリには「入力値を検査していないことで想定されていないHTML要素が選択される可能性がある」というバグが残るけれど、それは単なるバグであって、特殊なケースでなければ脆弱性にはならない。注意すれば防げる、俺ならそんなミスはしない、というのは戯言であって何の役にも立たない。バグはあって当たり前、バグがあっても脆弱性にならないようにすることを考えたほうがいい。