自前サーバの耐久性低くて済みません>読者のみなさま。自体は割とすぐ重くなりますね......。CSSXSS*1のIEのバグ挙動の性質が整理されてきたようです。言っても所詮IE6の実装バグに起因する挙動なんで、性質を推定してもそれが本当に正しいのかは観察の積み上げというレベルでしかわからないという嫌な状況ではあります。読んでいて、僕の中では大分問題の所在が整理されてきた感じです。対策は直交している(この表現、えむけいさんから拝借)。対策の手法には依存せず共通である。取得するように改変する。読み取り可能データ領域に入らないように「巧妙に」エンコードしてやる。(この辺り、今回の各議論の皆様の知見を大いに参考)。この辺りの議論、特に後者に関してはIE6のバグ挙動の正確で網羅的な検証が必要。対策はこれまで通り、攻撃者の知り得ない何らかの値を付加認証情報としてフォームに含める。フォーム入力に付加」でよい。攻撃を受けるため、どれも危険になる。この1点に関しては、「いわゆる高木方式」を含む各手法間の優劣は存在しない。攻撃に対して安全になる。IDが直接漏れるのは怖い」、という意見は(「怖い」という感情的な表現のレベルなら)心情的には一応理解できる。よる「間接セッション乗っ取り」の危険性*3を過小評価しており、不適当であると私は考える。ハッシュで十分と考えられる。安全な情報を用いる必要がある。用いた「いわゆる高木方式」や、「高木方式ハッシュ適応版」より遥かに危険である。*5といった感じになりますね。みなさま貴重なご意見ありがとうございます。興味深い問題ではあるんで、キチンと対策を考えてみたいとは思っていますが、仕様の明示できないバグ挙動の回避は、ある意味いくら考えても他に抜け穴のある可能性が否定できないんで、微妙ではあるんですよね。件ではソースファイルがあったのである意味で挙動は正確に把握できたのですが、IEに関しては完全にブラックボックスなので、思いついた攻撃の範囲にどうしても限定されてしまうんですよね......。lead相変わらず情報セキュリティ以外のネタ満載な(笑)セキュリティホールmemoより。ある(よくあっちゃ困るけど)不幸な混入話かと思っていたら、そんなレベルじゃなかったらしい。cent.99%鉛って、要するにこの手の安価な物品の加工材料としてはほぼ純鉛ってことですよね。そんなものが作れるんだ......。確かに鉛は溶かすの簡単だけどね......。想定していた正規の材料によっては比重で判りそうな気もするけど、検収者は気付かなかったのかねぇ。あちこちで言われている通り、この呼び名もイマイチですね。関係無いんですが......。ハッシュが漏れたらそれだけでアウトなんで、その認識がないと却って心理ファクタの油断の分だけ危険。通常のCSRF以上に強力であることにも留意すべき。ID自体の推測不能性が十分であるならば無視できる。実装上大きな問題になるとは考えられない。合わせて160ビットにしておけばよい。同一の値が複数箇所で用いられる可能性が有意にあり、一致が外部から推測できては困る場合(これもパスワードとか)に限られ、本件では該当しない。)、それを越える場合は160bitとなる。それしか方法がない)、とかやると却って危いよー」という主旨。メッセージはE-mailアドレスを除いて公開されることがあります。