パスワードを忘れた? アカウント作成
46591 story
プログラミング

最も危険なプログラミングエラーTop 25 41

ストーリー by hylom
やはりよく言われている問題が多い、 部門より

あるAnonymous Coward 曰く、

CWESANSが共同で「最も危険なプログラミングエラーTop 25」を取りまとめ、発表した。

このリストはSymantecやMicrosoft、米国国土安全保障省の国家サイバーセキュリティ部門、また日本の情報処理推進機構(IPA)など、国際的かつ多岐に渡る組織の協力を得て作成された。パフォーマンス上の問題やセキュリティ上の脆弱性、またサイバー犯罪の原因となり得るプログラミングエラーのうち、特に頻度と危険性の高いとされるものが25点挙げられている。

エラーは大きく「コンポーネント間のコネクションが適切に保護されていない」「危険なリソースマネジメント」「不備のある防衛策」の3種類に分類され、それぞれのエラーには簡単な説明と対処法などが記述されている。挙げられているエラーは「入力データの検証不備」やSQLインジェクションの原因となる「SQLクエリの保護不備」、またバッファオーバーフローを引き起こす「メモリバッファ境界チェックの不備」といったものが挙げられている。「パスワードのハードコード」を含め基本的なエラーが多いようだが、これら危険なエラーがそれなりの頻度で起きているというのが実態らしい。

InformationWeek blogではこれらのエラーは現在の開発体制が原因となっているとのエントリが掲載されており、本家/.で紹介されている。それによると(問題のある開発モデルではあったが)昔ながらのウオーターフォール・モデルを捨て、出荷までに出来る限り多くの機能を盛り込み、その後手直しをするといった現在の開発モデルに問題があると指摘し、また多くのセキュリティ脅威が潜む現在だからこそ、若い開発者たちがソフトウェア開発の歴史を学ぶことに意義があるとのことだ。

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

    by eureca (13651) on 2009年01月14日 18時14分 (#1491109) 日記

    訳してみました。不適切な言葉の使い方など、ツッコミあればお願いします

    コンポーネント間のセキュアでないアクセス
    - 入力の検証忘れ(数値か文字列かのチェックなど)
    - 出力のエスケープ忘れ(制御情報とデータの分離を忘れるなど)
    - SQLインジェクション
    - クロスサイトスクリプティング
    - OSコマンドインジェクション
    - 重要情報の平文通信
    - CSRF
    - 競合状態(レースコンディション)
    - エラーメッセージ漏れ

    危険なリソースマネジメント
    - バッファ内で操作が制限されていない
    - クリティカルセクションに外部からの変更ができる
    - ファイル名、ファイルパスに外部からの変更ができる
    - 信頼されていない検索パス(検索によって設定ファイルなどが検出できる)
    - コードインジェクション
    - チェックが不完全な(悪意の改竄のある)コードのダウンロード
    - リソース開放忘れ
    - 初期化忘れ
    - 不正確な算術(整数掛け算のオーバフロー、浮動小数点演算の丸め誤差など)

    穴の多い防御
    - 認証忘れ
    - 脆弱性のある暗号アルゴリズムの使用
    - ハードコーディングされたパスワード
    - 重要資源への不適切なアクセス制限
    - 不十分な乱数の使用
    - 不必要な特権を使った実行
    - クライアントサイドに依存したサーバセキュリティ(リバースエンジニアリングを使っ>たなりすましの危惧)

    • Re:TOP25の内容 (スコア:5, 参考になる)

      by Anonymous Coward on 2009年01月14日 21時49分 (#1491263)
      危険なリソース管理のところがちょっと違うような気がします。
      こんな感じかと。

      - メモリバッファ境界内の操作に限定することに関する怠慢 (バッファオーバーフロー)
      - クリティカルな状態データの外部制御 (hiddenやクッキーにセッションデータがそのまま入っているなど)
      - ファイル名やパスの外部制御 (ディレクトリトラバーサル)
      - 信頼されていない検索パス (ロードパスをあれすることで悪意あるライブラリを読み込ませるなど)
      - 実行コードの生成の制御に関する怠慢 (コードインジェクション)
      - 信頼性チェックをしないコードのダウンロード (DNSスプーフィングで攻撃者のサイトからダウンロードさせられているなど)
      - 不適切なリソースの停止処理または解放 (解放忘れ・二重解放・解放後の使用など)
      - 不適切な初期化 (初期化忘れ・クリティカルな内部変数を外部から初期化できる・未初期化で再利用されるため以前の内容が読めるなど)
      - 不適切な計算 (整数オーバーフロー・0除算など)
      親コメント
    • by Bumpkin (32664) on 2009年01月14日 22時58分 (#1491314)

      ここに挙げられているミスが致命傷になりやすいのは重々承知ですが、
      危険性の低いミスってどんなもんでしょうね?
      暗黙の型変換に頼りきったコードとかでしょうか。なかなかいい例が思いつきません。

      親コメント
      • by nim (10479) on 2009年01月15日 1時35分 (#1491400)

        受託開発してれば思いつくのでは。

        「FireFox で見るとナビゲーションバーの下に隙間ができる」とか、
        「表示金額が10桁以上になると、折り返しが発生してしまう」とか。

        親コメント
      • by Anonymous Coward
        飲み過ぎ、食べ過ぎ、社内恋愛
        • by Anonymous Coward

          どれも致命傷になりうる危険性の高いミスだと思うが…。

          人によっては。

      • by Anonymous Coward

        ・どこからも呼ばれないテストロジックの消し忘れ
        ・納品物としてどうよ?という内容のコメント
        ・同じロジックが別クラスに点在する

        要するに、コーディング規約レベルのミスを犯せばいいんじゃないでしょうか。

      • by Anonymous Coward
        publicな名前の定義のTYPOとかでしょうか(意味が誤解されないような場合に限る)。

        # 暗黙の型変換は意外と危険ですよ。予期せぬ演算エラーの元になりますので。
    • by Anonymous Coward
      > エラーメッセージ漏れ

      エラーメッセージからの情報漏洩

      でしょうかね。
  • by sladoslado (28918) on 2009年01月14日 19時46分 (#1491179)

    SANS Institute 2006年に発見報告された脆弱性を対象にした2007年調査によると
    http://www.sans-ssi.org/resources/top_three.pdf [sans-ssi.org]

    脅威度の高い脆弱性の85%は3つのErrorに分類されるそうで
    1.不適切な入力値処理
    (Error 1. Accepting input from users without validating and sanitizing the input)
       入力値の検査が無いor不十分な検査で想定しない入力値を許してしまうError
    2.バッファーオーバーフロー
    (Error 2. Allowing data placed in buffers to exceed the length of the buffer)
       確保されたバッファ領域外へのデータ書き込みを許してしまうError
    3.不適切な整数利用
    (Error 3. Handling Integers Incorrectly)
       整数型の最大値の上限を超えるor最小値の下限を超えてしまう事を許してしまうError

  • 実話 (スコア:3, 興味深い)

    by urx (4084) on 2009年01月14日 18時40分 (#1491130) 日記

    誰だ、サーブレットに

    System.exit(-1);

    なんて書いたのは!

    # それで落ちるようなサーバ設定にも難あり。

    • by odacle (36537) on 2009年01月15日 18時59分 (#1491896)

      cmd.exeだとbatファイルにexitと書いてしまうとbatだけでなくcmd.exeが終了してしまいますね。
      正しくはLABELを書いてgoto ENDみたいにして最後まで読み飛ばすという。。。
      最初みたときになんじゃこりゃとか思った。

      親コメント
      • by Anonymous Coward

        cmd.exeならexit /bで。
        command.comではエラーになっちゃうけど。

    • by Anonymous Coward
      アプレットにSystem.exit()があるとブラウザごと落ちるというバグを見た記憶が。
  • by Anonymous Coward on 2009年01月14日 18時20分 (#1491114)
    ぬるぽ
    • by Anonymous Coward
      これの何所が荒らしなの?
      • Re:ぬるぽ (スコア:1, 参考になる)

        by Anonymous Coward on 2009年01月14日 20時19分 (#1491204)

        「ぬるぽ」が NullPointerException から来ていることを知らない人もたくさんいるから、なのかな。
        でもぬるぽ自体は結果に過ぎないよね。
        安易にぬるぽを起こすようなコーディングをしてはならない!といいたいのかな。
        どっちにしても意図がわかりにくいよね。

        親コメント
        • by SteppingWind (2654) on 2009年01月14日 20時54分 (#1491227)

          とはいえ, ぬるぽで検出できるってのは良性ですよね. と言うか, Javaなんかの初期設定が定義されている言語では, 最悪ですらこの程度ってことで.

          Cなんかのポインタの初期化は自前でって思想の言語だと, 特にMMUが貧弱な環境であれば, ポインタが未設定の状態で使用すれば何が起こるか全く保障されないわけですし.

          親コメント
          • Re:ぬるぽ (スコア:1, 興味深い)

            by Anonymous Coward on 2009年01月15日 7時31分 (#1491443)

            対策は「まずはソースよこせ。話はソレからだ」ですかね。
            Cのようにノーガード戦法な言語だと、オープンソースというライセンス形態を後押ししたくなる理由が少なくとも1つ多いわけですね…

            あとソースといえば、支配のきつい職場での馬鹿コーディング規約にもしばしば困らされます。
            典型的に困るのはいわゆる変数の「初期化」を禁止するという規約。
            これじゃ(プロセスを)殺してくれといってるようなものです。
            そういうのを設定してる職場ってマヂあるんです。

            馬鹿規約は馬鹿規約やそれに基づいたソースがCLOSEDだからこそ何時までたっても直らないんだろうと私は想像しています。
            あんなの世間に晒されたら即効で笑いものになったり(コードを)攻撃されたりして信用失墜。
            秘密主義はその失墜を遅らせてるんですよね。
            もちろん失墜するリスクは永らく抱え続ける地雷であり、無くなるわけではない。

            親コメント
            • by Anonymous Coward

              変数の初期化を禁止するメリットというのは何なんでしょうか。
              逆なら思いつくのですが。

              #業務の片手間にちょこちょこツール書いてる程度なので、先人の知恵的なのはまったく知らんのです。

              • by Anonymous Coward
                いや、私もこの業界に17年ほどいるんだが、
                変数の宣言時に初期化しない事を禁止した規約は見たことがあるが、
                変数の初期化を禁止する規約は見たことがないな。

                当然、static 変数や、const 変数は使用禁止だ。
                C++ならコンストラクタの全面禁止だな。
        • Re:ぬるぽ (スコア:1, 興味深い)

          by Anonymous Coward on 2009年01月15日 1時59分 (#1491404)

          ぬるぽ対策として、tryしてcatchしたはいいけど、そのまま受け流してしまっているコードが意外とあるんじゃないでしょうか。

          try{
              doSomething();
          } catch (Exception e){
              // 何もしない
          }

          catchしなければ例外が起きた箇所がその場でわかるのに、例外処理が中途半端だったためにデバッグが面倒になったりってこと、あるんじゃないでしょうか。
          そもそも例外が起きているのに例外がなかったことにできるから、中途半端な例外処理は危険だ!

          親コメント
          • by Anonymous Coward

            ある日、僕は、ぬるぽを見つけたよ~♪
            だけど、それを、左へ受け流す~♪

          • by Anonymous Coward
            ぬるぽが右から来て~る~
            僕はそれを左へ受け流す~♪

            #ネタが賞味期限切れなのでAC
          • by Anonymous Coward

            ぬるぽ対策としては、「初期値を定義しちゃう」ってほうが多くないでしょうかね。
            try~catchで握りつぶすなという場合、他の例外に比べれば影響が微弱な事が多い。
            ぬるぽを例にする妥当性は、「危険性」というよりは「頻出性」に近くなってしまう。

  • by Anonymous Coward on 2009年01月15日 3時57分 (#1491425)

    何年か前、某サイト作成支援サービス系サイトのトップページにアクセスしたら
    db_error Object (
    ・・・・
      [nativecode=Unable to connect to PostgreSQL server: could not connect to server: Connection timed out (0x0000274C/10060)
    Is the server running on host "192.168.0.5" and accepting
    TCP/IP connections on port 5432?] ** pgsql://******:*******@tcp(192.168.0.5:5432)/ss_db
    )

    なるエラーが表示されてぶったまげたことがあります。(*は伏せてます)
    そっこー運営している会社にメールしましたが、半日近く管理者用DBユーザーとパスワードが垂れ流しのまま運営されていました。

    DB系はエラー吐くときパスワードを含んだDSNをまるごと表示しちゃうことがあるので怖いです。
    しかもDBサーバーが正常に動いている限りは、そんな空恐ろしいエラー表示が出ることに気づくことがないわけで、実運用してからある日突然こんな事態になるって意味で二重に怖いのです。

    • by Anonymous Coward on 2009年01月15日 7時24分 (#1491440)

      というか根本的に、エラーをブラウザに出す(という設定)は「世の中なめてる」よね。

      たとえばCGIなら標準「出力」はお客様へ、そして標準「エラー出力」はバックヤードへ、それぞれ情報を出すものだし、アプリのほうもそう作るべきだし、Frameworkでも同様だし。

      JavaServletとかでも発想は同じで、Web出力に繋がるOutオブジェクトは「お客様向け」のOut。

      うーん、よく知らないがRailsみたいな発想だと、
      「Developモードのときは簡便性のためにエラーもOutに出すが、
      運用モードだとバックにのみ出す」ような設定をFWレベルで持っている、のかな?
      #でもDevelopモードで運用したくなる悪魔の瞬間も存在するから、結局あぶないけどね。

      >DB系

      DBドライバが勝手にstdoutに出すっていう極道設計も現実に有り得るんだろうなあ。

      ※このばあい「極道楽」という原義に近い。おまえら遊びすぎ。

      対策としては、
      アプリとWebFWの層まではいいけど、
      それより下位(たとえばDBドライバ)を呼び出すときは、
      OutオブジェクトとかFileDescriptorとかを一時的にすりかえておく、
      という一手間がFW側に必要になるといったところか?

      #JSPの静的っぷりにうんざりしてるのでAC。まともな言語系ならば変数評価は遅延がデフォでしょうに。おまえはWindowsバッチファイルかと小一時間…orz

      親コメント
  • by Anonymous Coward on 2009年01月14日 17時07分 (#1491056)
    いまは情報処理推進機構になったんじゃないの。)どっちも0IPA2004年1月より前に協力したということ?
  • IPA (スコア:0, フレームのもと)

    by mikeneko007 (37541) on 2009年01月14日 19時01分 (#1491145)

    IPAの協力が危ない

    • by Anonymous Coward
      エラーを起こしたことのない人にはエラーのチェックは向きません。
      エラーを検証するのも経験がモノを言います。

      # 深読み禁止!
  • by Anonymous Coward on 2009年01月14日 19時57分 (#1491187)
    http://cwe.mitre.org/top25/#CWE-20
    一位は、input validation ですか。
    アメリカは遅れていますね(笑)。
    そりゃなんでも input validation のせいにしてりゃトップにもなりますわな。
    • by Anonymous Coward

      - 入力の検証忘れ(数値か文字列かのチェックなど)
      - SQLインジェクション
      - クロスサイトスクリプティング
      - OSコマンドインジェクション
      - コードインジェクション
      - 不正確な算術(整数掛け算のオーバフロー、浮動小数点演算の丸め誤差など)

      これ全部input validationぢゃないの?
      項目分ける意味がわからんちゃ

      • by Anonymous Coward

        - 入力の検証忘れ(数値か文字列かのチェックなど)
        - SQLインジェクション
        - クロスサイトスクリプティング
        - OSコマンドインジェクション
        - コードインジェクション
        - 不正確な算術(整数掛け算のオーバフロー、浮動小数点演算の丸め誤差など)

        これ全部input validationぢゃないの?
        項目分ける意味がわからんちゃ

        インジェクション系は原因となるデータがユーザーの入力から直接来るとは限らないでしょ。
        一度DBに入ってからというパターンもある訳だし。
        DBから取り出した値をいちいち入力チェックするというのは普通しないので別扱いでOK。
        とはいえインジェクション系は全部まとめてもいいかも。

  • by Anonymous Coward on 2009年01月15日 6時55分 (#1491437)
    昔はこういう話題だと if (i=0) とかが出ていたものだが、最近はいろいろ難しいなあ。
    • by Anonymous Coward
      同様ので、こんなんもありますね。
      ######################
      unsigned char i ;
      ・・・
      if (i < 0)
      ######################
      社内コーディング規約で、unsigned 変数には「un」とか「uc」を付けろと決まっていたっけ。
      組み込みだと、「int」は使うなと言われたりね。
  • by Anonymous Coward on 2009年01月15日 17時12分 (#1491816)
    5 NEW

    なんてのが勝手に追記されていたり。
typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...