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

Web制作者の常識、開発エンジニアの常識」記事へのコメント

  • >「SQLインジェクション」という言葉を知っている人、
    >と尋ねたところ6割程度の人しか手を挙げなかったのが

    知っていても決して手を上げないのが日本人の習性ですから:-
    • by soltiox (25610) on 2006年07月26日 17時37分 (#985202) 日記
      『「SQLインジェクション」という言葉を知っている』
      とゆう質問の意味を、
      ・辞書的な意味で、知っている
      ・骨身に染み付くぐらいに、知っている
      ・目を瞑ったまま対処できるぐらいに、知っている
      等々、どうゆうレベルに取るかによって、
      態度が変わる気がします。

      // 「お前はSQLを知っているか?」と問われて、
      // 躊躇無くyesとこたえられない気がするけどID
      親コメント
      • by GG (21918) on 2006年07月27日 2時11分 (#985480)
        日本人は、I can't speak English. って言っちゃう民族だからね。
        親コメント
        • 町中や電車で外人に英語で質問された時に、英語喋れないから I cant speak Englishとか正直に言ったのにそれでもなんか聞いてきて、しょうがないから必死になって答えてやったらやっぱり通じなかったみたいで「なに言ってるのかさっぱりわからん」みたいな顔で去っていかれたことならある。何度か。
      • by minz (3213) on 2006年07月27日 2時02分 (#985473) ホームページ 日記
        SQLインジェクションは本質的に「データベースのアクセス権限昇格の脆弱性」であることなのに,
        単にサニタイズ問題に矮小化されがちであるのは非常に気になりますねえ...

        # これに気がついている技術者が少ないことが,特に.
        --
        みんつ
        親コメント
        • 「データベースのアクセス権限昇格」でいうところの「権限」とは、なんの権限のことでしょう?

          ストレートに解釈するところの「権限」だとすると、これを「権限昇格」というのはあまり一般的でないような。
          親コメント
          • 「適正な権限でのみデータベースにアクセス」できているのなら,いくらインジェクションされても怖くないはづなんですが,(例えば共通ユーザによるアクセスにより)「実効的に昇格したアクセスが許される」ことに問題がある,との意です.
            ご指摘の通り,いわゆるセキュリティの脆弱性で良く表現される「権限昇格」とはニュアンスが違うかもしれませんね.
            --
            みんつ
            親コメント
            • >「適正な権限でのみデータベースにアクセス」できているのなら,いくらインジェクションされても怖くないはづなんですが

              これは、理論的には不可能ではないですが、現実には色々と難しいかと。

              ポイントはこのあたりです。
              • Webアプリ側のユーザアカウント(ショッピングサイトの利用者IDなど)は、DBアクセスのアカウントとは一般的には別
              • リクエスト毎に細かく権限を制御しようとすると、コネクションプーリングの有効性が薄れる

              例えば、Webアプリから参照しないはずのシステム表などへのSELECT制限やUPDATE制限をかける、ということであれば、
              リスク低減の観点からは実施すべきです。これすらやっていなくて被害を拡大している例も確かにあると思います。
              (Webアプリからdba権限でDBアクセスさせるような…)

              ただし、SQLインジェクションによる脅威は、WebアプリからSELECT/UPDATEしない表に限定されるものではありません。
              (ショッピングサイトで他の利用者の注文内容を盗み見る、など)

              適切な権限設定によってリスク低減が図れるのは間違いありませんが、本質的な解決はやはり「インジェクションさせない」
              ことになるかと思います。

              # このへんは先日の日記に書こうか迷ったけど、SQLインジェクションの本質的な解決にはならないので推敲で削除。
              親コメント
              • ええ,アカウントのマッピングと性能劣化はいつも設計上アタマの痛い問題です.
                ただ,レコード単位までアクセス制御がかかれば,ほぼ「SQLインジェクション怖くねー」となりますし,それを実現する ための仕組み (Oracle の FGAC など) も利用できないことはないです.

                ...つうか「ユーザ毎にアクセス制御しない」「生成される SQL 文を制限させることでアクセスを実現する」のが当然なのであれば,接続時のユーザ/パスワードなんて不要になっちゃいますよね...

                逆説的な説明になってしまいましたが
                「きちんとアクセス制御を行う」のがデータベースの使い方としては常道であり,性能等の問題が出た場合に「安全性とのトレードオフを熟慮した上で慎重な実装」にて行う,というのが原則だと思うのです.

                前段の論議ヌキに最後の「慎重な実装」という対策部分だけが語られがちであることが気になっています.
                --
                みんつ
                親コメント
        • SQLインジェクションは本質的に「データベースのアクセス権限昇格の脆弱性」であることなのに, 単にサニタイズ問題に矮小化されがちであるのは非常に気になりますねえ...
          ぜんぜん違いますよ。SQLインジェクションは本質的に「文字列の結合でプログラムを構成する」ところにミスが発生しやすいという問題ですよ。権限昇格は結果でしかない。
          • ミスが発生しても昇格が起きなければ「何の問題もない」んです.
            サイトの安全性を考えるならば,小手先の入口対策より根本対処にて対応すべきでしょう.
            他の方の投稿にもありますように,理想的にはそうであってもなかなか難しい,と言うのには納得しますが,だからと言って「結果でしかない」と短絡するのには違和感があります.
            --
            みんつ
            親コメント
    • by bero (5057) on 2006年07月26日 20時47分 (#985304) 日記
      >知っていても決して手を上げないのが日本人の習性ですから:

      日本人の習性としてはむしろ(場の雰囲気にもよりますが)
      - 常に上げない
      - 人数が多ければ(実際に知ってる・知らないにかかわらず)上げる
      というパターンのような

      「SQLインジェクション」という言葉を知らない人
      と尋ねるとまた別の結果がでるような
      親コメント

犯人はmoriwaka -- Anonymous Coward

処理中...