トラックバック頂いて気付きましたが、naoyaさんとかishinaoさんといった大御所の皆さんに先日の記事内容について、かなーり叩かれているみたいです。
naoyaさんとこのコメントなんかでは「指摘した人のオナニーのようなw(記事)」とか言われちゃってますし(泣
などと多少なりとも落ち込んでしまったので、おちゃらけで書き始めてしまいましたが、まずは色々ご意見ありがとうございました。
お二人の記事やコメントを拝見するに、「この程度のことを脆弱性と呼んで騒ぎ立てるな！」ということだと一応読ませて頂きました。
何が脆弱性で脆弱性とは言わないかは定義の問題でもあり、私の理解が間違っているなら訂正します。
私の理解ですが、ある別の脆弱性によって始めて発現する弱点があり、それがユーザーに不利益を被る可能性があるのであればそれを脆弱性といって報道などで喚起されても特に違和感は感じません。
一つには、たった一つの弱点によって攻撃がされることもあるでしょうが、複数の弱点が組み合わされて突かれるケースも結果としては同じことだからです。つまりこうした個々の表面化はしない可能性もあるリスクを一つ一つ取り除いていくのがセキュリティ確保の基本的な考え方でもあります。
次に、これを発現する元となる脆弱性(ここではCSS/XSS)はこれまで何度も様々な原因で問題となってきており、一般的には今後も同様の問題が出てくる可能性は高いと考えるべきでしょう。若しくは未だ対処されていない場合もあるやも知れず個々のユーザーでは既に条件を満たしているかも知れません。
三番目として、今回の場合はよりセキュアと広く理解されている手法は採用されておらず、次善策以下が積極的に採用されるのに理由が無いからです(アーキテクト上不能、などのケースはあるかも知れませんが)。この場合ユーザーへのインパクトはより大きくなる訳で、これをもって、より脆く弱い性質を保持していると理解しても差し支えないように思います。
同じ理由により、「POP3でも平文パスワードが流されている」といった類例は成り立たないと考えます。
とは言え所詮これは言葉の定義の問題です。
大多数がどのように理解するかなので、お前ごときがミスリードするな、と言われればそれは確かに(^^; その時は引っ込むようにします。
但し、故に「何が事実か」が十分に語られて個々の判断に足る情報が出来る限り得られることこそが重要と思っていますし、それが先の記事を結局書くことにした理由でもありました。
また簡単な感想なのですが、
「Webアプリケーション作るならセッション管理にはランダムなセッションIDぐらい使わないとなー」とか、「一応気付いたことがあったらベンダーに報告ぐらいはしておこう」というのは今日びの一般的エンジニアとしてはごく普通の感覚かとは思うのですが・・。
感性ずれてるでしょうか？私？？
# なおPerlの件はセッションIDの取り扱い方について言語間で差異があるのかなという純粋な感想でしかないです。馬鹿にしたように読めてしまったとしたらすみませんでした。
今回のような件は私も初めてだったもので、考えることも多々ありました。
同様に、またご意見頂ければ嬉しく思いますので、宜しくお願いします。
2005-05
14
16:04:00
いっぱい叩かれてしまった訳ですが
2005-05
14
16:04:00
>私が言葉の定義をしても仕方ないとは思いつつ、コリジョンなどの従来の理解より弱い性質が見つかったという意味の用例なら「個人的には」違和感は無い気が。
ということなんですよねー。考えられるベストな方法よりも「脆弱」、相対的なものかと。
なので、POP3はPOP3Sよりも脆弱なんです。
といった観点からすると、今回の件も「脆弱性」といっても間違いでないと思うのですが、
では、IPAで公開されるほどのものかという
意味では、みなさん違和感を感じているのだと
理解しています。
ryuさん、始めまして。
正直悪意にしか聞いていなかった私ですが、謝っても頂き、幸い立ち直りは早い方でしたので(^^;
今後ともどうぞ宜しくお願いします。
>そういう意味ではPOP3も「脆弱」
>でしょう。経路でパスワードを覗き見する
>ことは、可能ですから。
これはレイヤーが異なる話なので、POP3の脆弱と言うのはどうかなと思うのですが、どうでしょう。
また、
>MD5,SHA1に脆弱性が見つかった。
私が言葉の定義をしても仕方ないとは思いつつ、コリジョンなどの従来の理解より弱い性質が見つかったという意味の用例なら「個人的には」違和感は無い気が。
宜しくお願いします。
「脆弱性」の使用例
MD5,SHA1に脆弱性が見つかった。
これは間違っているでしょうか？
オナニーなのでは？と書いた、当方人です。
揶揄するつもりはなく、自分もオナニー派?
なので、悪意などはなかったのですが、
面識のない方への言葉としては大変
不適切でした。ごめんなさい。
指摘されていたことは、perlうんぬんは
除いて、大変的を得ており、ぼくも
賛同です。
今回の件で、「脆弱」「セキュリティホール」
の言葉の定義を再認識させられました。
指摘のあった部分は、「脆弱」であったと
思います。そういう意味ではPOP3も「脆弱」
でしょう。経路でパスワードを覗き見する
ことは、可能ですから。
ただ、セキュリティホールではなかったと
思います。そこらへん、混同してました。
これらの言葉の解釈や感覚は人それぞれ
温度差がありますよね。
とても勉強になりました。ありがとう
ございました。
脆弱性とセキュリティホール
Movable Typeの「【重要】 第三者による不正アクセスを許す危険性の
kさん、
ありがとうございます。そう言ってもらえると救われます(嬉泣
naoyaさん、
さっき読み返してたんですが、やっぱりそこの私の書き方が悪かったんですね。煽ったようになって論点をずらさせてしまい申し訳ないです。
セキュリティはカテゴリーのように語られますが、本来はレイヤー属性だと思うので、いい議論を積み重ねられるのは私も嬉しいし楽しいですね。
こちらこそ今後とも宜しくお願いします。
ishinaoさん、
Perlの件は表現悪すぎなのと、とは言え視点として示してみて識者の意見が欲しい点があり、後で書き直してみます。指摘などありましたらまたお願いします。
また記事で記載した通りなのですが、単純に「一般的に考えうる可能な方法が取られていなければ脆弱性と呼ばれても仕方ない」ところの切り分けなのかと推察します。
まあこの「一般的」というところが問題な訳で。私や私の周りの人間であればそう判断する、または特に客相手だとかなり突っ込まれかねない(本当に煩い人は煩いので)といった感覚からの判断だったりしてます。
[MT][セキュリティ][脆弱性] Re:「ここギコ！: MovableType脆弱性の話」 (16:49)
個人的には（そこまで重大かどうかは別として。緊急度は「低」だと思う）やっぱりこれは脆弱性といってよいのでは、と思います。
まあそう考える人もいるでしょう。元報告者の方およびその報告を受けて対応した方々はそう考えているんでしょうし（でもシックスアパート自体は「脆弱性」ではなく「危険性」と書いているんですけどね。その辺の言葉の選択もビミョー）。
ただ、Webアプリケーションで認証状態を維持する方法としては、一般的にCookieが利用されるものです。そのCookieにどのような情報が含まれるのであれ、そのCookieが漏れた場合は、ある程度の期間において認証状態が乗っ取られる可能性が発生することになります。
そのCookieによる認証をどの程度の期間有効にするかはWebアプリケーションの設計によりますが、ブラウザセッション（ブラウザを閉じるまで）を越えて有効な認証状態を継続するようなアプリケーション（MTでいうところの「情報を登録する?」オプションがあるもの）では、無期限とまでは言わないまでもかなりの期間、認証が有効な状態が継続するでしょう。
そして現在のところ、WebアプリケーションでHTTPセッション（1回のサーバーへのアクセス）を越えて状態を維持する手段としては、機能性・利便性・安全性のバランスにおいてCookieよりも妥当な方法がありません。より安全なSSL＋secure Cookieを利用する方法や、証明書やハードウェアキーなどを利用した方法は、現時点ではいつでも使える手段とはなっていません（もちろんより安全性が必要な場合は、それらを選択するべきでしょうけど）。
つまり、現在一般的なWebアプリケーションで（特にブラウザセッションを越えて）認証状態を継続しようとした場合は、多かれ少なかれ今回movable typeの認証Cookieが持っていたような危険性を持たざるをえないわけです。で、Webアプリケーション側では、漏れたら危険な認証情報をCookieに持たせる代わりに、Cookieが第三者に漏れないようなアプリケーションの設計にするわけです。Cookieが漏れないようにする（入り口に鍵をかける）ことによって、安全性を確保するわけですね。
もちろんCookieがそれほど安全なものでないことは、XSSやブラウザ自体が持つ脆弱性、盗聴の危険性などから、ある程度知られています。そして、そのような危険性への回避策もいろいろとあります。ただし安全性を高める回避策は基本的にはSSLとの組み合わせとなってしまう（利便性が損なわれすぎる）ため、一般向けのアプリケーションではそれに依存した設計はできません。
というわけで、現在のところ「Cookieにはある程度秘密の情報を保存してもいいが、その代わり第三者にCookieが漏れないような設計にする（漏れた場合はそれは脆弱性である）」というWebアプリケーションの設計方針は、（それほど重要ではない情報・機能を扱うWebアプリケーションにおいては）妥当なものだと考えています。おそらく現在稼働しているWebアプリケーションで、そのような設計方針の下に作成されたものは非常に多いのではないでしょうか。
で、私はmovable typeにおいても、基本的には（扱っている情報・機能とのバランスを考えて）上記のような設計は「あり」だと思います。つまり、「Cookieが漏れるような穴がない限りは、Cookieに秘密情報を保存していること自体は問題にならない」という考えです。ただし、より安全性を重視した設計にするならば、Cookieに保存する情報の内容自体ももっと安全な（漏れたときの影響が小さい）ものにするべきだとも思いますけど。
movable typeのような使われ方をしているWebアプリケーションでは、SSL必須にするわけにはいかないでしょうから、今回の問題を解決する方法としては、おそらくランダム性の高い（少なくともAtom APIでは使えない）認証キーをCookieに保存するようにするのでしょう。それでも「情報を登録する?」オプションが存在する限りは、その認証キーはある程度の期間有効でしょうし、その認証キーが漏れた場合はWeb管理ツールを乗っ取られる危険性があります。Cookieに登録されている情報の内容に限らず、「Cookieが漏れたら危険である」わけです。つまり重要なのは「Cookieが漏れるかどうか」であって「Cookieに記録されている情報」の方ではない、と考えるわけです。
と、なんか長々書いてきたけど、うまい締めが思いつかないんで、ひとまず「まあそういうことなんですよ」って感じで終わっておく。それにしても俺は別に「MTスキー」でも「セキュリティスキー」でもないのに、なんでこんなに一生懸命説明しているんだろうなー。
私もこの件を「脆弱性」と判断して報告したROCAさんの行動自体は問題ないと思います（ただ、前の記事のPerlに関する発言はちょっと問題があると思う）。
ただそれが最後まで「脆弱性」として扱われるのは、私の感覚とはずいぶん違っているので、そのあたりのずれを修正（あるいは私の方の感覚が間違っているならそれを修正）するために、あのような記事を書いています。
ごめんなさい、僕も最後のPerlの記事云々というところをみてちょっと過剰に反応してしまったかなとも思います。
結果的にはよかったんじゃないでしょうか、何をもって脆弱性とみなすかみたいな濃いい議論に発展させることもできたわけですし、僕自身も勉強になりました。
今後ともよろしくお願いします。
脆弱性かどうかは別にして、こういう報告をする人は素敵だと思います。