「セッション」タグアーカイブ

2005-05
14
16:04:00
いっぱい叩かれてしまった訳ですが


トラックバック頂いて気付きましたが、naoyaさんとかishinaoさんといった大御所の皆さんに先日の記事内容について、かなーり叩かれているみたいです。
naoyaさんとこのコメントなんかでは「指摘した人のオナニーのようなw(記事)」とか言われちゃってますし(泣
などと多少なりとも落ち込んでしまったので、おちゃらけで書き始めてしまいましたが、まずは色々ご意見ありがとうございました。
お二人の記事やコメントを拝見するに、「この程度のことを脆弱性と呼んで騒ぎ立てるな!」ということだと一応読ませて頂きました。
何が脆弱性で脆弱性とは言わないかは定義の問題でもあり、私の理解が間違っているなら訂正します。
私の理解ですが、ある別の脆弱性によって始めて発現する弱点があり、それがユーザーに不利益を被る可能性があるのであればそれを脆弱性といって報道などで喚起されても特に違和感は感じません。
一つには、たった一つの弱点によって攻撃がされることもあるでしょうが、複数の弱点が組み合わされて突かれるケースも結果としては同じことだからです。つまりこうした個々の表面化はしない可能性もあるリスクを一つ一つ取り除いていくのがセキュリティ確保の基本的な考え方でもあります。
次に、これを発現する元となる脆弱性(ここではCSS/XSS)はこれまで何度も様々な原因で問題となってきており、一般的には今後も同様の問題が出てくる可能性は高いと考えるべきでしょう。若しくは未だ対処されていない場合もあるやも知れず個々のユーザーでは既に条件を満たしているかも知れません。
三番目として、今回の場合はよりセキュアと広く理解されている手法は採用されておらず、次善策以下が積極的に採用されるのに理由が無いからです(アーキテクト上不能、などのケースはあるかも知れませんが)。この場合ユーザーへのインパクトはより大きくなる訳で、これをもって、より脆く弱い性質を保持していると理解しても差し支えないように思います。
同じ理由により、「POP3でも平文パスワードが流されている」といった類例は成り立たないと考えます。
とは言え所詮これは言葉の定義の問題です。
大多数がどのように理解するかなので、お前ごときがミスリードするな、と言われればそれは確かに(^^; その時は引っ込むようにします。
但し、故に「何が事実か」が十分に語られて個々の判断に足る情報が出来る限り得られることこそが重要と思っていますし、それが先の記事を結局書くことにした理由でもありました。
また簡単な感想なのですが、
「Webアプリケーション作るならセッション管理にはランダムなセッションIDぐらい使わないとなー」とか、「一応気付いたことがあったらベンダーに報告ぐらいはしておこう」というのは今日びの一般的エンジニアとしてはごく普通の感覚かとは思うのですが・・。
感性ずれてるでしょうか?私??
# なおPerlの件はセッションIDの取り扱い方について言語間で差異があるのかなという純粋な感想でしかないです。馬鹿にしたように読めてしまったとしたらすみませんでした。
今回のような件は私も初めてだったもので、考えることも多々ありました。
同様に、またご意見頂ければ嬉しく思いますので、宜しくお願いします。

2005-05
12
23:47:00
Movable Type 3.151以前のセッションハイジャック脆弱性問題


実は今年の2月頃のことですが、Movable Type 3.15を使っていた際に所謂セッション・ハイジャック脆弱性と思われる挙動を見つけてしまいました。
シックスアパート社とJVNにそれぞれ詳細とともに通知していたのですが、これが公表されたようです。

JVN:
Movable Type におけるセッション管理の脆弱性
シックスアパート:
【重要】 第三者による不正アクセスを許す危険性の対策について

こうした脆弱性がしっかりと公表され、(まだ現行の日本語バージョンではFIX版が提供されていないようですが)対処がされるのはよいことなのですが、上記の公式情報などでは詳細があまり触れられておらずユーザーに具体的なリスクが分からないようにも感じます。
少しまだ早いかなと迷うところもあったのですが、ベンダーによって告知もされたことですし一部誤った理解をされている方々もいらっしゃりそうなため、通報者として具体的な脆弱性内容を明記して啓蒙させて頂こうと思います。

Continue reading