パスワードを忘れた? アカウント作成
6317 story

経産省、Cookie盗聴への対策を指示 90

ストーリー by Oliver
お金が絡んでます 部門より

k3c 曰く、 "8月11日、経済産業省から「Cookie盗聴によるWebアプリケーションハイジャックの危険性への対応について」というプレスリリースが発表された。これは、産業技術総合研究所 グリッド研究センター セキュアプログラミングチームから先日発表された「Cookie盗聴によるWebアプリケーションハイジャックの危険性とその対策」というテクニカルレポートの内容について、(財)日本情報処理開発協会・電子商取引推進協議会・(社)情報サービス産業協会・(社)電子情報技術産業研究会・(社)日本通信販売協会の5団体に対して、会員企業へ対策の周知徹底を図るよう通知した、というもの。
このレポートでは、SSLを使用するWebページで、セッション管理のために発行しているCookieにsecure属性がないと、Cookieが盗聴されてしまい、SSLの安全性が損なわれる場合があるという危険性について述べ、実際に多くのWebアプリケーションで、secure属性を持たないCookieを発行しているというお寒い現状が示されている。
経産省からの通告に各団体がどのように応えるのか、また各団体から通知を受けた各会員企業がどの程度真摯に対策を施そうとするのか、結果はまだ分からないが、少なくとも行政側にこのような認識が生まれているということは評価に値するのではないだろうか。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • このプレスリリース,基本的には的を射ている提言なんだが,対策Bとして提示している [ipa.go.jp],
    方法 B: 2つのクッキーを使い分ける

    サイトの設計上、http://... の画面と https://... の画面をまたがってセッション管理を行う必要がある場合は、2つのクッキーを発行し、一方を secure 属性付きとし、もう一方を secure 属性なしとします。https://... の画面ではセッション管理に前者のクッキーを使用し、 https://... の画面では後者のクッキーを使うようにします。

    このとき、暗号化で保護が必要な画面(https:// を使うことにした画面)に対して、http:// でアクセスされても情報を表示しないように作る必要があります。そうしないと、攻撃者は、盗聴で盗み出した http:// 用のクッキーを使って、重要情報にアクセスできてしまうからです。
    というのが,Java屋としては,ちょっと困りもの。

    というのも,JavaのServletでセッション管理に使われるCookieの文字列は,Servlet APIの仕様 [jcp.org]で,
    SRV.7.1.1 Cookies

    Session tracking through HTTP cookies is the most used session tracking mechanism and is required to be supported by all servlet containers. The container sends a cookie to the client. The client will then return the cookie on each subsequent request to the server, unambiguously associating the request with a session. The name of the session tracking cookie must be JSESSIONID.
    というぐあいに,「JSESSIONID」という文字列に固定されちゃってるんだよね。WebアプリやWebコンテナの都合で勝手に変えるわけにはいかない。

    といって,方法 Aの「すべてのページを https://...にする」というのも,全部のサイトで実現できるわけではないし。

    さて,どうしたもんだろ?
    • by Anonymous Coward on 2003年08月12日 14時02分 (#377367)
      secure属性を付けて独自のCookieを発行すればいいだけですよ。 つまり,コンテナが管理しているセッションIDとは別に,セッションID を管理してあげればよいのです。
      親コメント
      • by Anonymous Coward on 2003年08月12日 15時13分 (#377388)
        >secure属性を付けて独自のCookieを発行すればいいだけですよ。
        >つまり,コンテナが管理しているセッションIDとは別に,セッションID を管理してあげればよいのです。

        面  倒  臭  ぇ

         

        …いや、まあ、その、あなた様の意見は正論です、その通りです。返す言葉もございません。
        しかし、それじゃあなんの為にセッション関連のインターフェイスが提供されて実装知らなくても扱えるようになってんだ、と。

        成る程、こうしてセキュリティホールが出来上がるのか。
        親コメント
        • そのとおりだと思いますよ。面倒くさいですし,いちいち実装していたらバグの温床になります。

          でも,一度実装しちゃえばアプリケーションごとで変わるものでもないですよね。
          フレームワークとして実装するなり,既存のフレームワークを使用するなりが筋でしょう。

        • Javaのことはよくわからないんですけど、この件に限らずどんな仕事でも面倒臭くても 必要ならばキッチリやるのがプロフェッショナルというものだと思います(気持ちはわかりますが(^^;;)。もちろん、キッチリやってもやらなくても全く差がないなら、手を抜くのは当然なんですが。
          いや、むちゃくちゃな納期でデスマーチになってたり、キッチリやっても評
          • by G7 (3009) on 2003年08月12日 23時57分 (#377760)
            >「ブラックボックスで使え」と提供されている

            ブラックボックスというか、「フレームワーク」と呼ぶものなんでしょうね。
            問題は、そのフレームワークの「ホットスポット(改造予定個所)」が
            適切に用意されているかどうか、なんですが…

            たしかにJavaServletのあのcookieを初めて見たときには、
            ちょっと首を傾げたもんでした。
            「なんで変更するメソッドが無いんだろう?」って。

            まあ、そのうち改善されてくれることを期待します。
            Sevlet APIも、時と共に少しづつバージョンが上がっているわけですから。
            少なくとも全くの無神経ってことは無いようですよ。
            たしか以前にも、ヨソのセッションに属するObjectをアクセスできちゃうメソッドが廃止になった
            という改良が有ったような記憶が。
            #そもそもそんなメソッドが最初から有るのが変だ、とも言えるかもだが。
            親コメント
        • ガイドラインに従った実装がこれから出てくるかもしれないぢゃん;-p

          #未来永劫、今の実装だとだれが決めた?

          つか、各ベンダにリクエストしようぜ。
  • by k3c (4386) on 2003年08月12日 14時32分 (#377373) ホームページ 日記
    てにをはの間違いがありましたので訂正お願いします>編集者どの

    「secure属性を持たないCookieを発行しているをいうお寒い現状」
     ↓
    「secure属性を持たないCookieを発行しているいうお寒い現状」
  • by Anonymous Coward on 2003年08月12日 15時18分 (#377395)
    時々メンテや後始末もやってますが、金取ってコード書く前に金払って勉強してこいって感じの仕事にお目にかかる事が多くなりました。セッションハイジャックなんて当たり前。つか動けばいいだけのメンタリティで書かれたと思われるコードが多く、変数汚染に不正なSQLインジェクションもぼこぼこ見つかります。
    メーリングリストや質問板に見るユーザー層の質もそんな状態で、基礎理解が不足している上に解法でなく解答を求める人が大半。最近は素人に素人がリプライ付けてタコなコーディング技法が伝播していく有様。
    関西圏だと仕事料の相場もかなり下落しており、二束三文のコーダー使って動けばいいだけのコードをかけば利益が出るけど、まともなテストや経験と知識を十分に備えた人間を割り当てると赤出るんじゃないの?と思ってしまう状態。

    なんつーか、ストーリーのように啓発を促すか、きっちり監督してもらって品質の下落を食い止めれば少しはマシな状態になるかな~と期待していますけど、、
    • 結局、開発時に発注元が「できること」だけでなくて
      「できないこと(XSSできない、不正なSQLは投げられない、など)」も
      機能に盛り込んでいかない限り、改善しないんだろうなぁ。
      しかし、現状では「できないことは機能ではないし、払う金はない」なんて言われそうだな。

      「できない機能を盛り込んでトラブルを抑え、運用費を削減しました!」
      みたいな成功体験はないのかな…
      そういうのがあれば管理職を説得しやすいと思うんだけど。
      --
      # mishimaは本田透先生を熱烈に応援しています
      親コメント
    • by Anonymous Coward
      まずは、品質に対する対価を正当に評価できるようにすることが重要ではないでしょうか。

      そしたら、あとは、品質の低いものを買っていると後で面倒なことになるよという認識を、運営者に持ってもらうこと。

      しかし、どうやって品質を評価するのか。
      • by Anonymous Coward
        結局、目に見えない、情報収集しにくい性質のものだから難しいですよね。金を出す側ではあんまり理解してないですし。
        建物の手抜き工事と同じで、結局キッチリやっても日の目を見ることは少ない、という状況では、なかなか自
    • 最近ではおさるさんでもプログラミングできる [newtechusa.com]みたいです.いや,だから二束三文のコーダがどうしたって話ではないんですが,ちょっと驚いたものですから.ハイ
  • 役人の責任逃れ (スコア:1, オフトピック)

    by office (5894) <office@ukky.net> on 2003年08月12日 15時21分 (#377399) ホームページ 日記
    こういった省庁の通達は、現場サイドでまともに受け止められることは決してありません。末端ではハンコが山ほど押してある紙束や、超特大PDFになってやってきますので、問答無用でゴミ箱行きがオチです。

    例えばクロスサイトスクリプティング脆弱性についても同様の通知 [meti.go.jp]が平成13年10月30日になされているわけですが、何の効果も影響もないことは皆さんご存じの通りです。

    こういうのは、「こういう問題について指導しない国が悪い」とかいう「とにかく誰かを悪く言いたい系」の人々から逃れる目的だけのために役人がやってることなのだと思います。
    --
    office
    • 代わりに誰がなにかをすべきかという観点が不足しているのではないでしょうか?ないしは、既に提示されたものに対して改善するという余地はないのでしょうか?

      声が届かないという問題点があると仮定して、それは、受け止める側の問題でしょうか?それとも、発声する側の問題でしょうか?

      # どきどきしながらID
      --
      Copyright (c) 2001-2014 Parsley, All rights reserved.
      親コメント
      • どちらにも問題あると思いますし、さらにプロトコルにも問題があるでしょう。

        「代わりに誰がなにかをすべきか」という点については、いわゆる「立法論」とかいうやつの範疇にはいるらしく、これを口にすると物笑いのタネになります。単なる自己満足じゃないのという、まことにごもっともな指摘まで頂戴してしまいます。それでもやるんだという「ハッカー」:-)にあなたもなりますか?

        例えば、経産省が直接通知したという5団体のWebには、まさに「SSLを使用するWebページで、セッション管理のために発行しているCookieにsecure属性がない」のではないかと推測されるところがあります。(私はそこに入れないので確認できません。)

        そういったことがらを確認し、きちんと改善されないようなら、「きちんと対応しろ。そういう怠惰な姿勢を正せ!」と指導してがげるのも「誰かがすべき何か」の一つなのかも知れません。そうでないことなのかも知れません。あなたが自己責任で考え行動して下さい。

        おっしゃることは正論ですが、机上の空論に終わらせないでくださいね。
        --
        office
        親コメント
        • よそから茶々入っているようで、黙っていると私のAC発言だと思われそうなので、継続させていただきます。

          > どちらにも問題あると思いますし、さらにプロトコルにも問題があるでしょう。

          「プロトコル」の意味がhttp/httpsの件でしたらおっしゃるとおりです。その前に、伝えるべき内容が正しく伝わっていないという点で、「プロトコール」に問題があるという意味に解釈してよろしいでしょうか?

          # 誰と誰の間かであるかは、さまざまな解釈があるでしょうが。

          「オレ基準」というものは、本人に一番わかりにくいということは、他者から指摘されないと気が付きにくいものです。たとえば、「立法論」であるとの反論をうけて、政治家になるというオプションもありうるのではないでしょうか?

          正論は深まらないと思っていますので、罵ってくださって結構。
          --
          Copyright (c) 2001-2014 Parsley, All rights reserved.
          親コメント
          • ここで言うプロトコルは、「発声する側」と「受け止める側」の間でなされる通信に関する規則のつもりでした。

            つまり、何重にも押印された表紙が重ねられていくようなそういうやり方のことです。

            確かに、「政治家になるというオプションもあり」得ますね。ただそいつは多くの場合遠回り過ぎると判断されるような気がします。少なくとも「ハック」ではないでしょう。
            --
            office
            親コメント
    • by dejaq (16629) on 2003年08月12日 16時24分 (#377453)
      しかしメールでねじ込んだり,掲示板でさらしても,大した影響
      も効果もないことも皆さんご存じの通りでは?

      こういうのは何のためにやっているわけ?
      自己満足じゃないよね?
      親コメント
      • Re:役人の責任逃れ (スコア:0, フレームのもと)

        大義名分としては一消費者である自分のためにやってますので、自己満足のため以上のものではありません。

        で、それが何か問題なんですか?
        --
        office
        • by dejaq (16629) on 2003年08月12日 17時37分 (#377512)
          正直この返答にはとてもがっかりしたんだけどな
          そのまま肯定するとは思わなかったよ,はあ

          要するに経済産業省もoffice氏も自己満足のためにやっているわけで
          あえて脳内フィルターかけるけど,お役所が税金を使っているかどう
          かが問題なわけね,たぶん
          で私人が自己満足のためにやる分には問題はないと

          了解
          つまんね
          親コメント
  • クッキーデータ無くして更にパスワード忘れた場合は、メールでパスワード送ってもらうんじゃないのか?
    大抵平文でだよね。

    ニュースサイトは大きな穴を見つけたみたいに書いているところあるけど、大したこと無い気がする。
    • by Anonymous Coward on 2003年08月12日 17時28分 (#377503)
      2 年にわたって運営を担当させられている某サイトは Cookie に ID とパスワードを平文で格納してます。セッションちゃうやん > SIer
      ユーザーが「パスワード教えて(泣」とメールを投げてきた時は ID とメールアドレスを照合した後に登録されたパスワードをこれまた普通のメールで返します。パスワードは平文のままDBに格納されてます。
      こんな所の管理者なんてイヤです。苦痛です。鬱です。
      ついでに SSL 無しで住所から家族構成まで入力させているのですが、ユーザー数が1000を超えた割に苦情は1件しか入っていません。まぁ機会ロスはその数十倍ありそうですけど。
      ただこういう状況だとリプレースの必要性を説いても説得力が落ちるんですね。どうしようもないシステムですが、意外とクライアントとユーザーの程度を考えると身の丈には合っているのかも~なんて思ったり。

      で、リプレース用に自分で構築中のシステムではリマインダーを使って新しいパスワードで上書きし、ユーザーにそのパスワードを使ってログインしパスワードを再設定するよう促したメールを返します。パスワードは md5 ハッシュ値を取ってDBに格納しています。なので本人が忘れると終わり。
      色々不備もありますが、まぁコストもかけれませんし、ユーザーオペレーションのコストを上げるとクライアントが煩い上に私の能力評価が下がるし、妥当な仕様かな、と。
      親コメント
      • 俺、実はSSLは大して必要と思っていません。

        俺が構築中のシステムでは、平文でパスワード送ります。
        IDはメールアドレス。
        パスワードは、計算で求めて(md5とsha1)、翌日いっぱいまで有効とかにするつもり。
        DBにはパスワードもそのハッシュも格納しない。
        前回パスワードを発行した時の日付やIPアドレスは保存し通知するかも。
        名前とか生年月日とかを使う確認は取らないで、IDのメールアドレスにパスワード送信。

        回線途中で覗くより、端末から盗む方が簡単だよね。
        自分専用端末じゃない奴のことを配慮する方が、必要だと思ってます。
        あと、自分専用端末でも、ウイルスとか、トロイの木馬とか、色々入っている奴がいるからね。

        クッキーって平文で格納されるよね。セキュアのクッキーは別なのかな?
        親コメント
    • SSLで重要なデータを入出力するWebサイトが平文のメールでユーザーにパスワードを送っていればそれは問題ですが、仮にその問題を指摘して改善されたとしても、今回指摘されたクッキー盗聴の問題が実在していれば、依然として重要なデータが盗まれる可能性は残ります。

      また、そのようなWebサイトが平文メールでユーザーにパスワードを送っていなくても、今回指摘されたクッキー盗聴の問題が実在していれば(以下略)

      平文メールでパスワード云々は、今回の問題の重要性になんら影響を与えません。

      -----
      もちろん、平文メールでパスワードを送って、それをそのまま恒久的にパスワードとして用いられるような実装は問題ですし、そのような実例を見つけたら(利用しない|指摘して修正してもらう|必要だと思えば公表する)というアクションが必要になることもあるでしょう。
      親コメント
    • そりゃまた危険な欠陥をお持ちのサイトをお使いですね。

      普通は、パスワードリマインダーが付いてたり、
      住所、電話番号とか、登録してある情報をありったけ入れないと、
      パスワードが送られてこないという仕掛けに
      なってませんか?
  • by Anonymous Coward on 2003年08月12日 13時42分 (#377354)
    アプリケーションハイジャック?
    この言葉はどうなんでしょう。はじめて聞きました。
    予算取るために大げさな言葉を使ってるんだろうか。
    うちはこれだけやってますよと。

    垂れこみの中身自体は
    きちんとしなきゃいけないことだと思うんですが…
    • 「Webアプリケーション」のハイジャックですよ。
      やっていることはセッションハイジャックなんですが、この場合はセッションを利用しているWebアプリケーション全体の脆弱性を指摘している、と考えれば大げさな表記ではないと思います。
      親コメント
      • 元ACでは無いのですが、私もWebアプリケーションのハイジャックでは、やや大袈裟な気がしました。
        例えば、ジェロニモ(new!)乗っ取りとかを想像してしまう。

        今回のケースならば「Webアプリケーション ユーザセッション ハイジャック」
        英語では"the User's Web Application Session Hijacking Attack"
        とかが妥当な気が。長いけど。

        #高橋さん恐いのでAC。 (^^;
    • セッションハイジャックの間違いじゃないの? また例によって「セッションという言葉は一般的じゃ無い」 なんて不可解な理由で間違った用語を発明したんだろ。
      国語審議会にちくってやる。
      • Re:ハイジャックって (スコア:2, すばらしい洞察)

        by meta-o (11572) on 2003年08月12日 14時39分 (#377377)
        > 国語審議会にちくってやる。

        国語審議会的には、まず 「ハイジャック」->「乗っ取り」でしょう。「セッション」は「会期」かな(ちょっと違うような気もする)。
        親コメント
      • サブジェクトを見る限り元ACは、"ハイジャック"の表現が大袈裟だと騒いでると読めますね。

        セッションハイジャッキングという言葉もこれまで聞いたことがないということなのでは?
      • オフトピですが。国語審議会は、この前消滅しました。表外字体漢字表を答申したのが最後の仕事となりました。この答申は内閣告示はされない模様なんですが、それでもJIS X 0213は国語審議会答申ベースで改訂されつつあります。
    • > アプリケーションハイジャック?
      > この言葉はどうなんでしょう。はじめて聞きました。
      > 予算取るために大げさな言葉を使ってるんだろうか。

      英語圏で"hijack"と表現してい [google.co.jp]
  • by Anonymous Coward on 2003年08月12日 17時18分 (#377496)
    ちょうど一週間前の日経の夕刊にこんな記事がありました。

    ネット通販大手、9割にシステム欠陥・産総研調査 [nikkei.co.jp]

    結果が偏ってるような気がするんですが、この記事の「大手通販サイト」の
    選定基準ってどうなんでしょうね。
    • by Anonymous Coward on 2003年08月12日 17時53分 (#377523)
      元ネタの産総研テクニカルレポートによると
      調査対象として、ある著名なインターネット情報誌が2002年に開催した、優秀なネットショップを選ぶコンテストにおいて、ある部門にノミネートされた35箇所のネットショップを選択した。
      とあります。
      この35のネットショップのうち
      • 10ヶ所はユーザ登録機能がない
      • 3つのサイトはcookieによるセッション追跡を行っておらず
      • ので対象外。
        残りの25サイトのうち2つのサイトはsecureモードのcookieを使用して いたので、23サイトに問題ありと結論していました。
        日経は調査対象になった25サイトを基準に「9割」としていますが、「ネット通販大手」というなら、元々の35のネットショップに対しての 比率(6割強)の方が、言い方としては正確だと思います。
      親コメント
typodupeerror

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

読み込み中...