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

価格.com、サービス再開へ 237

ストーリー by Acanthopanax
信頼回復できるか 部門より

tetsuya 曰く、 "クラックされ、5月15日からサービス停止に陥っていた価格.comが24日午後にサービス再開する見込みです(編注: 掲載時点ではまだ再開されていない)。サイト再開のお知らせ(23日付)には「システムの再構築、各種セキュリティ検査、最終テストを経て、明日24日(火)午後に当社運営サイトを厳重な監視体制の下、再開することとなりました」とあります。この辺を報じたasahi.comの記事によると、今回のクラックはSQLインジェクションによりDBを乗っ取られたということのようです。タレコミ子はWEB開発に関して全くの素人ですが、SQLインジェクションに関しては教科書的なサイトにもよく取り上げられるほどであり、基本的な対策の様に思えます。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • MSSQL (スコア:4, 興味深い)

    by kacchan6 (19477) on 2005年05月24日 23時25分 (#740232)
    MSSQLはサニタイズと実行権限の設定を
    キチンと行わないと非常にヤバイです。

    他のDBは詳しくないのですが、MSSQLは拡張ストアドで
    コマンド実行やCOMのインスタンス生成ができます。
    さらにSQL文を区切らなくても平気で連続実行できてしまいます。

    インジェクションを行えば、
    select * from user where userId = '$ここに入力値$'
    が、
    select * from user where userId = '' sp_xxxxx(適当なストアド) select 1 where ''=''
    みたいな感じで実行できてしまいます。

    本来、ユーザIDが入力されるところで、
    ' sp_xxxxx(適当なストアド) select 1 where ''='
    と、こんな感じで入力すれば何でもできてしまいます。

    サニタイズの簡単なチェックとしては、
    入力フォームで、「'」と入力してみましょう。
    エラー画面になるようだと危ないです。
  • 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の記事を読み直した方がいいんじゃないか?と思うのは気のせいですか。
            「ソフトの不備ではなく、データベースの安全設定が不十分だった点を悪用された。」(一部引用)

            #というより、この記事を読んで擁護や正当化と取る人もいるなんて、このコメントを見るまで思わなかった。
            親コメント
      • (誤)本当にクラックの方法が記事どおりだとしてら
        (正)本当にクラックの方法が記事どおりだとしたら
        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 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)
        なんにしろ、ウィルスをばらまいている事を知っていたにも
        かかわらず「犯人追跡」だの「侵入経路の特定」だの理由をつけて
        サイトの運営を続けていたわけです。

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

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

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

        ま、これに懲りて安全なサイトにはなるでしょうけどね。
        親コメント
    • レイヤ違い (スコア:1, 興味深い)

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

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

      #記事では「SQLインジェクション」と呼ばれる手法を『利用』ではなく『応用』って書かれてる。
      #SQLインジェクションが使えるっていうアプリケーションの脆弱性が無ければ侵入はできなかったとは思うが。
      #ただ、ここまでの話は「データベースを支配下に置いていった」というasahiの記事が正しければの話。
      #単にSQLインジェクションでデータを抜いただけなら話は別。
      親コメント
    • 今時SQLインジェクションも無いだろうに。 誰かは知らんが犯人もびっくりした事でしょう。
      親コメント
    • 朝日新聞の記事の中ではこういうこと↓のつもりなんでしょう。

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

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

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

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

      報道で伝えるべきは、ソフトウェア製品の脆弱性パッチをあてているだけではだめで、個別に開発したWebアプリケーション固有の脆弱性を、検査するなりして、排除しないといけないということなんですがねえ。
      親コメント
  • by Anonymous Coward on 2005年05月24日 22時28分 (#740189)
    あーあ

    ボランティアベースでoffice氏みたいな人がせっせとおせっかいを焼いている以前の状況であれば防げたかもしれないのに。

    >「もし」office さんが逮捕されていなかったら、私はおそらく SQL インジェクションができないかどうかチェックしていたでしょうから
    (http://bakera.jp/hatomaru.aspx/ebi/topic/2324)

    だからって「法律」として整備するなといいたいわけではなく。
    *善意から*脆弱性を探す人が今までいっぱい居たわけで、その人たちを生かす形にできなかったのはやっぱり失敗だと思う。
    • そのページを読んだ限りでは、「絶対秘密は守るから脆弱性の検証をさせてくれ」と頼んではいなかったように見えるのですが。むしろ「office氏が逮捕されてなきゃ(無断で)検証してたのに」というニュアンスを感じました。
      検証される側からするとそれってどうなんでしょう。「脆弱性を見つけても機密情報を手にしてもそれを悪用しない」という確約を取り付ける前に検証されては、される側からすれば”検証後にその成果を教えてくれた”以外には実際に攻撃されたのと同じじゃないですか?(勿論これも大きな違いではあるが、通報者の善意…というか”悪意が無い事”を証明する物ではない)

      > office氏みたいな人がせっせとおせっかいを焼いている以前の状況であれば防げたかもしれない

      更に言えば、office氏みたいな人がこの事件を引き起こしたかもしれませんね。office氏自身、ACCSの件以前にも数々の脆弱性を発見すると同時に得てきた情報を悪用してないとは限りませんし(今までこの疑いを抱いている人を見た事が無いのですが、office氏って昔はそんなに信用のあった人物なんですか?)。

      # という感じの事を前も書きました [srad.jp]。「いきなり検証済み脆弱性を報告してきた人」に企業側ではどんな対応をするのか、どなたか教えて頂けないでしょうか。少なくとも素性も探らないままなんて事は無いと思いますが…
      親コメント
  • by shiroiwanisan (12855) on 2005年05月24日 19時28分 (#740069) 日記
    19:26現在まだ再開されていないようです。
  • Win系かUNIX系か、どっちのOSdでサービスを再開するのかは見ものだね。
    • Re:ところで (スコア:1, 興味深い)

      by Anonymous Coward on 2005年05月24日 20時34分 (#740103)
      以前カカクの掲示版でM$SQLサーバのタイムアウトエラーが表示されたことがあります。 1週間やそこらでM$から他DBへの乗換は無理では...
      親コメント
      • Re:ところで (スコア:2, 参考になる)

        by Anonvmus Coward (27270) on 2005年05月24日 21時55分 (#740164)
        私も見たことあります、
        800 何チャラとか言う画面ですね。
        ODBCのエラーだったような記憶が・・。

        結局ODBC経由で”単純に”作られているアプリならば、
        1週間もあれば対応できるのではないでしょうか。

        でも、DBの標準の関数(と言うかストアードか)
        をSQL内で使っていたら、代換えを作るのに
        時間がかかるかも知れませんが・・・。

        以前 PostgreSQLで作っていたものをOracleに
        かえる時に、TOP使っていたりとか、
        逆にOracleでTO_NUMBERと使ってたら、
        予算がやっぱり無いからクラサバでACCESS
        をローカルでDBに持ってとかで、大変な
        目にあいました・・。
        SQL内でそのDB専用のものは使うべきでは
        無いを痛感・・。
        #まっ、コロコロDB環境が変わるような
        #客も困りもんだが・・。
        親コメント
  • by esumi (15966) on 2005年05月24日 22時59分 (#740204)
    SQLインジェクションを許してしまう仕様のどこが
    最高レベルのセキュリティなんでしょうか。
    以前言ってた事とつじつまがあってないじゃないですかカカクコム様(汗
  • またIIS (スコア:1, 余計なもの)

    by fuku (1936) on 2005年05月24日 23時54分 (#740244) 日記
    再開されたようですね。
    またIIS [netcraft.com]だそうです。

    Linux+Apacheだったのは一時閉鎖時だけだった模様。

    ---
    IISは個人的に嫌いです。
    • by doripush (653) on 2005年05月25日 0時12分 (#740258)
      報道されていること(OSやサーバソフトウェア自体の
      脆弱性が問題だったのではなく、ソフトウェアの設定や
      開発したプログラムにセキュアでない部分があった)が
      本当だったとすると、今まで同様IISでサービスすることは
      至極当然でしょう。

      トラブルの混乱から、問題でない部分まで変えてしまい
      予想外の結果を招くのは、よくありがちな失敗パターンです。
      最終的には、今後の結果がすべてを決めるのでしょうが、
      とりあえずは賢明な判断だったと考えます。
      親コメント
typodupeerror

人生unstable -- あるハッカー

読み込み中...