IEにつづきOperaにもCookie漏洩の穴

takunama曰く、"Net Security の記事によると、IE につづき Opera にも Cookie 情報漏洩のセキュリティ・ホールが発見されたらしいです。現在このセキュリティ・ホールが確認されているのはヴァージョン 5 だけですが、他のヴァージョンも同様である可能性が高いとのこと。 日本語ページの表示に対する正式な対応、そして日本語化ツールの公開と、やっと普及への第一歩を踏み出したところで、いきなり出鼻をくじかれたかっこうです。 なお、上記記事にはこうもあります。

本誌では(中略)Internet Explorerの利用を控えるように勧めてきた。しかしながら、こうしてOperaでも同様の問題が発覚したことにより、他のブラウザでも決して安心が出来ないことが分かる。

オープンソースでの開発によるならばこのような問題も発生しにくいと聞きますが、Mozilla などはどうなんでしょうか?"

今朝のスピーチで

[slashcow (5413)]

ちょうど今朝のスピーチでOpera６beta1を紹介したばっかりだったのに。

というのはさておいて、バージョンが進んでからこういうセキュリティーホールが見つかったということにどうしても気になってしまいます。
クッキーシステムがもともと欠陥だったのか、多機能化で複雑になって欠陥に変質したのか。
ともかく、「IE使っていないから安心だ」ということがくずれたわけで、安易にNNやOperaに乗り換えようとは言えなくなり、穴があったら入りたいです。最低限の行為としてクッキーを切って使おうということを再び守るしかないのかなと思います。

それでもIEから乗り換えれば、気持ちだけでも安心して使えるというのは、否定できないので「乗り換えてクッキーとJAVAを切って使おう」と言いふらしてしまうかもしれません。

Cookie と JavaScript を切ったら

[uxi (5376)]

状態の保存とか出来ない気がするんですが
web 経由の DB 使ったシステムとかって
どうやって動かせば良いんでしょうか、、、

少なくとも世の中にあるオンラインショッピングなんかは
ほぼ全滅ですよね、、、
# まぁオンラインショッピングするなら
# リスクはある程度覚悟するべきですが、、、

--
uxi

Re:Cookie と JavaScript を切ったら

[alfeim (1615)]

出来ますよ
Cookieを使う場合、サーバのDBに状態を何らかの方法(状態クラスをシリアライズしたものなど)を保存し、それをuniqueに識別できるキーをCookieに持たせているだけなのでそのキーをハイパーリンクのURLやFORMの飛び先URLにパラメータとして追加してやれば良いだけです。

PHP3のライブラリであるPHPLIBにはそのへんも考慮してあってCookieを切っていてもURLの記述を全部PHPLIBの関数経由で記述しておけばセッションをGETメソッドだけで記述できました。

Re:今朝のスピーチで

[Anonymous Coward]

>ともかく、「IE使っていないから安心だ」という
>ことがくずれたわけで、安易にNNやOperaに乗
>り換えようとは言えなくなり、穴があったら入
>りたいです。

崩れる以前に、そんな仮定は成立していないと思いますが？
まず先にその点を恥じるべきでしたね

Re:今朝のスピーチで

[slashcow (5413)]

そうでしたね。使い方によってはどんなブラウザでも被害を受けるという基礎的なことを忘れていたということですね。
ただ、前提はないといっても、最近のマスコミ(日経BPやZDnetなど)の論調を見ると私のように勘違いして、さも前提があるようにも見えてしまったのも何人かはいるんではないでしょうか。そう考えると乗り換えろだけでなく、
・セキュリティーホール情報を頻繁に見よ
・クッキーやJAVAは切って隙を減らそう
などのことも訴えかけていく必要があるのではないかと思います。

今思えば、ありえない前提をでっち上げでもしないと、(危険を知らずに)IEを使いつづけてしまうというジレンマを読み取るべきであったとも思えなくも無いのも正直なところです。

Re:今朝のスピーチで

[Teruching (3577)]

あと、忘れてはいけないのはJavaScriptも切らないとね;-P

なんか、便利にするための機能がすべてセキュリティーホールになっているような・・・

#JavaとJavaScriptを混同している人ってけっこいるよなぁ・・・

--
天琉陳(Teruching)

Re:今朝のスピーチで

[Anonymous Coward]

> #JavaとJavaScriptを混同している人ってけっこいるよなぁ・・・

そそそ、いっぱいいる。
自称「デザイナー」とか自称「ウェブマスター」とか。
こんな連中のお守りで、頭のいたい毎日よ...

発生しにくい？

[Anonymous Coward]

> オープンソースでの開発によるならばこのような問題も発生しにくいと聞きますが、Mozilla などはどうなんでしょうか?"

発生し難い点はあるだろうけど、オープンソースもっとも良い点は、発生しても直ぐにパッチが作りやすい点の方ではないでしょうか？

ソースが公開されているからといって必ずしも、パッチが直ぐに作ってくれるとはかぎりませんが。
この点が、Mozilla などはどうなんでしょうか?
と聞いてみちゃったりなんかして。

By シャム

Re:発生しにくい？

[Anonymous Coward]

Mozillaは nightly buildとして自動的に毎日ビルドして
公開されているので、

　1)そういった問題があることを誰かが発見し
　2)それｗ mozilla.orgへ誰かが報告し
　3)誰かが対策のためのコードを書き
　4)十分にテストされ
　5)該当する部分のモジュールオーナがコードを
　　取り込む事を判断し
　6)レビュワー達が認めれば

CVSツリーにそのコードは取り込まれ、自然に
翌日には対策済みのビルドが公開されます。
（もしかしたらレビューフローがまた変わっているかも）

ただ、現在の最新 milestone buildsである 0.9.5 に
対して back port し 0.9.5.1 などを公開することは
99.9%ありません。 もしも今日そういった問題が
見つかった場合、既に branchしている 0.9.6 の
枝に対策が施されるかどうかは微妙かもしれません。
（たぶんスケジュールを２～３日遅らせてでも
取り込むとは思いますが）

Re:発生しにくい？

[Anonymous Coward]

一番の問題は、3)項の誰がコードを書くかだろうね。

書く技術はさておき、対象が特定モジュールだけに
閉じている修正ならば取り込みにかかわるフローも
割とスムースに行くだろうけど、広い範囲に影響する
場合は比較的時間がかかる可能性はあるかも。

とはいえ、修

mozilla.org におけるセキュリティ問題の扱いについて

[Anonymous Coward]

＃自己コメント

修正レポートやパッチ自体は Bugzillaにあがるだろう
けど、それはすぐに公表されるのかなと思って調べたら
"Handling Mozilla Security Bugs" という文書が
見つかった。

http://www.mozilla.org/projects/security/security-bugs-policy.html

長い英文でよく分からん (^^; ので各自で見て欲しい。
（んで、わしの解釈に間違いがあったら指摘してほしい）

どうやらmozilla.orgにはセキュリティに注力する
チームがあって、Bugzillaへ報告されたセキュリティ
問題のレポートは最初のうちはそのチームと報告者のみが
参照できるようになっているらしい。（つまりは
隠される。）

ただし、その隠蔽期間は特に定めてないが、意味もなく
長期間隠蔽する事はさすがに禁止されていて公開する
義務が課せられているようだ。

またそのバグレポートをセキュリティチーム以外にも
公開するかどうかのフラグ設定の権利は、セキュリティ
チームだけでなく報告者自身も所有するらしい。
だから報告者が「早急に公開を」と考えれば
即公開も可能（だと思うがあっているか？ ^^;）

他にも、バグ扱いの考えかたや組織構造、組織の
役割や情報開示の考え方などについて書いてある
ので英文に堪能な人は見て内容を教えて欲しい（爆

Re:発生しにくい？

[m-masa (4724)]

発生後の対応が楽しみです。

私も

[minz (3213)]

勧めてしまいました。(^^; 対応も遅そうだという情報なので残念に思っています。しかしながら、

こういう会社の製品 [nikkeibp.co.jp]を使うよりはよっぽどマシであると信じております。

--
みんつ

オープンソース

[Anonymous Coward]

「オープンソースでの開発によるならばこのような問題も発生しにくい」
は明らかな間違いですな。
あるとすれば、

1. センスのないプログラムは、えてして実行しただけだと
      そのセンスの無さがよくわからないけど
      ソースを一目見ればすぐに分かるものなので、
      ソースがあれば
      「センスのないプログラムは危ないから使わない」
      という選択肢が取りやすい。
2. ソースがあれば、気休め程度には穴が見つけやすい。
3. ソースがあれば、外部の人間でも原因を特定しやすい。
4. ソースがあれば、自分ですぐに直せる。

オープン揚げ足鳥

[Wildcat (2067)]

> 4. ソースがあれば、自分ですぐに直せる。

これでは正しいとも間違いとも言えません。人によってはすぐ直せるかも知れませんがいくらやっても全然直せないこともありえます。よって、これはこのように修正した方がより正確になると思います。

4. ソースがあれば、自分で直せる、かもね。

--
(´д｀;)

Re:オープン揚げ足鳥(-1希望)

[SteppingWind (2654)]

4. ソースがあれば, 自分で味付けできる

いや, サブジェクトだけ見ていたらつい...

それも開発参加の一姿勢です

[naka64 (4590)]

それでできた成果はコミュニティにフィードバックしましょう。
運がよければ本流に採用されるかも。

#「味付け」の意味を思いっきし曲解して軌道修正してみました。

Re:オープン揚げ足鳥(-1希望)

[Anonymous Coward]

やっぱり「フレームのもと」希望ですかね？
＃火の元に注意

開発モデル

[Anonymous Coward]

> オープンソースでの開発によるならばこのような問題も発生しにくいと聞きますが
一体誰に聞いたんだ。

・一般的なバグの発見が早まる

Re:開発モデル

[LightSpeed-J (4514)]

例えば某社の某ブラウザの場合は，何が問題？
ソースがオープンじゃないからバグが見つかりにくい？

なんとなく複雑さの問題，な気がしてるのですが？
「コンセプトが問題」であるならば，賛同！

--
-- LightSpeed-J

Re:開発モデル

[isi (4853)]

　MS社の場合は、ガートナーの言い草 [srad.jp]だけじゃなく、
「基本姿勢」 [cnet.com]に一番問題があるんじゃないでしょうか。

Re:開発モデル

[Hebikuzure (489)]

やっぱりオープンソースの場合、いろんな考え方、見方をする人が参加しやすいので、多面的なチェックがかかりやすいという事かなあ。
商業的な開発の場合、一度「基本姿勢」が決まると、それに添わない部分は軽視されがちになりますよね。

笑うしかない

[Anonymous Coward]

> 「基本姿勢」

この記事読んで爆笑してしまいました。もうちっとまともな嘘考えつかなかったのかねえ。そういった意味での知性の欠如もこの会社が信頼できない理由の一つだな。

調査に二週間かかるんならちょっと状況を再現したほうが遥かに手っ取り早いだろうが。笑わせる。

馬鹿の上に嘘つき、この会社に期待できることは一体なんだろうね。

ぞっとしますな。

[redbrick (4865)]

こんな、

>馬鹿の上に嘘つき、

な会社が作ったOSが世界を席巻してるなんて・・・。

＃んで、「ソフトウェアで起こった損害は私たちに責任はない」なんて
＃毎回毎回ほざくわけだ。
＃相手にするだけこっちがバカみたいに思える・・・(泣)。

--
---- redbrick

Re:ぞっとしますな。

[BAK (1020)]

「ソフトウェアで起こった損害は私たちに責任はない」

いわゆる「開封契約」とか「利用許諾」の類では，そういう条項が入ってますね． （これらの有効性，については別として）

つまり，無料のソフトと有料のソフトでは「金を払うか払わんか」という違いしかないわけで :-) 「金を払って使っているのだから何かご利益があるだろう」と思ってる人も多いらしいのだけれど，これはただの幻想ですな．

使用許諾

[Aisya (6363)]

　無責任ですか？

　実際にバグがあって、「このソフトの計算ミスのせいで
会社がつぶれた。賠償しろ」
って言われたらどうするんで？

　そこまでの責任を数万円のソフトに対して求める、と。
数億円のソフトでも、ソフトの金額以上の責任はおいま
せんよ。

　無責任でしょうかね？

　無料なら責任をおわなくても良い、というも間違
いで、範囲を明確にした上でそれなりの責任はおうべき
だと思いますね。

　話題がずれてしまって失礼。

Re:使用許諾

[Anonymous Coward]

ソフトの金額以上の責任は負えない、というのはありだと思います。
では、金銭的な負担を求めないソフトウェアに対しても一定の責任を求める根拠ってなんだろう、とも思いますが。

お仕事で、いわゆる open source なソフトウェアを使用する場合、該当するソフトの機能が要求を満たしていることはもちろんですが、トラブルが発生した場合に他人の責任を当てにしなくてすむ、という部分が評価されることも多いはずです。
そ

Re:使用許諾

[Anonymous Coward]

責任を負うべきと考える人は、なにを根拠にそう考えるので
しょう？　以前にそういった意見の人の発言を聞いたことが
ありますが、その人の場合は要するに

　　公の場において広く流通あるいは利用可能にさせるの
　　ならば、それは相応な安全性を備える必要がある。

というものでした。

それは判らなくもないのですが、ではそれが「安全性に問題が
ある可能性が予告されているもの」で「利用する時点でそれに同意
したとみなされる」場合はどうなるのでしょう

Re:使用許諾

[Aisya (6363)]

　無料のソフトウェアに対して声高に「責任とってもら
おうじゃないの！」って詰め寄ることは出来ないとは
思ってます。
（えーと。個々の使用者から料金は徴収しないけれど、
広告他で収入を得るビジネスモデルを有する場合は除く）

　賠償するだけの金額をひねりだせないですし、マンパ
ワーも無いでしょうから。

　というと、結局個々の良心に従ってもらう、というこ
とになるので、責任はとらないということになるんでし
ょうね。「このソフトを使用した場合の損害について、
一切の責任は負いません」という範囲の規定もされて
いるし。

　余計なことを書きました。すみません。

Re:使用許諾

[redbrick (4865)]

>責任を負うべきと考える人は、なにを根拠にそう考えるのでしょう？

バグを直せるのが作成者(例えばMS)だけだから。
＃オープンソースの場合はそうは言いませんがね。
＃自分で直せるという別の道があるから。

--
---- redbrick

Re:使用許諾

[Anonymous Coward]

#40311 にも書いたのですが、そういう考えは
改めるべきだ的な考えの人もいるんですよ。
やはり、公開するなら相応の責任を負えと。

ぴったり当てはまりはしませんが、たとえば。
http://www.forest.impress.co.jp/article/2001/11/05/yomoyama33.html
まぁ、そこで書かれている「最低限の社会的責任」
「ユ

Re:使用許諾

[monalisa (871)]

フリーソフトウェアに限らず、たいていの有償のソフトウェアでも、パッケージを開けると使用許諾に同意したと看做されるものがあり、
しかもその使用許諾には、800円までしか損害を保証しない(あくまで例です)という内容のものもありますよね。
しかもバグ報告をしても対応が遅かったりしてね。

反対にフリーソフトウェアが広く使われている場合には、 作者の中にはその社会的責任を充分に感じている人もいます。
実際、linusは自伝のなかで、「これだけlinuxが広まって、しかも業務でも使われているので、プレッシャを感じる」
といったような発言(詳細失念)をしていますね。
彼はトランスメタでlinuxの開発を主に業務としていると聞いたのですが、
彼にしてみれば、この職に就く事が、彼なりに責任を一部果たしていることになるのではないでしょうか?
つまり、「彼に直接バグ報告をすればすぐに直せる」という体制ですかね
お金だけが責任の取り方ではないってことで、しめます。

Re:使用許諾

[BAK (1020)]

ええと，言いたかったのは「使用許諾という観点から見ると売りものも無料のソフトも同じ． ということは，売りものと無料のソフトの違いは金を払うか払わんか，の違いしかない． 金払ってるから何かいいことがある，という思い込みはただの幻想である場合も多い」 というあたりだったのですが．

Re:使用許諾

[redbrick (4865)]

わたしも同意です。どちらにせよおんなじ。
金払ったところで、結局は責任をこちらに押しつけられる
だけですからねぇ。
＃サポートなんてものにハナから期待はしていないので、
＃自分で問題に対処でき、サポート省略で安くなるなら
＃そっちを常に選択します。
＃ただ、売り物以外に選択肢がない場合もあるので・・・。

ただ、自分が作ったものに対する責任というものはあると思います。
＃ユーザーが被害を受ける受けない、という部分より前の段階で。

ものを作る側は、それが自分の手から離れる段階で、その責任を普通
意識していると思います。
＃コメントの投稿でも、会議での発言でも、製品の出荷でも同じ。
危険なもの、影響の波及の多いものについては、自分の手を離れる前に
慎重に問題がないか、これで大丈夫かと考えませんか？

その考慮が充分ではなかった場合は、批判されるのは当然と思います。
＃それは製品の質にかかわるものであるから。
そう云った、製品の質についての責任は、無償だろうが有償だろうが
どんなものにもあるはずです。
＃/.の参加者がコメントひとつにも責任を求められるように。

他の方が言われているのは、そう云った製品の質についての責任だと思うのですが、
わたしはそれが即賠償責任に結びつくとは考えていません。

明らかに危険なものを危険な扱い方で使ったら、その被害は使用者の
責任において賠償されるべき、と思います。
＃包丁を振り回して他人にケガを追わせたら、包丁のメーカーが治療費と
＃慰謝料を支払ってくれるんですか？ くれませんよね？

でも、明らかに危険なものを、もっと危険でない使い方に変えたり、
危険な部分を直させる事はやるはずです。
＃包丁を登録制のお店で販売するようにする、ある程度以上の、
＃武器になりそうな大きさのものは購入に身分照明が必要とする、
＃使用者に注意を促す説明書を同梱して販売する、など。

そう云った部分での修正要求は可能なはずですし、詳細なバグ報告を作者に
送ることはできるはずです。
＃オープンソースではpatchを作って作者に送ることすら可能です。
で、その製品の問題によって被害を受けた場合の賠償は、商契約としての
使用許諾の問題になると思います。
＃それに、使用許諾では、一般に
＃「製品について批判してはならない、修正要求を出してはいけない」
＃なんて、書いてないですよね？

だもんで、製品の内実を隠蔽して、欠陥品や危険な製品をばらまき、
バグの指摘についても知らぬ振りをするような相手は
糾弾されてしかるべき、と思うのです。
あ、糾弾してるからって、賠償しろって言ってるわけではないですよ。

＃だから、MSはいつも責められているのだとわたしは思います。
＃適切な時期に、セキュリティ情報など必要な情報をきちんと公開し、
＃危険があるならばそれを事前に説明し、デフォルト設定で危険な状態に
＃なっている製品を出荷してないですから。

--
---- redbrick

おっと、訂正(汗)

[redbrick (4865)]

>＃適切な時期に、セキュリティ情報など必要な情報をきちんと公開し、
>＃危険があるならばそれを事前に説明し、デフォルト設定で危険な状態に
>＃なっている製品を出荷してないですから。

デフォルト設定で危険な状態になっていない製品を出荷してないですから。

ですね。

--
---- redbrick

Re:使用許諾

[BAK (1020)]

うむ，了解です． 法的に云々，というレベルではなくて「作り手のプライド」という話ですね．

そういう意味では，金取ってるソフトの場合は無料のソフト以上にしっかりしなければならん，と，私は思います． われわれから取った金で，バグなどに対処するリソースを整備できる／すべきですから．

Re:開発モデル

[Anonymous Coward]

おっととっと失敗。

・一般的なバグの発見が早まるので、正式リリースの時に一般的なバグが入る事が少ない
・みんなして寄ってたかって修正するので、直し忘れとか時間切れとかが少ない

程度の話だと思う。
あくまで多量のマンパワーがなせる技であり、オープンソースだからとか言う話じゃないよ。

Re:開発モデル

[who-am-i (2922)]

あくまで多量のマンパワーがなせる技であり

ってのももちろんそうでしょうけど、見逃せないのが、違う価値観から見た評価でしょう。
closed な環境で開発されていて、開発者側が『仕様だ』と 思い込んでいる場合でも、違う立場からみれば『穴だ』と 思うこともよくあるでしょう?

その他、開発している側に近寄りやすいのでバグ報告とかを出しやすい、とかもあるんでしょうね。

Re:開発モデル

[G7 (3009)]

>違う価値観から見た評価

そうですね。それのおかげでOpenSourceって、
「多くの人にとってしっくりくる仕様」に
落ち着くことが多いように思います。
OpenSourceの使いやすさは、そこから醸し出される、という。

Closedな仕事だと、「これって仕様自体がおかしいのでわ」とか
「技術的にこんな実りの無い無理をするくらいなら、こっちの代替案を認めて欲しいのに」
とか思うことが多いです(T_T)

ただし、OpenSourceのほうも、コミュニティ全体が偏向(^^;してたら話は別ですが。
世間の人々に言わせればUnixそのものが(以下略)とか言われそうだったり(^^;。

勿論、全てのOpenSourceが良くも悪くもマジョリティを志向する必要はないわけですが。

Re:開発モデル

[takunama (6522)]

あくまで多量のマンパワーがなせる技であり、オープンソースだからとか言う話じゃないよ。

そうですね。
「しっかりしたコミュニティに支えられたオープンソース開発プロジェクトなら」とすべきでした。