経産省、Cookie盗聴への対策を指示 90
ストーリー by Oliver
お金が絡んでます 部門より
お金が絡んでます 部門より
k3c 曰く、 "8月11日、経済産業省から「Cookie盗聴によるWebアプリケーションハイジャックの危険性への対応について」というプレスリリースが発表された。これは、産業技術総合研究所 グリッド研究センター セキュアプログラミングチームから先日発表された「Cookie盗聴によるWebアプリケーションハイジャックの危険性とその対策」というテクニカルレポートの内容について、(財)日本情報処理開発協会・電子商取引推進協議会・(社)情報サービス産業協会・(社)電子情報技術産業研究会・(社)日本通信販売協会の5団体に対して、会員企業へ対策の周知徹底を図るよう通知した、というもの。
このレポートでは、SSLを使用するWebページで、セッション管理のために発行しているCookieにsecure属性がないと、Cookieが盗聴されてしまい、SSLの安全性が損なわれる場合があるという危険性について述べ、実際に多くのWebアプリケーションで、secure属性を持たないCookieを発行しているというお寒い現状が示されている。
経産省からの通告に各団体がどのように応えるのか、また各団体から通知を受けた各会員企業がどの程度真摯に対策を施そうとするのか、結果はまだ分からないが、少なくとも行政側にこのような認識が生まれているということは評価に値するのではないだろうか。"
「2つのクッキーを使い分ける」ってのがねー (スコア:2, 興味深い)
というのも，JavaのServletでセッション管理に使われるCookieの文字列は，Servlet APIの仕様 [jcp.org]で， というぐあいに，「JSESSIONID」という文字列に固定されちゃってるんだよね。WebアプリやWebコンテナの都合で勝手に変えるわけにはいかない。
といって，方法 Aの「すべてのページを https://...にする」というのも，全部のサイトで実現できるわけではないし。
さて，どうしたもんだろ？
Re:「2つのクッキーを使い分ける」ってのがねー (スコア:1, 参考になる)
暴言かましてよかですか? (スコア:2, 参考になる)
>つまり，コンテナが管理しているセッションIDとは別に，セッションID を管理してあげればよいのです。
面 倒 臭 ぇ
…いや、まあ、その、あなた様の意見は正論です、その通りです。返す言葉もございません。
しかし、それじゃあなんの為にセッション関連のインターフェイスが提供されて実装知らなくても扱えるようになってんだ、と。
成る程、こうしてセキュリティホールが出来上がるのか。
Re:暴言かましてよかですか? (スコア:0)
そのとおりだと思いますよ。面倒くさいですし，いちいち実装していたらバグの温床になります。
でも，一度実装しちゃえばアプリケーションごとで変わるものでもないですよね。
フレームワークとして実装するなり，既存のフレームワークを使用するなりが筋でしょう。
Re:暴言かましてよかですか? (スコア:0)
いや、むちゃくちゃな納期でデスマーチになってたり、キッチリやっても評
Re:暴言かましてよかですか? (スコア:1)
ブラックボックスというか、「フレームワーク」と呼ぶものなんでしょうね。
問題は、そのフレームワークの「ホットスポット(改造予定個所)」が
適切に用意されているかどうか、なんですが…
たしかにJavaServletのあのcookieを初めて見たときには、
ちょっと首を傾げたもんでした。
「なんで変更するメソッドが無いんだろう？」って。
まあ、そのうち改善されてくれることを期待します。
Sevlet APIも、時と共に少しづつバージョンが上がっているわけですから。
少なくとも全くの無神経ってことは無いようですよ。
たしか以前にも、ヨソのセッションに属するObjectをアクセスできちゃうメソッドが廃止になった
という改良が有ったような記憶が。
＃そもそもそんなメソッドが最初から有るのが変だ、とも言えるかもだが。
Re:暴言かましてよかですか? (スコア:0)
#未来永劫、今の実装だとだれが決めた?
つか、各ベンダにリクエストしようぜ。
Re:「2つのクッキーを使い分ける」ってのがねー (スコア:0, 余計なもの)
ネ タ が つ ま ら な い か ら 荒 ら し 認 定 さ れ る ん だ
せめて隣りの奴が笑ってから投稿せぇ
誤記訂正 (スコア:1)
「secure属性を持たないCookieを発行しているをいうお寒い現状」
↓
「secure属性を持たないCookieを発行しているというお寒い現状」
くっきーはぐはぐ (スコア:1, 興味深い)
メーリングリストや質問板に見るユーザー層の質もそんな状態で、基礎理解が不足している上に解法でなく解答を求める人が大半。最近は素人に素人がリプライ付けてタコなコーディング技法が伝播していく有様。
関西圏だと仕事料の相場もかなり下落しており、二束三文のコーダー使って動けばいいだけのコードをかけば利益が出るけど、まともなテストや経験と知識を十分に備えた人間を割り当てると赤出るんじゃないの？と思ってしまう状態。
なんつーか、ストーリーのように啓発を促すか、きっちり監督してもらって品質の下落を食い止めれば少しはマシな状態になるかな～と期待していますけど、、
Re:くっきーはぐはぐ (スコア:1)
「できないこと（XSSできない、不正なSQLは投げられない、など）」も
機能に盛り込んでいかない限り、改善しないんだろうなぁ。
しかし、現状では「できないことは機能ではないし、払う金はない」なんて言われそうだな。
「できない機能を盛り込んでトラブルを抑え、運用費を削減しました！」
みたいな成功体験はないのかな…
そういうのがあれば管理職を説得しやすいと思うんだけど。
# mishimaは本田透先生を熱烈に応援しています
Re:くっきーはぐはぐ (スコア:0)
品質への対価 (スコア:0)
そしたら、あとは、品質の低いものを買っていると後で面倒なことになるよという認識を、運営者に持ってもらうこと。
しかし、どうやって品質を評価するのか。
Re:品質への対価 (スコア:0)
建物の手抜き工事と同じで、結局キッチリやっても日の目を見ることは少ない、という状況では、なかなか自
Re:くっきーはぐはぐ (スコア:0)
役人の責任逃れ (スコア:1, オフトピック)
例えばクロスサイトスクリプティング脆弱性についても同様の通知 [meti.go.jp]が平成13年10月30日になされているわけですが、何の効果も影響もないことは皆さんご存じの通りです。
こういうのは、「こういう問題について指導しない国が悪い」とかいう「とにかく誰かを悪く言いたい系」の人々から逃れる目的だけのために役人がやってることなのだと思います。
office
責任逃れた人は置いておいて (スコア:1)
声が届かないという問題点があると仮定して、それは、受け止める側の問題でしょうか？それとも、発声する側の問題でしょうか？
# どきどきしながらID
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:責任逃れた人は置いておいて (スコア:1)
「代わりに誰がなにかをすべきか」という点については、いわゆる「立法論」とかいうやつの範疇にはいるらしく、これを口にすると物笑いのタネになります。単なる自己満足じゃないのという、まことにごもっともな指摘まで頂戴してしまいます。それでもやるんだという「ハッカー」:-)にあなたもなりますか？
例えば、経産省が直接通知したという５団体のWebには、まさに「SSLを使用するWebページで、セッション管理のために発行しているCookieにsecure属性がない」のではないかと推測されるところがあります。（私はそこに入れないので確認できません。）
そういったことがらを確認し、きちんと改善されないようなら、「きちんと対応しろ。そういう怠惰な姿勢を正せ！」と指導してがげるのも「誰かがすべき何か」の一つなのかも知れません。そうでないことなのかも知れません。あなたが自己責任で考え行動して下さい。
おっしゃることは正論ですが、机上の空論に終わらせないでくださいね。
office
Re:責任逃れた人は置いておいて (スコア:1)
> どちらにも問題あると思いますし、さらにプロトコルにも問題があるでしょう。
「プロトコル」の意味がhttp/httpsの件でしたらおっしゃるとおりです。その前に、伝えるべき内容が正しく伝わっていないという点で、「プロトコール」に問題があるという意味に解釈してよろしいでしょうか？
# 誰と誰の間かであるかは、さまざまな解釈があるでしょうが。
「オレ基準」というものは、本人に一番わかりにくいということは、他者から指摘されないと気が付きにくいものです。たとえば、「立法論」であるとの反論をうけて、政治家になるというオプションもありうるのではないでしょうか？
正論は深まらないと思っていますので、罵ってくださって結構。
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:責任逃れた人は置いておいて (スコア:1)
つまり、何重にも押印された表紙が重ねられていくようなそういうやり方のことです。
確かに、「政治家になるというオプションもあり」得ますね。ただそいつは多くの場合遠回り過ぎると判断されるような気がします。少なくとも「ハック」ではないでしょう。
office
Re:役人の責任逃れ (スコア:1)
も効果もないことも皆さんご存じの通りでは？
こういうのは何のためにやっているわけ？
自己満足じゃないよね？
Re:役人の責任逃れ (スコア:0, フレームのもと)
で、それが何か問題なんですか？
office
Re:役人の責任逃れ (スコア:1)
そのまま肯定するとは思わなかったよ，はあ
要するに経済産業省もoffice氏も自己満足のためにやっているわけで
あえて脳内フィルターかけるけど，お役所が税金を使っているかどう
かが問題なわけね，たぶん
で私人が自己満足のためにやる分には問題はないと
了解
つまんね
Re:役人の責任逃れ (スコア:1)
office
Re:役人の責任逃れ (スコア:1)
「経産省からの通告に各団体がどのように応えるのか、また各団体から通知を受けた各会員企業がどの程度真摯に対策を施そうとするのか、結果はまだ分からないが、少なくとも行政側にこのような認識が生まれているということは評価に値するのではないだろうか。」
とあるので、それに応える形で書いてるのであって、文書の有用性についてはまだ何も言ってない。
文書の有用性だけでなく、経済産業省が公式に通知したという事実や、Webに掲げていることにも有用性がある。
「××の理由でCookieの扱いをこういう具合にしてはいけない」と指摘しただけでは理解できなくても、「経済産業省がこうやってはいけないと公式に発表している」とポインタを示すと従う馬鹿がたくさんいるからね。
office
パスワード忘れた場合 (スコア:1)
大抵平文でだよね。
ニュースサイトは大きな穴を見つけたみたいに書いているところあるけど、大したこと無い気がする。
適当にやっても苦情率は 1/1000 (スコア:2, 興味深い)
ユーザーが「パスワード教えて（泣」とメールを投げてきた時は ID とメールアドレスを照合した後に登録されたパスワードをこれまた普通のメールで返します。パスワードは平文のままDBに格納されてます。
こんな所の管理者なんてイヤです。苦痛です。鬱です。
ついでに SSL 無しで住所から家族構成まで入力させているのですが、ユーザー数が1000を超えた割に苦情は１件しか入っていません。まぁ機会ロスはその数十倍ありそうですけど。
ただこういう状況だとリプレースの必要性を説いても説得力が落ちるんですね。どうしようもないシステムですが、意外とクライアントとユーザーの程度を考えると身の丈には合っているのかも～なんて思ったり。
で、リプレース用に自分で構築中のシステムではリマインダーを使って新しいパスワードで上書きし、ユーザーにそのパスワードを使ってログインしパスワードを再設定するよう促したメールを返します。パスワードは md5 ハッシュ値を取ってDBに格納しています。なので本人が忘れると終わり。
色々不備もありますが、まぁコストもかけれませんし、ユーザーオペレーションのコストを上げるとクライアントが煩い上に私の能力評価が下がるし、妥当な仕様かな、と。
Re:適当にやっても苦情率は 1/1000 (スコア:1)
俺が構築中のシステムでは、平文でパスワード送ります。
IDはメールアドレス。
パスワードは、計算で求めて（md5とsha1）、翌日いっぱいまで有効とかにするつもり。
DBにはパスワードもそのハッシュも格納しない。
前回パスワードを発行した時の日付やIPアドレスは保存し通知するかも。
名前とか生年月日とかを使う確認は取らないで、IDのメールアドレスにパスワード送信。
回線途中で覗くより、端末から盗む方が簡単だよね。
自分専用端末じゃない奴のことを配慮する方が、必要だと思ってます。
あと、自分専用端末でも、ウイルスとか、トロイの木馬とか、色々入っている奴がいるからね。
クッキーって平文で格納されるよね。セキュアのクッキーは別なのかな？
Re:適当にやっても苦情率は 1/1000 (スコア:1)
「セッションのクッキー」は普通 volatile なものです。
もちろん、開きっぱなしのブラウザをそのまま利用されてしまったらおしまいですけどね。
Re:パスワード忘れた場合 (スコア:1)
また、そのようなWebサイトが平文メールでユーザーにパスワードを送っていなくても、今回指摘されたクッキー盗聴の問題が実在していれば(以下略)
平文メールでパスワード云々は、今回の問題の重要性になんら影響を与えません。
-----
もちろん、平文メールでパスワードを送って、それをそのまま恒久的にパスワードとして用いられるような実装は問題ですし、そのような実例を見つけたら(利用しない|指摘して修正してもらう|必要だと思えば公表する)というアクションが必要になることもあるでしょう。
Re:パスワード忘れた場合 (スコア:0)
普通は、パスワードリマインダーが付いてたり、
住所、電話番号とか、登録してある情報をありったけ入れないと、
パスワードが送られてこないという仕掛けに
なってませんか？
Re:パスワード忘れた場合 (スコア:1)
Re:パスワード忘れた場合 (スコア:1)
それに、電話番号って知っている人多すぎ。
15年前に登録したデータとか聞かれても、引越しを何度もしたり電話番号を何度も変えていれば、訳分からなくなる奴が必ず出てくる。
Re:パスワード忘れた場合 (スコア:0)
普通に使っているだけで乗っ取られるのとでは、
いちおう、後者の方が危険度は高いということですかね。
Re:パスワード忘れた場合 (スコア:0)
Re:パスワード忘れた場合 (スコア:1)
ハイジャックって (スコア:0)
この言葉はどうなんでしょう。はじめて聞きました。
予算取るために大げさな言葉を使ってるんだろうか。
うちはこれだけやってますよと。
垂れこみの中身自体は
きちんとしなきゃいけないことだと思うんですが…
Re:ハイジャックって (スコア:1)
やっていることはセッションハイジャックなんですが、この場合はセッションを利用しているWebアプリケーション全体の脆弱性を指摘している、と考えれば大げさな表記ではないと思います。
Re:ハイジャックって (スコア:0)
例えば、ジェロニモ(new!)乗っ取りとかを想像してしまう。
今回のケースならば「Webアプリケーション ユーザセッション ハイジャック」
英語では"the User's Web Application Session Hijacking Attack"
とかが妥当な気が。長いけど。
＃高橋さん恐いのでAC。 (^^;
Re:ハイジャックって (スコア:0)
国語審議会にちくってやる。
Re:ハイジャックって (スコア:2, すばらしい洞察)
国語審議会的には、まず 「ハイジャック」->「乗っ取り」でしょう。「セッション」は「会期」かな(ちょっと違うような気もする)。
Re:ハイジャックって (スコア:0)
セッションハイジャッキングという言葉もこれまで聞いたことがないということなのでは？
Hi,Jack! (スコア:2, 興味深い)
そもそも語源が「hi,Jack!（よぉ、オッサン）」と言いながら銃を突きつけて脅した、
というところから来ていますし。（Jackは見知らぬ人への呼びかけ）
（別の説によると"Hands up high,Jack"「おいてめえ、手ェ上げやがれ」からだとかいう説もありますし、
またHighwayman(追い剥ぎ)+Jacker(夜に狩りをする人)の合成語のHijackerから
動詞Hijackが派生した、という説もありますが「よぉオッサン」説のほうが面白いので僕はそれを推します）
だもんで、乗り物を乗っ取る行為はぜんぶ「hijack」です。
シージャックとかバスジャックとかいう語は和製英語です。
Re:ハイジャックって (スコア:1)
乗っ取り［取る］, ハイジャック（する）; 強奪（する）
Re:ハイジャックって (スコア:0)
Re:ハイジャックって (スコア:0)
> この言葉はどうなんでしょう。はじめて聞きました。
> 予算取るために大げさな言葉を使ってるんだろうか。
英語圏で"hijack"と表現してい [google.co.jp]
Re:ハイジャックって (スコア:0)
# 自分は全てを知っていると思わないこと
ネット通販大手、９割にシステム欠陥・産総研調査 (スコア:0)
ネット通販大手、９割にシステム欠陥・産総研調査 [nikkei.co.jp]
結果が偏ってるような気がするんですが、この記事の「大手通販サイト」の
選定基準ってどうなんでしょうね。
Re:ネット通販大手、９割にシステム欠陥・産総研調査 (スコア:1, 参考になる)
元記事では「クッキー」について触れられています。 [2ch.net]
Re:ネット通販大手、９割にシステム欠陥・産総研調査 (スコア:1, 参考になる)