パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

価格.com、サービス再開へ」記事へのコメント

  • by Anonymous Coward on 2005年05月24日 19時41分 (#740074)
    SQL注入されちゃうのはプログラムの欠陥だろー>asahi.comの記事
    • by pivo (27159) on 2005年05月24日 19時50分 (#740079) 日記
      本当にクラックの方法が記事どおりだとしてら、
       これまでのサイト攻撃は、OSの不備やホームページをネットに提供するプログラムのミスなどを突くケースが多かった。今回は、プログラムに欠陥がなくても、コンピューターが正規の命令か悪意のある命令かは判断できない点を突き、命令をそのまま実行させて支配下に置いていた。
      入力文字列のチェック不足というプログラムの欠陥ですが、asahi.comって何を言っているのかな?Webサイトのように公開されている場合は特に、入力された値のバリデーションを正しく行うことは、Secureプログラミングの基本だと思うのだが、、、

      #自分の個人サイトでは手を抜くけどw

      親コメント
      • 一般の読者を対象にしている記事の性格を考えると、
        あなたの記事の解釈が間違っていると思われます。

        「OSの不備」は、読んで字の如くOSの脆弱性を指すと思い
        ます。「ホームページをネットに提供するプログラム」は、
        サーバソフトウェアのことで、Apache HTTP Serverや
        Internet Information Server等を指しているのではないで
        しょうか。

        上記のように解釈すれば、記事全体の話の筋が通ると思います。
        親コメント
        • そういう受け取り方も、確かに成り立つと思います。doripushさんの言うことは間違っていないかもしれません。
          が、ずいぶん好意的な解釈ですね(笑)

          kakaku.comはApacheやIISだけで「ホームページをネットに提供」していたわけではなく、独自のプログラムを構築してサービスを提供していたわけですが、そのうちの一部分がIISなりだったというだけでしょ?
          また、社会的な責任という面を考慮した場合に、OSやIISなどの脆弱性をつかれたわけではなかったのかもしれませんが、入門書でも載っているようなSecureプログラミングを知らない(または手抜きした)人が実装もテストもしていたということで、利用者がウィルス感染したりという被害が出ているわけですから、kakaku.comを擁護するような内容の記事が問題だと思うわけです。
          kakaku.comが自身を正当化することを、メディアが鵜呑みにしたような記事を載せることに抵抗を感じずにはいられません。

          親コメント
          • by Anonymous Coward on 2005年05月24日 20時38分 (#740107)
            > kakaku.comが自身を正当化することを、メディアが鵜呑みにしたような記事を載せることに抵抗を感じずにはいられません。

            結局ソレだよな。
            サイトの更新頻度からして技術と広報の連携は取れていると見えるだけに、
            今までにない新しい攻撃手法みたいな言い方は、解っててミスリードを誘っているとしか思えねえ。
            親コメント
          • by Anonymous Coward on 2005年05月24日 21時04分 (#740120)
            asahiの記事はkakaku.comを擁護も正当化もしていないと思うのは気のせいですか。
            問題がIISでもphpBBでもなくDBの設定であるって言うのは、プログラム作者ではなくkakaku.comが悪いと言っているように思うのは気のせいですか。

            asahiの記事を読み直した方がいいんじゃないか?と思うのは気のせいですか。
            「ソフトの不備ではなく、データベースの安全設定が不十分だった点を悪用された。」(一部引用)

            #というより、この記事を読んで擁護や正当化と取る人もいるなんて、このコメントを見るまで思わなかった。
            親コメント
            • by Anonymous Coward
              バカか、しゃいんか。
              #740120 はなぞのばくはつを、とげた。

              「と思うのは気のせいですか。」を3連発するなんて、よほど腹が立ったんだろうなあ。
              何故腹が立ったのか俺には解らんけど。

              pivo 氏が疑問に思ってるのは、多分

              > これまでのサイト攻撃は、OSの不備やホームページをネットに提供する
              > プログラムのミスなどを突くケースが多かった。
              > 今回は、プログラムに欠陥がなくても、コンピューターが正規の命令か
              > 悪意のある命令かは判断できない点を突き、命令をそのまま実行させて
              > 支配下に
              • by Anonymous Coward
                #740120だが、バカは良いとして、なんで社員と勘違いするんだろ?

                「OSやIIS、phpBBは悪くない。
                 悪いのは設定をしたkakaku.comだけだ。」
                ってasahiが言ってるって書いてるのに。

                疑うとしたらMSの社員の筋だと思うのだが。
                「winにもIISには問題ないから安心して使えます。
                 今回の問題はユーザが設定を謝ったから起きただけです。
                 通常はなんの問題もありません。」
                #、、、うぐっ、吐き気が
            • by Anonymous Coward
              この記事を書いた者が kakaku.com の言い分を鵜呑みにして、
              不適切な(正しいとは言い難いってゆーかむしろ間違ってる)報道をしていて、
              それが(意図するか否かに関わらず)「kakaku.com への擁護」になってしまっている。

              と言うのが現状です。
              気のせいでもなんでもなく、
          • いつぞやの#735814ですが…
            無知や面倒くさがりでこうなったのなら、どれほど救いがあった事かと思いますよ。
        • > 「ホームページをネットに提供するプログラム」は、
          > サーバソフトウェアのことで、Apache HTTP Serverや
          > Internet Information Server等を指しているのでは
          > ないでしょうか。

          別 AC ですが。

          ネタ元 AC さんは「単純なプログラムミスなの
        • DBのサーバはプログラムではないとでも?
      • (誤)本当にクラックの方法が記事どおりだとしてら
        (正)本当にクラックの方法が記事どおりだとしたら
        typoです(T_T)
        親コメント
      • オフトピですが

        バリデーションというよりもサイニタイジングと言わないか?
        俺のまわりだけか・・。

        バリデーション=数値範囲チェック、仕様に添った型で有るか
        サニタイジング="aaa && sendmail hoge@hoge `tail` ..."みたいなトリッキーな文字列を掲示板に投稿するとか検索フォームにPOSTとかしてないかをチェック。

        というイメージがあるんですけどね。。
        親コメント
        • Google検索結果。

          サイニタイジング の検索結果のうち 日本語のページ 約 63 件中 1 - 4 件目 (0.21 秒)

          サニタイジング の検索結果のうち 日本語のページ 約 2,800 件中 1 - 10 件目 (0.04 秒)

          英語のスペルはぐぐればすぐ出てきますが、「sanitizing」。
          ですので、多分2文字目のイは余分です。

          ちなみに、バリデージョンは英語スペルが「Validation」で
          「Varidation」のtypoが多いみたいですね。
          意味は似てないこともないけど、認証とか保証とか検証とかの
          意味があてられているようですね。

          #私の言うことは例のクレタ人並みに信用できますので!
          親コメント
      • by jbeef (1278) on 2005年05月24日 23時22分 (#740229) 日記
        入力された値のバリデーションを正しく行うことは、Secureプログラミングの基本だと思うのだが、、、
        違いますよ。セキュアプログラミングの本当の基本は、入力の値がどうこうというよりも、出力部分、つまり値を使用する部分(SQLならSQL文を文字列連結して作成する部分)で、メタ文字をエスケープすること(ないし制限チェックをすること(たとえば変数をパス名として使用する部分では、使用するところで所定のディレクトリ内かをチェックする。けっして入力値のチェックではない。))です。

        どういうわけか、入力をサニタイズするという場当たりな対処方法ばかりを宣伝するおかしなセキュリティ屋が多いですが、彼らはプログラミングの素人なんでしょう。ちっちゃいおもちゃCGIプログラムくらいしか作ったことがないとか。

        その場にある脆弱なプログラムを取り急ぎ直すのに入力のサニタイズという方法が即効性がある場合もあるのでしょうが、どのように使われるかわからない入力値をどうやって完全にサニタイズするんでしょうか。サニタイズ漏れや、過剰なサニタイズでバグを生んだりしかねないでしょう。

        セキュアプログラミングの文脈で「サニタイズ」とかいう言葉を持ち出すセキュリティ屋は信用するな、とまで言ってもいいかもしれない。文脈通りに正しい文字列連結のプログラミングをしていれば、この種の脆弱性は最初から生じないのです。

        親コメント
        • by ruto (17678) on 2005年05月24日 23時38分 (#740237) 日記
          それをサニタイズと言うのだと思っていました。
          後学のために正しくはサニタイズとはどういう処理か詳しく教えてください。
          親コメント
        • by pivo (27159) on 2005年05月24日 23時53分 (#740243) 日記
          その通りですね。面目ない。
          ご指摘ありがとうございます。本当に言葉の意味を理解して使っているのかと、自分で反省中です。
          親コメント
        • by zumapon (9208) on 2005年05月25日 1時16分 (#740288)
          外部からの入力:出力が1:nの関係になることを考えると

          1. 出力箇所での対処漏れの予防

          2. 処理回数削減による効率向上

          という考えもアリではないですか?
          なのでシステムの規模や処理内容などで使い分ければ良いんでないでしょうか。
          もちろん、出力時の対処の方がシステムの拡張性は高いと思いますが。

          どちらにしても「設計」「規約による縛り」「試験」は大切ですね。
          親コメント
        • 「サニタイズ」というのはそんなめんどうな言葉でもなくて、存在しちゃまずいキャラクタや文字列を置換するなり削るなりするだけのことですよね?
          そういう意味ではおっしゃるようなメタ文字のエスケープやディレクトリのチェックを(どの時点でやろうとも)サニタイズと呼んでいいような気がします。言い方の問題かな、と。

          しかし、確かにユーザーからの入力値チェックで済ませるというのは場あたり的かもしれないですね。その後どう使われるかがはっきりしてる小さいプログラムしか書かないので、ちょっと気付きませんでした。
          それでも単純に「入力値」とか「入って来た値」とか言ったとき、プログラムに入って来た(main()に入って来た?)値なのか、その関数に入って来た値なのかは状況いかんな気もします。関数に入って来た値を利用する前にエスケープ処理などをやらせる関数を、sanitize()とか名付けたり、「入って来た値は使う前にサニタイズしないとね」みたいな言い方はよくします。やはり言い方、名付け方の問題?

          名前がついているのは便利 [rubycolor.org]ですしね。
          親コメント
        • Yahoo! Blog が入力値をサニタイズしまくって記事投稿時にエラーばっかり吐きまくりやがるので (不正な文字列がどうたらこうたらとか。。。んで、書いた記事全文がフイになる。ブラウザの機能で戻ってもスッカラカンになっちゃうの)、一部ユーザーに反感買いまくりだったりするわけですが、やっぱり彼らもシロートなんだろうなぁ。。。

          。。。ん? /. のコメント欄でもそんなエラーに出くわした記憶が。。。??

          --
          むらちより/あい/をこめて。
          親コメント
        • > どのように使われるかわからない入力値をどうやって完全にサニタイズするんでしょうか。

           セキュリティとは違うのかもしれませんが、データを入力するユーザーが間違える可能性を考慮しないというのはまずいのではないでしょうか。たとえば電話番号の入力を要求しているのにアルファベットが来たら、チェックして正しいデータを入れてもらうようにしないと。

           しかし、電話番号を入れるときにハイフンを使うな、というwebをよく見かけるけど、10桁の数字って確認しにくいんだよなあ。ハイフンくらいプログラムの内部で処理してくれればいいのに。
          --
          ---- 6809
          親コメント
      • >対策として、データベース項目や接続する管理者ごとに使える機能を細かく制限し、
        >外部からの命令を受け付けなくすることなどの設定が必要だ。対策済みの企業も少なくない。

        このくだりが

        >入力された値のバリデーションを正しく行うことは、
        >Secu
        • それは一時期Theo尊師が暴れて話題になった、
          OpenSSHの「特権分離」と同じことではないの?
          これを入力のされた値のチェックに当たるかかと言われてもなぁ。

            Darren Reed: 気に入らないのは「特権分離」とやらを使うのが
          唯一の方法だということだ。皮肉なタ

    • by niratama (2175) on 2005年05月24日 19時55分 (#740081) ホームページ 日記
      最高レベルのセキュリティが破られた [itmedia.co.jp]んだから、欠陥なんてあるわけないじゃないか!
      修正しているそばから改ざんする [nikkeibp.co.jp]というレベルの高い攻撃 [impress.co.jp]を仕掛けてくる、スーパーハカーによるサイバーテロ [kakaku.com]だったんだよ!

      #んなワケねーだろ
      親コメント
      • by __hage (7886) on 2005年05月24日 20時30分 (#740101)
        なんにしろ、ウィルスをばらまいている事を知っていたにも
        かかわらず「犯人追跡」だの「侵入経路の特定」だの理由をつけて
        サイトの運営を続けていたわけです。

        顧客を危険に晒してるのに順番がおかしいです。
        ナメきってると思いました。私はもう利用しません。

        # 直接の顧客は私のようなサイトの利用者じゃないでしょうけど

        私一人なら痛くもかゆくもないでしょうけど、
        こう思ってる人がどれくらいいるんでしょうね。

        ま、これに懲りて安全なサイトにはなるでしょうけどね。
        親コメント
        • >なんにしろ、ウィルスをばらまいている事を知っていたにも
          >かかわらず「犯人追跡」だの「侵入経路の特定」だの理由をつけて
          >サイトの運営を続けていたわけです。

          サイトの運営を続けるのは、俺はそれ自体が悪だとは思えないけど。
          既出の穴でパッチ当てているブラウザでは感染しないのだろ?被害が小さいと判断するのはおかしな判断とは思えない。
          被害の可能性や被害者への連絡を4日後に行なったのは遅い気もするが、4日でしかないとも言えるんじゃないの?
          親コメント
          • 「ともいえる」では大抵のことは言えてしまいます。

            利用者側の判断として「パッチを当てているから大丈夫」ってのはいいでしょう。
            サービス提供者側が「パッチを当てていれば大丈夫」と判断するのはどうなんでしょう。
            もっと踏み込んで「パッチを当ててないやつが悪い」というニュアンスを感じます。

            もちろんパッチを当ててないやつも少しは悪い、というか自業自得の面はあるでしょう。
            だからといってサービス提供者側がそれをアテにするのは間違った態度です。

            サービスを受ける側も提供する側も被害を広めない・受けない努力が必要です。
            それは、サービスを受ける側ではたとえばパッチを当てることです。
            サービスを提供する側ではたとえばサイトの運営を即時停止することです。

            不特定多数が利用するサイトですから、サービスを受ける側に素人さんがいることは
            容易に想像がつくはずです(つかなきゃ馬鹿です)。

            もう一度言います。顧客を危険に晒してまでサイト運営を続けたのは間違いです。
            親コメント
            • >不特定多数が利用するサイトですから、サービスを受ける側に素人さんがいることは
              >容易に想像がつくはずです(つかなきゃ馬鹿です)。

              それはそうなんだけどさ、IEでも古い奴やパッチ当てて無い奴の中には、開いたページのエレメントをscriptで拾って他所に送信可能だよね。
              これは容易に想像が付く問題だから、scriptは起動しないように切っておくべきだろうけど、必須のサイトは多く存在する。
              そう言ったscript必須のサイトは閉鎖すべきなんですか?
              カカクコムでの穴を突くパッチって、最近供給された奴じゃないよね。かなり以前でしょ。

              俺は「信用済みサイト」以外はscriptの実行は認めていない。当然/.も信用していない。
              でも、こんな奴ばかりじゃないことは容易に想像がつくはずです。

              ちょっとでも危険ならば即閉鎖すべきなんだろうか?
              即閉鎖した場合、書き換え方法がログから特定出来なければ、廃業すべきってことになりそうだよね?穴塞がずに再開出来る訳ないだろうし。
              って事は、社員がログが残らないように工作した場合は廃業?
              クラッカーがログを消して出て行った場合でも廃業?
              パケットキャプチャーする時間くらい与えても俺は良いと思うけど。

              ただ俺も一つ気になる点がある。
              何度も変えられた様だけど、それならば早い段階で犯人のIPアドレス分かっていた様な気がする点。
              その段階でトップページで告知すべきなんじゃ?と。
              俺は、しばらく「アクセス出来ない状況」で「変だな」と思ってたら、その後ニュースで流れて知ったよ。
              ウイルス感染被害者への配慮ならば、仮のサーバー立てて、早い内に告知すべきだったのではと思う。
              「アクセス出来ない状況」って、閉鎖していたが仮サーバー立ててなかったのでしょ?
              親コメント
              • >「ウィルスを配信している」状態が分かった段階でサーバ停止して
                >別サーバたててお知らせ出すぐらいはやっても良かったんじゃないでしょうか?

                「お知らせ出すぐらいは」ってのが難しいんじゃ?
                お知らせの告知を出すと、ばれたと思われクラッカーが再攻撃してこない可能性もあるよね。
                ログの削除と重なれば手口の特定が非常に難しくなるよ。
                そうすると、停止したサーバーの再開は困難 => ネット専業だから廃業と言う流れに。

                バランスを考えると「手口が判明しだい告知などの対処」がベストの様な気が俺はするね。

                逆に、ウイルス配信で即停止すべきと言うのがルールならば、ライバル社がサーバー管理者をたらし込めば、ウイルス配信しログ削除が可能だよね。
                2億とか出されればぐらつく奴はいると思うけど。
                サーバー管理者で、自分の管理下にあるサーバーのログの削除は技術的には可能と思っている人はいるんじゃ?
                話があれば、自宅サーバー立てて真面目に出来るか検証可能だよな。その後受けるか連絡すれば良いんだし。
                進入経路も書き換え手口も分からん。ログも削除されている。そう言った状況で犯人の特定が出来る確率は少ないんじゃないの?
                ウイルス配信で即停止すべきと言うのがルールならば、俺は逆にセキュリティーが保てなくなる様な気がする。
                親コメント
              • >セキュリティの専門家を招集して既知の脆弱性や攻撃手法で攻撃をテストし、成功したらその穴埋め。それが終わったら建前上「穴は無くなった」と言えるので、サーバ運用再開。

                「既知の脆弱性や攻撃手法で攻撃をテスト」って、単なる一通り?
                パッチ当てているか否かって問題ならばそれで直ぐ分かると思うが、CGIなどの不備って、そんな簡単に分かれば苦労しないと思うけど。
                >しかし結果として“最高の対策”とは呼べない部分はあったと思う」(穐田社長)
                http://www.itmedia.co.jp/news/articles/0505/25/news086.html
                と言っているくらいなんだから、「最高の対策」と呼べる対策はそもそも存在していたのでは?
                例えば、バッファオーバーフローの脆弱性も今でもたまにぽつぽつと穴が公表されるよね。
                テストプログラム回して簡単に脆弱性があるか分かれば苦労しない気がするけど。

                ついでに、
                「当社に過失はなかったが、詳細は明らかにできない」「今回の件は、過失や重過失に類するものではない」と「無過失」と述べている点と、
                >SQLインジェクションによるものだったする一部報道については「私どもから発表した事実ではない」(穐田社長)と、肯定も否定もしなかった。
                と言っている点は気になるな。
                OS、wwwサーバー、スプリクト言語辺りのどれかに未知の穴でもあったって言う話?
                >不正アクセスの手口は「判明している」(穐田社長)としながらも「類似犯罪のヒントとなる情報は出したくない」と、詳細は明かさなかった。
                からは、パッチの提供がまだされていない様な印象を俺は受けたけど、どうなんだろう?
                親コメント
              • >気になるもなにも「その通り」という回答そのものでしょ。

                「その通り」って、「SQLインジェクションによるものだった」ってこと?
                仮にそうだったとすると、彼の無過失の主張は戯言なのかな?
                それと、SQLインジェクションって情報流したのは情報の漏洩?情報の管理が出来ていないってことか?

                まぁ、掲示板は読めるけど書けない現状(読み込みCGIは可)を考えると、書き込みの特殊文字の無効化をミスった感じは濃厚だけど、彼は無過失を主張するんだな。
                親コメント
      • ところで「最高レベルのセキュリティが破られた」の報道したのはIT戦士の記事だけだっけ?
    • レイヤ違い (スコア:1, 興味深い)

      by Anonymous Coward on 2005年05月24日 20時28分 (#740100)
      SQLインジェクションが使われるのはアプリケーションの脆弱性。
      ただ、asahiの記事で問題にしているのはSQLインジェクションで実行されるDBアカウントを使って、「DBを乗っ取った」ことに関して。

      権限がしっかりと制限されていれば、SQLインジェクションを使われても情報流出は最小限に抑えられる。
      しかし、権限が制限されていないと、DB内の情報が全て攻撃者に漏れてしまうので危険。
      (ユーザIDが流出するだけで済んだはずなのにメールアドレス等の個人情報が流出した等)
      という話だと思われるが。

      #記事では「SQLインジェクション」と呼ばれる手法を『利用』ではなく『応用』って書かれてる。
      #SQLインジェクションが使えるっていうアプリケーションの脆弱性が無ければ侵入はできなかったとは思うが。
      #ただ、ここまでの話は「データベースを支配下に置いていった」というasahiの記事が正しければの話。
      #単にSQLインジェクションでデータを抜いただけなら話は別。
      親コメント
      • by Anonymous Coward
        > 権限がしっかりと制限されていれば、SQLインジェクションを使われても情報流出は最小限に抑えられる。
        > しかし、権限が制限されていないと、DB内の情報が全て攻撃者に漏れてしまうので危険。
        > (ユーザIDが流出す
    • 今時SQLインジェクションも無いだろうに。 誰かは知らんが犯人もびっくりした事でしょう。
      親コメント
    • 朝日新聞の記事の中ではこういうこと↓のつもりなんでしょう。

      「プログラム」= サーバとか、OSとか、ソフトウェア製品のこと
      SQLインジェクションの問題 = データベースの設定の問題

      朝日新聞(のデスク)にとって、Webアプリケーションという概念は存在しないのでしょう。

      予想される記者とデスクのやりとり:

      デスク:プログラムの欠陥を直していなかったのが原因なのか?
      記者:いえ、パッチは適用していたそうです。
      デスク:じゃあ、なんで起きたんだ。
      記者:SQLインジェクションという脆弱性だそうです。
      デスク:やっぱり欠陥を直していなかったんじゃないのか?
      記者:直すパッチはないんだそうです。
      デスク:どうしてないんだ?
      記者:kakaku.com だけの問題だからだとか。
      デスク:設定がまずかったということか?
      記者:そんなとこですかねえ。

      報道で伝えるべきは、ソフトウェア製品の脆弱性パッチをあてているだけではだめで、個別に開発したWebアプリケーション固有の脆弱性を、検査するなりして、排除しないといけないということなんですがねえ。
      親コメント
    • 被害者の言い分を鵜呑みにしてるんでしょうな。(--;
      「思い込まない」「鵜呑みにしない」がセキュリティの第一歩だと教えてあげませう。
    • >SQL注入されちゃうのはプログラムの欠陥だろ

      欠陥(バグ)とは、意図したとおりに動作しないもののこと。
      カカクコムのプログラムは、開発者の意図どおりには動いていたんだから、
      欠陥じゃないぞ。
      • ふむふむ……。

        ユーザー「これこれこういう条件だと、アプリがOSごと落ちるんですけど、これってバグですよね?」
        メーカー「いえ、仕様です」

        というのは欠陥とは言わないのか。
        知らなかった。

        # s○nyめ……。
        親コメント
      • ハァ?

        「意図したとおりに動作しない」は、安全に動作しなかったという意味で「意図したとおりに動作しなかった」わけだろ。だから、脆弱性は常に欠陥。でなきゃ、「このような結果を招いたのもプログラムの仕様です」とか言うんか?
        • 安全に動作することを要件に盛り込んでない仕様書って
          世の中にいっぱい(割合は不明)ありそうな気がします。
          その場合は安全に動作しなくても、「それは仕様です。」
          と答えて正解。

          #もちろん反論としては
          「それは(公序良俗に照らし合わせて)常識外です。」が
          ありますが。
          親コメント

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

処理中...