パスワードを忘れた? アカウント作成
10341 story
セキュリティ

ウェブアプリの脆弱性にどう対応してますか? 73

ストーリー by yoosee
日々の弛まぬ努力、だけでは足りなくなりつつあるかも 部門より

戸高芳広 曰く、 "現在ITproで「【緊急連載 今本当に必要なセキュリティ対策】」という連載が始まっている。この記事の中でカカクコムの穐田CEOは、「自社内では考えうる限り最高のシステムだと思っていたが,実際診断を受けたらそうとは言えないと指摘された」と述べている。

慢心した馬鹿だと思われるでしょうが、私にはこの人の気持が良く解ります。 個人的な話で恐縮ですが、今年の初めに報告されたAWSTATSの脆弱性の時には、私が脆弱性の情報をまだ掴んでいなかった1月19日から私のサイトに対して多数の攻撃が行なわれていました。インターネットからウェブアプリへのアクセスを認めないポリシーだった為、クラックは免れましたが、もし公開されていれば私のサーバはSELinux ターゲットポリシーを有効にしていたにも関わらず、スクリプトキディの遊び場になっていた事でしょう。

カカクコムに対する攻撃の詳細が報告されなかったり、ホワイト(グレイ)ハット的行為が日本では糺弾され、多少セキュリティに関心がある程度では、なかなかサービスを守りきるのが難しくなってきているように個人的に思います。
スラッシュドット諸志は、特にウェブアプリの脆弱性に対して、そしてクラッカーの手にサーバが落ちた時に備えて、どのような対策やポリシーを用意しているのでしょうか。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • お題、把握してますか (スコア:5, すばらしい洞察)

    by Anonymous Coward on 2005年06月17日 14時40分 (#753147)
    どれだけ頑張っても事故る確率は残るわけで、それをどうハンドリング、ケアしますか、という話なのでは。

    何故に「俺流 これがセキュアな web アプリケーションの書き方」みたいな話になっているのか。
  • WAF (スコア:3, 参考になる)

    by passa (9748) on 2005年06月17日 14時34分 (#753141) ホームページ
    Web Application Firewall使えばほとんど防げるのに、、

    商用(アプライアンス)だったら
    Teros [teros.com]とか
    TrafficShield [f5.com]とか
    NetContinuum [netcontinuum.com]とか
    SecureSphere [imperva.com]とか

    商用(ソフトウェア)だったら
    InterDo [kavado.com]とか
    AppShield [watchfire.com]とか
    # F5に買われたのか、、

    オープンソースならmod_security [modsecurity.org]
    使えば防げるよ。

    他にもあるけど、こんなに出てるのね。
    # 仕事中だけど、ま、いいや
    --
    • Re:WAF (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2005年06月17日 15時47分 (#753208)
      >Web Application Firewall使えばほとんど防げるのに、、

      どこかの社長の「最高レベルのセキュリティ」と同じ意識ですね。
      というかこういう製品は、正しいWhite Listを作らないと使い物になりませんし、望んだ効果も得られません。
      上の方にありますが、taint perlを使っておきながら$foo = ($foo =~ /^(.*)$/)[0] とかするような人には効果は得られません。
      正しいWebアプリケーションを作れない人/会社が、正しいWhite Listを作れるという、説得力のある理由がみつかりません。

      # もちろん、これらの製品を正しく設定すれば有用である事には異議はありません。

      親コメント
    • Re:WAF (スコア:1, 参考になる)

      by Anonymous Coward on 2005年06月17日 14時38分 (#753145)
      と慢心して、サーバの上に乗っけたアプリケーションの穴に気付かなかったんですよね。
      自分の行った対策がどのレベルを保護しているのか理解できないと無意味。
      親コメント
    • by kokugojiten (22778) on 2005年06月20日 8時51分 (#754429)
      ほとんど防げるのに、、

       この一言が中途半端ですね。
       むしろ「~使えば防げない攻撃はない」位言って欲しかった。(笑)
       そしたらもっと釣れたのに。
       
       
      親コメント
  • Javaの例だと (スコア:2, 参考になる)

    by gogler (17154) on 2005年06月17日 17時44分 (#753280)
    2,3年前は、色々気をつけていましたが、XSSやSQLInjectionぐらい
    なら、今ではフレームワークが解決してくれますね。
    これはトリッキーな機能や設計を防ぐ手段にもなっています。

    最近は、パラメータの改ざんに注意を払うようにしてます。
    機能としての汎用性を犠牲したり、あらゆる入力パラメータを
    想定して開発するといった若干精神論的なアプローチでまだまだ
    これだ!という解決策はありません^^;

    また、CSRFへの対応も難しいですね。単純な仕組みならAjaxで簡単に
    自動なんたらを作れてしまうし。ちょっとJavaScriptを知っていれば
    ブラウザ開いて適当な文字列を入力エリアに配置し、送信。送信確認。
    と全て自動で何かを行われてしまうサイトを作られてしまうでしょう。

    自動化の危険性を顧客(サービス利用者も含め)に伝えるのも仕事の
    一つですかね。
  • 対策 (スコア:2, 興味深い)

    by yellow tadpole (7084) on 2005年06月17日 22時50分 (#753428) 日記
    いかに対策しようと思っても、顧客が費用を払ってくれないと
    どうにもならないって事があるよね。
    「はやくシステムを稼動して欲しい」っていう要求ばかり強いと、
    こちらも人の子だから「じゃセキュリティは後回しにして・・・」っていう事にもなりかねない。怖い怖い。

    要所要所で「対策しないとヤバいっすよ」って一応は言うよ。
    そういう点では価格コム等の件は脅しに使える優れた事例ではあります。

    「対策に金出さないとやられますよ、知りませんよ」
    「そうは言っても予算が」
    「じゃ頑張って予算を獲得して連絡してくださいね。それまでは絶対責任持てません」
    「わかりました」

    しかし担当者はいつまで経っても連絡してこない。
    業を煮やして電話すれば

       「あ、あの人辞めましたよ」

    そっか、辞めたのか・・・。

    かくして私も転職するのです。
    --
    〜◍
  • by kacchan6 (19477) on 2005年06月18日 1時38分 (#753556)
    価格.comで問題になった時に、
    とあるSNSサイトのログインページに、
    ' or '' = '
    と、よくあるフレーズを入力したらログインできたので、
    管理者に状況を報告してあげました。
    これでボランティア2件目でした。

    ウェブでの商用サービスは、
    「ユーザが多い分システムが枯れているのかな」
    って思っていたんですが、ただの妄想に過ぎませんでした。

    素人が作っているんでしょうか。
    作っている最中に、普通に「これはマズイ」って思いませんかね。
    • by sen (197) on 2005年06月18日 5時45分 (#753621)
      > 素人が作っているんでしょうか。
      > 作っている最中に、普通に「これはマズイ」って思いませんかね。

      素人さんが作っているのであれば「まだ」救いがあるのでしょうが、
      考えにくいでしょうね。お金もらって商売している人がこのような状況を
      作り出しているのでしょう。
      # ある意味では「素人」になるのでしょうが。

      多分「マズい」ということに素で気づいていない、に100ガバス。
      親コメント
    • by Elbereth (17793) on 2005年06月18日 11時32分 (#753743)
      SNSサイトなんて数えるほどしかないんですから、
      これを見て総当り攻撃するバカが出て問題になったら
      犯罪教唆にあたりませんかね?

      素人が報告しているんでしょうか。
      書き込んでいる最中に、普通に「これはマズイ」って思いませんかね。
      親コメント
  • とりあえず (スコア:1, 参考になる)

    by Anonymous Coward on 2005年06月17日 14時08分 (#753123)
     ・バリデーションされていない入力データは有害。
     ・サニタイズされていない出力データは有害。

    だけでも認識されていればそこそこ安心できそう。
    • Re:とりあえず (スコア:1, 参考になる)

      by Anonymous Coward on 2005年06月17日 14時45分 (#753153)
      perlのCGIなら、taintperl 強制で、バリデーション済のデータかどうかをperlにチェックさせるというのはどうですかね。
      「perl -wT が通らないCGI? そりゃダメだね、怖くて使えないよ」って意識が広がれば成功。

      #面倒になって $foo = ($foo =~ /^(.*)$/)[0] をやったことがあるのでAC
      親コメント
    • by maoyam (16680) on 2005年06月17日 23時23分 (#753445) 日記
      こんなフィルターをヒマな時に作ってみたんですけどね。
      使えますかね?

      正規表現を利用した入出力バッファ・チェック・ライブラリ:
      http://www.toshima.ne.jp/~maoyam/buffer_checker/index.html
      親コメント
  • 他レスにもあるように、
    とりあえず入出力のサニタイズですかね。。

    後出来る限りPreapareでのDBアクセス。
    ただDBアクセスせずに式入力(そんなのあるか?)みたいなのだとコマンドインジェクションも。。。
    やはりサニタイズ??

    ただ、それでも漏れはありますし、プラットホームの脆弱性でサニタイズだけでは対応できないこともありますから。
    おきた場合の対処のマニュアルも重要。

    >慢心した馬鹿。

    ええ。思います。
    オフとぴ気味、別議論になりそうですが、セキュリティ対策とは侵入対策、改竄対策、ウィルス感染対策などの受けだけを、また技術的防御策だけを指すものではありません。
    万一、感染、改竄された場合の対処のマニュアル等も含めた総合的なものです。

    たとえばパターンファイルが間に合わずにウィルス感染してしまった場合でも、今度は2次感染者を出さない為の対策ができているかもセキュリティ対策です。
    普通は感染したら、即座にネットワークから切り離しますよね?そのPCからの2次感染しゃを出さない為に。
    サーバーなら尚更です。

    今回カカクコムは自分のサーバーが改竄によりウィルス感染しているのを知りながら、情報収集の為と称して稼動を続けエンドユーザーに多くの2次被害者を出しました。
    ”2次被害者をださない”この視点が全く欠けている。

    セキュリティ意識がと技術がこの時点で引く過ぎる。
    ”考えられる最高レベルのセキュリティ対策をしてきたつもり”とはIT関係者なら口が裂けても言える状態ではない。

    あの事件でカカクコムを擁護している人間は、カカクコムはある時点から完全な加害者であるという意識を持っていない人が大勢。

    感染、改竄に気がつかない間->カカクコムは完全な被害者。責任の大半は攻撃者。
    感染、改竄に気がついた後運営していた間->カカクコムはユーザーから見て完全な加害者。ユーザーの感染の責任の大半はカカクコム

    そこをよく考えてみてほしい。。
    • 引く過ぎる。->低すぎる。TYPOすまん。
      親コメント
    • 感染、改竄に気がついた後運営していた間->カカクコムはユーザーから見て完全な加害者。ユーザーの感染の責任の大半はカカクコム

       被害者は被害認識後、適切な対応が出来ないと加害者ですか・・。ほんとに迷惑な被害だな。
       攻撃者は「今対応することを強制」することができるんだもんね。
      親コメント
      • 知識の低い一般ユーザーならば、まだ許せるが

        ”最高のセキュリティ対策”を詠ってるIT企業なら2次感染対策は当たり前でしょう。 ”今対応すること”も。 (自分が感染し2次感染がおきることがわかっていた上で)何も対策せず、多くのユーザーの2次感染を引き起こしたのですから、言い訳は効かない。

        今回のカカクコムの一番の間違いは個人的にはここだと思ってる。 #SQLインジェクション対策や防御をおざなりにしていいという話ではない。

        #例えるなら、防火壁で建物建てて、防火は完璧といって室内にスプリンクラーつけず、消火器設置もなし。窓も一般の窓。家の中には可燃物一杯ww。
        #で、最高の火災対策と吹聴すると。あほかと。
        親コメント
        • >”最高のセキュリティ対策”を詠ってるIT企業なら2次感染対策は当たり前でしょう。 ”今対応すること”も。 (自分が感染し2次感染がおきることがわかっていた上で)何も対策せず、多くのユーザーの2次感染を引き起こしたのですから、言い訳は効かない。

          #いくらやっても平行線でしょうな。

          としたうえで

          見物客からは金取らないで直接経済的な利益のある情報を与えるサービスで

          「知ってて理解してて対策出来てる」事や
          「非常時にどうするかをあらかじめ ないしは 納得されるほど迅速に的確な対応をするための知識や知恵を持ってて適用する」

          事を要求するってのは どうも「知ってる側」のエゴのようなきがするんでさ。

          経営的に見ても 

          ・分間○○○万稼ぐ
          ・社会的意義も大きいサイト
          ・ウィルス感染してしまいました
          ・でもまだ運用できてます

          ってなったときに

          1.運用全止めで直るまで対策する。
          2.運用しながら対策。(直ったら自分から報告 or だまっとく)
          3.放置。

          だったら カカクコムの取った対策は 3の様に言われているが
          普通の経営者だったら2を取りたいしカカクコムもそうしたでしょ。

          1だったら1で(結果しかみない)ステークホルダー様が(彼らにとって訳のわからない)サイトの停止にお怒りなすったでしょう。

          また技術者にしても、結果的に対策できなかったカカクコムの技術力はばれてしまったわけですが、そんなピンチの超高緊張時にゃ 技術者も技術的な問題の対策力も調査力も判断力も半減ですよ。
          #この意味からも、あらかじめ調べておくってのは大事だね。

          「知らない人」ってのは「知らない」事を「知らない」んだよ。
          だから自分の知ってる中で最高とか誇っちゃうの。
          どんな状況であれ「知ってる」事に金を払っている訳じゃなければ相手に「自分が知ってる」事を強要するのは勝者の論理とおもうぜ。

          でも だんだん良くなってるじゃん カカクコム。

          それでも俺は使いたいなぁ。
          親コメント
          • 経営者側が2を取りたいのは解るが、モラル適にも、技術的にもやってはいけない事。

            問題はカカクコムは
            ”2次感染が起きる事を知ってた”って事。
            2次感染が起きる事を知った上で数日間運用をつづけた。

            語幣を恐れずにいえば2次感染が起きる事を知ってた上で利益を優先し、故意にユーザーを2次感染させたって事。

            +知らなかった以降、問題を起こし、知った後でも、
            過失はない

            なんて発言をしている。
            http://itpro.nikkeibp.co.jp/free/SI/NEWS/20050525/161513/

            防御技術がもし本当に完璧だったとしても、運用過失は間違いなくあった訳だ。

            なのに過失はないなんて発言をしている。

            ”考えられる最高レベルのセキュリティ対策をしてきたつもり”
            も事件後の言葉。事件に何も学んでいる様には見えない。

            こういう企業は同じ事を繰り返す。学ぶつもりも無いし、学んだとしても利益優先でそれを生かすモラルが無いわけだから。
            私には本当の意味で、何も反省しているようには見えない。

            だから、カカクコムには厳しい事をいうべきだと思う。
            それが私の考え。

            平身低頭謝るなら、まだ対策していこうという気があるように見えるんだけどね。
            口だけで証拠は出さない。運用は滅茶苦茶だったじゃ擁護の価値はない。
            親コメント
          • 知らなかったんなら
            ”過失はない。”
            ”最高のセキュリティが破られた”

            なんていわずに、

            ”最高のつもりがガタガタでした。ごめんなさい。一から出直します。"

            って言えばいいんだよ。。
            それならまだ反省してるな。これからは大丈夫になっていくな。。と見えるのに。。
            親コメント
          • >ステークホルダー様が(彼らにとって訳のわからない)サイトの停止にお怒りなすったでしょう

            ならば2次感染者を故意に出していいとでも?

            >また技術者にしても、結果的に対策できなかったカカクコムの技術力はばれてしまったわけですが、そんなピンチの超高緊張時にゃ 技術者も技術的な問題の対策力も調査力も判断力も半減ですよ。

            だからこそ一時的に止めた上でログなり何なりを元に、ゆっくり調査・対策すべき。
            結果的にその方が判断力の回復が早い。
            ログすら取ってないんなら、運用として最悪。
            親コメント
  • 何もせず相手がボロを出すのを待ちます(w
    あとは、詳細を伏せ「わが社の対策は完璧だった」で押し切ります。
    --
    ヒースキット山口 heath yamaguchi
  • サニタイジングなどの必要な(予想のつく)対策を施していても、何事においても完璧ってことはないので、「何かヘンなことがおきている」ってのをどうやって監視するかも重要ですよね。と、ひとことで言っても、ファイルシステム上で監視したりネットワークの出入り口で監視したりログインやプロセスの実行をログったりとたくさんありますよね。個人で実験的に挙げているサーバだとそこまで手が回らないので、どっか抜けちゃうんですよね。

    個人レベルだと「できるだけ気をつける」か「サーバ上げるのやめる」かの二択になっちゃうなぁ。
    --
    屍体メモ [windy.cx]
  • 500円 (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2005年06月17日 16時16分 (#753225)
    ユーザ数*500円の資金を常に用意しています。
  • by Elbereth (17793) on 2005年06月17日 17時37分 (#753274)
    しばらく前の日付の辞職願と、しばらく身をひそめるセーフハウス、
    当座の生活資金あたりを用意しておけば何とか逃げられるんじゃないかと
    思ったりして。徹底するならパスポートも用意しておいた方がいいかも。

    え、そういう話ではない?
  • by Anonymous Coward on 2005年06月17日 20時35分 (#753358)
    自分に責任が降りかからないよう、お客さんや周りの人間に、 「Webアプリの脆弱性経由でクラックされることもあるんだよ~」 という地道な啓蒙活動してます・・・ 万が一侵入されたら、サーバ管理者のせいにされそうで怖いんですもの。 開発側にも言ってるんだけど、なかなか意識してもらえなくて・・・
  • by uxi (5376) on 2005年06月18日 1時35分 (#753553)
    PHPの場合
    SQLインジェクション対策には
    PEAR::DB->quoteSmart()
    XSS対策には
    htmlentities()
    かな、、、
    --
    uxi
  • by Anonymous Coward on 2005年06月17日 14時00分 (#753118)
    DBへのアクセスはPreparedStatement。
    原理的にSQLインジェクションは発生しないので。

    でも結局のところは一生懸命情報を収集するしかないのですけれどね。
    • by 0-9a-zA-Z_.+!*'(),-\ (6182) on 2005年06月17日 16時15分 (#753224)
      likeには気をつけましょうね。
      PostgreSQLのJDBCだと、 % はエスケープされずそのまま渡されます。
      バージョンによって違うかもしれませんが。

      他のDBはどうなんでしょう?
      親コメント
    • by Anonymous Coward
      条件分岐で検索条件が変わる時は
      その分だけのPreparedStatement作るんですか?
      • by tit (23686) on 2005年06月17日 15時30分 (#753194)
        その場合は都度、PreparedStatementを生成してあげれば良いかと思います。
        情報源は定かではないのですがJavaの場合、PreparedStatementを生成する際に
        コンパイルされたSQL文はキャッシュされるはずですので
        Statementを都度生成するより効率的です。

        誰か詳しい人、補足をお願いします…;
        親コメント
        • Javaの場合ってか、Oracleの場合はSQLの字句を比較して過去の解析
          結果を使いまわすキャッシュがあったはずです。
          あらかじめPrepareしておけばこのキャッシュから探す手間も
          省けます。
          が...
          条件によってSQLを動的に生成するという事は、下手するとキャッシュ
          にヒットしないんじゃない?

          私だったら、デカイSQLでRDBMS側に条件判断させる事も検討します。
          そうしないと、SQL動的生成する部分に脆弱性っつかバグが紛れ込む可能性
          が出てきますから。
          # 実行計画次第ですがね。
          --
          wild wild computing
          親コメント
          • Re:とりあえず (スコア:3, 参考になる)

            by SteppingWind (2654) on 2005年06月17日 17時26分 (#753262)

            オンライン・トランザクション処理でミリ秒単位のレスポンスを要求するシステムではPreparedStatementの使用が事実上必須ですね.

            Oracleの場合, SQLのコンパイルにかかる時間は(もちろんSQLの記述によって全く異なりますが)おおよそ数100msのオーダー, 一方コンパイル済みのSQLをキャッシュから探すのが数msのオーダーです. そのため秒間数10~数100程度の問い合わせがあるシステムでは, 動的SQLを使うとデータが十分にバッファリングされてIO負荷に問題の無い場合でもCPUネックでシステムが回らなくなる場合があります. 一般には多くの業務システムでSQLキャッシュヒット率は95%以上が望ましいと言われていますが, 経験的には大規模システムで確実に回す場合, 最低でも98%. 99%以上もあたりまえって感じです.

            あと, ある程度以上の規模のシステムではRDBMSサーバとアプリケーションサーバが分離されていてネットワークで繋がっているという構成も多いです. この場合RDBMSサーバ側でできるだけ条件判断を行わせてRDBMSサーバとアプリケーションサーバ間のネットワークに余分なデータを流さないというのも性能に効いてきたりします.

            親コメント
            • by Anonymous Coward on 2005年06月18日 0時20分 (#753489)
              ORACLEの場合、8だか9だかあたりからパフォーマンスの為に設定によって動的SQLでも似たものはキャッシュ使うようになってるとか聞いたような。
              実際以前よりは動的SQLにパフォーマンスに難が無くなりました。
              Prepare構文に変換出来るものは内部的に変換してキャッシュ率上げるとか。。うろ覚え。違ってたらごめんなさい。

              それでも最初からPrepare使った方が早いですし、インジェクション対策にもなるので良いのは変わりませんが。
              親コメント
            • by Anonymous Coward on 2005年06月18日 17時15分 (#753873)
              動的SQL文が増えるとSQLトレースもノイズだらけになりますし、
              そのコンパイル時間によってOSとDBサーバアプリのI/O WAITも
              隠蔽され、性能分析/改善が難しくなります。

              まず最初に動的SQL潰しをやってから真面目に分析しましょう、
              なんて話はよくありますし、その分改善コストがかさみます。

              単発ツールなら別ですが、システム開発であればPreparedは必須で、
              動的SQLの使用は許可制が良いかと。
              # オフトピックですいません。
              親コメント
      • by Anonymous Coward on 2005年06月18日 17時58分 (#753900)
        貼っておきます。
        NULLとUNKNOWNを積極的に活用するSQLの書き方 [no-ip.info]

        しかし,webアプリの検索フォームなどでは,プリペアドステートメントは使えない場合が多かった.検索条件項目が複数存在していて,いずれの項目も必須で無い場合,項目が入力されているかどうかをチェックし,それに合わせてSQL 文の WHERE 句の内容をツギハギしなければならないからだ.

        SQL文そのものも,そしてそれにセットする引数の個数も可変なので,プリペアドステートメントを使うのは無理だったのである.

        今回思いついたのは,このような条件で,プリペアドステートメントを使う方法である.
        親コメント
  • by Anonymous Coward on 2005年06月17日 14時01分 (#753120)
     
     (冫、)ノ < ハイ 私もその一人です
                ごめんなさいッッ
     
     
    #絶対AC
  • by Anonymous Coward on 2005年06月17日 14時16分 (#753128)
    htmlspecialchars
typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...