SQLインジェクションを使用して、ログインデータベースからパスワードまたはパスワードハッシュを抽出するのはなぜですか（合法的にそれらを開示してはいけません）。
（さて、私は自分自身を教育しようとしている間、ウェブアプリケーションのセキュリティに関する現在の知識の状態はまだかなり浅いことを前もって告白します。私がこれを尋ねる方法が少し不器用であるなら、あなたの忍耐に感謝します。）
私が出会った数日前にいくつかのinfosecニュースに追いついていた このアイテム のWebサイトへの侵入に関連した罪で今月初めに逮捕された灰色の帽子のセキュリティ研究者/ハッカーについてフロリダの郡選挙組織。技術的な観点から、このフェローがログインデータベースに対してSQLインジェクション攻撃を使用し、郡選挙管理者の平文（！）パスワードをそこから盗んだときに妥協が生じたようです。次に、それらの資格情報を使用して、Webサイトのコンテンツ管理システムにログインしました。
これについて読んだ後、奇妙なことが私を襲った。私が本当に理解していない、またはまったく理解していない、パスワードデータベースからのこれらの超一般的なSQLインジェクション盗難の性質について、かなり基本的な点があることに気付きました。つまり、なぜログインデータベースを操作して、最初にパスワードハッシュ（および/またはユーザー名、ソルト、またはその他の認証関連情報）を開示することが可能なのでしょうか。
SQLインジェクションがデータベースに対して一般的に機能する理由を理解できます。データベースの典型的な一般的な仕事は、ユーザーのクエリに応答して、データベースに格納されているユーザーが読み取り可能な情報を返すことです。しかし、ログイン認証情報データベースの仕事は大きく異なります。実際にデータベースの外部に保存された認証情報を送信する必要はありません代わりに、ユーザーが指定した資格情報を渡すかどうかに関するWebサーバーに応答を提供するだけですそれらは有効かどうかです。 （正しい？）
では、なぜフルパワーのデータベースソフトウェアとSQLクエリを使用して、ユーザー名とパスワードの認証というかなり限定されたニーズに対処するのでしょうか。 SQLデータベースインジェクションが発生する余地を多く残した汎用アプリケーションを使用するのではなく、パスワードデータベースが実行する必要のあることだけを行うことを特に目的とした限定目的データベースアプリケーションがないのはなぜですか？何が欠けていますか？
「不要」と「最低入札者による実装」の間には大きなギャップがあります。
フルパワーのデータベースソフトウェアとSQLクエリを使用する理由
トランザクションデータ用のSQLデータベースをすでに実行している場合、適切にトレーニングされた開発スタッフとサポートスタッフを使用して2番目のテクノロジースタックを実装することは、非常にコストがかかるためです。
1つのアプリケーションスタックを正しく取得できない場合、どのようにして2つに対処しますか？
確かに、SQLインジェクションの問題は、コード（SQL）をデータ（パラメーター）から分離しないAPIから発生しますが、この分離を強制する他のデータベースシステム（およびSQL API）があります。しかし、リレーショナルデータベースと特にSQLデータベースは、他のタイプのデータベースでは利用できない膨大な機能を提供します。永続化にLDAPを使用するショッピングカートを作成するのは非常に困難です。
このシステムの開発に責任を負う人々は、ハッカーと同じように不法行為です。
Symcbeanの答えに対する別の角度。
全体の状況はかなり単純化されているようです。クエリできるものとできないものは誰が処理する必要がありますか？基盤となるDB（ユーザーストレージに特別なテーブルを使用）、Webアプリケーションサーバーのバックエンド、さらにはWAF？ LIKEステートメントを含むクエリについてはどうですか（例： 'a％'のようなPasswordHash、これがどこに向かっているかがわかります）？さらに詳しく言えば、SQLインジェクションはログイン資格情報を盗むだけではありません。抽出できるより多くの機密情報が存在する可能性があります。さらに悪いことに、DBサーバーでRCEが発生する可能性があります。などなど。
SQLインジェクションを防ぐための対策を実装するだけの方が簡単に思えます（もちろん、これにより、SQLステートメントのパラメーター化についてだけでなく、SQLインジェクションを防ぐための多層防御アプローチについても話します）。
通常、ユーザーテーブルは、実際のデータベースのコンテンツへの関係を提供します。
例user：jon_smithがこの投稿を投稿しました
Userテーブルは、ログイン資格情報を格納するための論理的な場所でもあります。問題/質問は、「なぜログイン認証情報をデータベースに保存しているのか」ではなく、「パスワードのハッシュ値を保存し、ハッシュ値を比較して認証する理由」ではありません。
簡単な答えは、専門のソフトウェア開発者と比較して、学生またはフリーランサーが選挙のためにデータベースを構築するために500ポンドを支払う悪い/怠惰な開発者と安い製品マネージャーです。
スタックにさらに技術を追加することは、これを処理するための費用効果の高い方法としては非常に効率的ではなく、一般に、データベースに認証データを保存することは問題ではありません。それはあなたがそれをどのように保存し、どのようにアクセスできるかということです。
これで、SQLインジェクションに関する他の質問に移ります。それらは簡単に防ぐことができます。そして、そうしていないほとんどのサイトは、遅延プログラミングや遅延データベース設計の結果であると思います（プレーンテキストでパスワードを保存しないでください！）。誰かを侮辱するように聞こえるという意味ではありませんが、結局のところ、データベースに到達するために使用されている言語またはメソッドと、それがどのように実装されているかによって決まります。
たとえば、PHPはmysqlコマンドを使用していたが、その後mysqliになり、この問題に対処する状況ではPDOを使用することをお勧めします。進行が発生した理由は、すべての入力がサーバーに有効な形式で提示されます。
ここで私の目を引いたもう1つのことは、データベースはユーザーが読み取れる情報を返すことを目的としているということです。これは多くの用途の1つですが、データベースの目的に限定されません。問題はデータベースではなく、それを取得する方法です。非常に正当な理由により、データベースにコマンドを送信できるようにする必要がある多くの場合があります。
SQLインジェクションは、入力に対して機能し、その入力がサーバーに情報を要求する前に検証されるかどうかを確認します。したがって、問題はデータベースではなく、データベースに情報を要求するプロセスです。もちろん、資格情報を他の形式で保存することもできますが、柔軟性に制限がある傾向があります。
また、SQLインジェクションは、考慮すべき多くの攻撃方法の1つにすぎないことにも注意してください。それは不適切に設定されたシステムに入る最も簡単な方法についてであるので、それは多くの報道を得るだけです。
では、なぜフルパワーのデータベースソフトウェアとSQLクエリを使用して、ユーザー名とパスワード認証のかなり限定されたニーズに対処するのでしょうか。 SQLデータベースインジェクションが発生する余地を多く残した汎用アプリケーションを使用するのではなく、パスワードデータベースが実行する必要があることだけを行うことを特に目的とした限定目的データベースアプリケーションがないのはなぜですか？何が欠けていますか？
不足しているのは、データベースが広範なユースケース用に設計された一般的なツールであることです。あなたが説明しているのは、非常に特定のユースケースのために設計された非常に特定のツールです。
問題は、保守とコストのいずれかです。一般的なツールを使用する方が、説明しているようなより具体的なものに依存するよりも一般に安価で簡単です。
適切に使用すれば、データベースはデータを格納し、プログラムから直接クエリするのに完全に適しています。私があなたが広範に使用して説明しているような解決策を個人的に知りません。それはそれらが存在しないという意味ではありませんが、ひどく一般的ではないことを意味します。
また、それはセキュリティ設計に帰着します。あなたが説明しているのは安全な設計です。問題のウェブサイトがセキュリティを考慮して設計されていなかった場合、あなたが説明したような安全な機能は含まれません。
重要なのは、セキュリティは（一般的に）箱から出しただけではありません。デフォルトは通常、セキュリティなしです。それが積極的に設計されていないと考えなければ、あなたはそれを得るつもりはありません。これは、セキュリティを後から考えるのではなく、最初から考える必要があるという私たちが直面する最大の問題の1つです。
データベースは認証ツールではありません。すでに認証ツールを使用している場合（Webサイトログインは、他の場所にあるコンピューターまたはアプリケーションログインと資格情報を共有します。たとえば、会社の財務アプリのWebバージョン）、Active Directory、PAMまたはRADIUS =または両方の何でも。
Webアプリのユーザーログイン用に2つ目の分離されたデータベースを、残りの詳細を保持する大規模なデータベースと一緒に実行します。さらに、認証の仲介を維持し、さらに問題を引き起こします。最終的に、そのデータベースは依然として存在し、他の多くの方法で侵害される可能性があります。 。 SQLインジェクションを許可するために間違いを犯した場合、「特別な」データベースを直接または自作の認証プロセッサを介して公開する他の間違いを犯す可能性があります。