素人が居丈高にセキュリティーを語る2006年04月12日 00時59分02秒

ことの詳細はこの辺参照。CSRF 対策やる以上、IE の CSSXSS 脆弱性を考慮するべきなんじゃねーの? という議論がこの辺のサイトを中心に沸きあがっていたわけだわな。まぁ、この辺のスレッドなんかを辿ってみたりすると分かるとおり、ワンタイムトークンを使用することが CSSXSS 脆弱性による脅威を回避することになるという理由が説明できていなかったりして、微妙に香ばしかったりするわけなのであるが。

個人的にはこの件については、大岩氏によるこの辺の記事の通り、Microsoft が早急にこのバグを修正すべきなんであって、Web 開発者がどうにかする問題ではないと思っているし、実際に MS に問い合わせている hoshikuzu star_dust さまはヱラい!と思うわけですよ。

んで、高木さまの今回の記事なのですが、出だしで異様なほどご丁寧な GUI 設計に関する議論から始まっている (しかも図付きでw) ので、いったいなんのつもりだ? とか思いながら読んでいたわけですが、「ワンタイムトークン方式って何?」辺りまで読み進んだところでその理由が明快に分かりましたよ。なるほど高木さんはそういうレベルの人たち相手に分かるように説明してあげないといけないと思ってその記事を書いていらっさるわけですね。お忙しい中、本当に本当にご愁傷様です (T-T)/

。。。あのさぁ。つくづく思うんだけどさぁ。セキュリティーに関する議論に素人が首を突っ込むな、とまでは言わんからさぁ、せめて足手まといになるようなことだけは避けてくれまいか? とか思うわけですよ。確かに、いろんな物事に対して疑いを持つというのは、大切なことですよ。でもね。モノを疑うにも、優先順位というものがあるのですよ。

例えば、プログラムを書いていて、すぐには原因を理解できないバグに遭遇したときに、その原因をすぐに OS や開発環境に求めるのは現実的ではありません。たいていの場合、バグの原因は自分や、共同開発者が書いたコードにあるものです。まず疑うべきは手元のコードであるべきであり、設計上でも理論上でも API の仕様においても間違った書き方をしていないというのであれば、その結果浮き彫りになった予測される OS などのバグの存在を立証するコードを別途書いてみる、という手はずで進めるべきなのです。

今回の一件の場合、情報セキュリティー研究の権威が (個人のブログ記事とはいえ) 書いていることを取り上げて、その中の「なんとなく危なっかしそうな気がする箇所」に異論を唱え、「本当に正しい対策はこうなんだ!」という妄信の元に記事を執筆してみたものの、あっちゃこっちゃから逆に突っ込みのコメントを寄せられ、それでも考えを改められずに意固地になっている、というパターンなワケですが。だから異論を唱えてみる前に、何で自分はそれが危なっかしいと思ってしまうのかもう一度考え直してみたらどうなのかと。

確かに、IE の脆弱性を回避する方法について考えてみるというのは、場合によってはまったく無益ではないのかもしれないけど*1、セッション ID が hidden フィールドに書き込まれることに対する危険性の証明ができていないのに、わざわざ複雑でその分メンテナンス性が低下する実装方法を推奨するのは、問題の切り分けを余計に難しくする分むしろ有害だと断ぜられるべきです。

*1 : おいらの個人的見解としてはまったく以って無益だと思っているけどね。「フォーム画面を表示するリクエストを POST メソッドでしか受け付けないようにすればいい」みたいに書いてあるけど、IE の脆弱性の影響範囲を知るのはあくまで IE を記述するソースコードだけで、それがプロプライエタリなものである以上、ユーザーであるおれらに確証を得る手立てはないのだから。

コメント

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※投稿には管理者が設定した質問に答える必要があります。

名前:
メールアドレス:
URL:
次の質問に答えてください:
おいらがやっている会社の名前をひらがな4文字で。

コメント:

トラックバック

このエントリのトラックバックURL: http://harapeko.asablo.jp/blog/2006/04/12/324314/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。