セキュリティを克服するコーダー:共有と学習-SQL インジェクション
簡単に言うと、SQL (または構造化照会言語) はリレーショナルデータベースとの通信に使用される言語であり、開発者、データベース管理者、およびアプリケーションがリレーショナルデータベースを管理するために使用するクエリ言語です 毎日大量のデータが生成されています。
私たちのデータは急速に世界で最も価値のある商品の1つになりつつあります。そして、何か価値のあるものがあると、悪者は自分たちの利益のためにそれを手に入れたいと思うでしょう。
攻撃者はSQLインジェクションを使用しています。これは最も古いものの1つです（1998 年以降!)そして、世の中で最も厄介なデータ脆弱性は、世界中の何百万ものデータベースにある機密情報を盗んだり変更したりすることです。これは陰湿なものであり、データを安全に保つためには、開発者は SQL インジェクション (およびその防御方法) を理解する必要があります。
そのために、SQL インジェクションの 3 つの重要な側面について説明します。
- 仕組み
- なぜそんなに危険なのか
- それに対する防御方法
SQL インジェクションを理解する
SQL インジェクションは、「コンテキスト」という単語だけで理解できます。
アプリケーション内には 2 つのコンテキストがあります。1 つはデータ用、もう 1 つはコード用です。コードコンテキストは、何を実行すべきかをコンピューターに伝え、それを処理対象のデータから分離します。
SQL インジェクションは、攻撃者が SQL インタープリターによって誤ってコードとして扱われるデータを入力した場合に発生します。
その一例が、Web サイトの入力フィールドです。攻撃者が '」OR 1=1"を入力すると、SQL クエリの末尾に追加されます。このクエリを実行すると、データベースのすべての行に「true」が返されます。つまり、クエリされたテーブルのすべてのレコードが返されるということです。
SQL インジェクションの影響は壊滅的なものになる可能性があります。これがログインページで発生すると、ユーザー名とパスワードを含むすべてのユーザーレコードが返される可能性があります。データを取り出す単純なクエリが成功すると、データを変更するクエリも成功します。
SQL インジェクションの脆弱性が実際にどのようなものかを確認できるように、脆弱なコードをいくつか見てみましょう。
このコードをチェックしてください：
文字列クエリ =「ユーザーデータからアカウント残高を選択 (user_name =)」
+ request.getパラメータ (「顧客名」);
試してみてください {
ステートメントステートメント = 接続. CreateStatement (...);
結果セット結果 = ステートメント。クエリの実行 (クエリ);
}
このコードは、クライアントからのパラメーター情報を SQL クエリの最後に追加するだけで、検証は行われません。この場合、攻撃者が入力フィールドや URL パラメーターにコードを入力すると、そのコードが実行されます。
重要なのは、攻撃者が各 SELECT クエリに '」OR 1=1"しか追加できないということではなく、攻撃者はあらゆる種類の SQL クエリ (INSERT、UPDATE、DELETE、DROP など) を操作して、データベースがサポートしているものなら何でも拡張できるということです。素晴らしいものがあるのです。 リソース そして、何が可能かを示すツールがパブリックドメインで入手可能です。
この問題を修正する方法については、近日中に説明します。まず、どれだけのダメージを与えることができるかを理解しましょう。
SQL インジェクションが危険な理由
SQL インジェクションによる侵害の例を 3 つだけご紹介します。
- イリノイ州選挙管理委員会のウェブサイト 破られた SQL インジェクションの脆弱性が原因です。攻撃者は20万人の米国市民の個人データを盗みました。見つかった脆弱性の性質上、攻撃者はデータを変更した可能性はありましたが、実際には変更していませんでした。
- 南アフリカのウェブサイトホスティング会社であるHetznerは、 破られた 4万件の顧客記録に達しましたSQL インジェクションの脆弱性により、データベース内のすべての顧客レコードが盗まれる可能性がありました。
- 米国ミネソタ州のカトリック系金融サービスプロバイダーは、 破られた SQL インジェクションを使用する。約13万人の顧客の口座番号を含む口座情報が盗まれました。
機密データは、アカウントの乗っ取り、パスワードのリセット、金銭の盗難、または詐欺に使用される可能性があります。
機密情報や個人を特定できない情報でも、他の攻撃に使用される可能性があります。住所情報または政府発行の識別番号の下4桁は、企業になりすましたり、パスワードをリセットしたりするために使用される可能性があります。
攻撃が成功すると、顧客は会社への信頼を失う可能性があります。システムへの損害や規制違反による罰金からの回復には、数百万ドルの費用がかかる可能性があります。
しかし、そんなふうに終わらせる必要はありません。
SQL インジェクションを倒す
SQL インジェクションは、アプリケーションの一部に明確にラベルを付けることで阻止できます。これにより、コンピューターは特定の部分が実行すべきデータなのかコードなのかを知ることができます。これは、パラメータ化されたクエリを使用して行うことができます。
SQL クエリがパラメーターを使用する場合、SQL インタープリターはパラメーターをデータとしてのみ使用します。コードとしては実行されません。
たとえば、'」OR 1=1"のような攻撃は機能しません。データベースは「OR 1=1" という文字列を検索しますが、データベースには見つかりません。ただ肩をすくめて、「ごめんなさい、これが見つかりません」と言うだけです。
Java のパラメータ化されたクエリの例は次のようになります。
ほとんどの開発フレームワークには、SQL インジェクションに対する防御機能が組み込まれています。
オブジェクト・リレーショナル・マッパー (ORM)、など エンティティフレームワーク .NET ファミリでは、デフォルトでクエリをパラメータ化します。これにより、SQL インジェクションの処理はユーザー側で行う必要がありません。
ただし、特定のORMがどのように機能するかを知っておく必要があります。例えば、 休止状態、Javaの世界で人気のあるORMで、 まだ傷つきやすい 誤って使用するとSQLインジェクションに移行します。
クエリをパラメータ化することが最初の、そして最善の防御策ですが、他にもあります。ストアド・プロシージャは SQL パラメータもサポートしており、SQL インジェクションの防止にも使用できます。ストアドプロシージャは次の点に注意してください。 また、正しく構築する必要があります これがうまくいくように。
//これも検証すべきだ
文字列カスタム名 = request.getParameter (「顧客名」);
//入力検証を行って攻撃を検知
文字列クエリ =「ユーザーデータからアカウント残高を選択。ここで、ユーザー名=?「;
プリペアドステートメント pstmt = 接続。プリペアドステートメント (クエリ);
pstmt.SetString (1, カスタム名);
結果セット結果 = pstmt.ExecuteQuery ();
入力内容は常に検証してサニタイズしてください。「OR 1=1」などの一部の文字は、アプリケーションの正規ユーザーには入力されないため、許可する必要はありません。処理する前に、エラーメッセージをユーザーに表示したり、入力から取り除いたりできます。
とはいえ、身を守るために検証とサニタイズだけに頼らないでください。賢い人間はそれを回避する方法を見つけました。これらは優れた多層防御 (DiD) 戦略ですが、パラメーター化はすべての基地をカバーする確実な方法です。
もう1つの優れたDiD戦略は、データベース内で「最小権限」を使用し、入力をホワイトリストに登録することです。最小権限を適用するということは、アプリケーションがデータベース内で無限の能力を発揮できないということです。攻撃者がアクセス権を握ったとしても、攻撃者が与える被害は限定的です。
OWASPには素晴らしいものがあります SQL インジェクションチートシート この脆弱性を複数の言語やプラットフォームで処理する方法を紹介しています。ただし、さらに改善したい場合は、今すぐ当社のプラットフォームでお好みの言語で SQL インジェクションチャレンジをプレイできます。その中でも人気の高いチャレンジをいくつかご紹介します。
旅の始まり
SQL インジェクションとその修正に必要な手順を理解するうえで、大きな進歩を遂げました。素晴らしい！
ここまで、SQL インジェクションがどのように行われるのかについて説明してきました。一般的には、攻撃者が入力を使用してデータベースクエリを不正な目的で制御する場合です。
また、SQL インジェクションの脆弱性の悪用による被害も見てきました。アカウントが侵害され、数百万ドルの損失が発生する可能性があります。これは悪夢であり、コストもかかります。
SQL インジェクションを防ぐ方法を見てきました。
- クエリのパラメータ化
- オブジェクトリレーショナルマッパーとストアドプロシージャの使用
- ユーザー入力の検証とホワイトリスト登録
今、それはあなた次第です。学び続け、習熟を深めるには練習が一番です。ぜひチェックしてみてはいかがでしょうか。 学習リソース SQLインジェクションについては、次のことを試してください 無料デモ プラットフォームの？セキュア・コード・ウォリアーへの道は順調に進むでしょう。
攻撃者はSQLインジェクションを使用しています。SQLインジェクションは最も古いものの1つです（1998年以降！）そして、最も厄介なデータ脆弱性は、世界中の何百万ものデータベースにある機密情報を盗み、改ざんすることです。
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
簡単に言うと、SQL (または構造化照会言語) はリレーショナルデータベースとの通信に使用される言語であり、開発者、データベース管理者、およびアプリケーションがリレーショナルデータベースを管理するために使用するクエリ言語です 毎日大量のデータが生成されています。
私たちのデータは急速に世界で最も価値のある商品の1つになりつつあります。そして、何か価値のあるものがあると、悪者は自分たちの利益のためにそれを手に入れたいと思うでしょう。
攻撃者はSQLインジェクションを使用しています。これは最も古いものの1つです（1998 年以降!)そして、世の中で最も厄介なデータ脆弱性は、世界中の何百万ものデータベースにある機密情報を盗んだり変更したりすることです。これは陰湿なものであり、データを安全に保つためには、開発者は SQL インジェクション (およびその防御方法) を理解する必要があります。
そのために、SQL インジェクションの 3 つの重要な側面について説明します。
- 仕組み
- なぜそんなに危険なのか
- それに対する防御方法
SQL インジェクションを理解する
SQL インジェクションは、「コンテキスト」という単語だけで理解できます。
アプリケーション内には 2 つのコンテキストがあります。1 つはデータ用、もう 1 つはコード用です。コードコンテキストは、何を実行すべきかをコンピューターに伝え、それを処理対象のデータから分離します。
SQL インジェクションは、攻撃者が SQL インタープリターによって誤ってコードとして扱われるデータを入力した場合に発生します。
その一例が、Web サイトの入力フィールドです。攻撃者が '」OR 1=1"を入力すると、SQL クエリの末尾に追加されます。このクエリを実行すると、データベースのすべての行に「true」が返されます。つまり、クエリされたテーブルのすべてのレコードが返されるということです。
SQL インジェクションの影響は壊滅的なものになる可能性があります。これがログインページで発生すると、ユーザー名とパスワードを含むすべてのユーザーレコードが返される可能性があります。データを取り出す単純なクエリが成功すると、データを変更するクエリも成功します。
SQL インジェクションの脆弱性が実際にどのようなものかを確認できるように、脆弱なコードをいくつか見てみましょう。
このコードをチェックしてください：
文字列クエリ =「ユーザーデータからアカウント残高を選択 (user_name =)」
+ request.getパラメータ (「顧客名」);
試してみてください {
ステートメントステートメント = 接続. CreateStatement (...);
結果セット結果 = ステートメント。クエリの実行 (クエリ);
}
このコードは、クライアントからのパラメーター情報を SQL クエリの最後に追加するだけで、検証は行われません。この場合、攻撃者が入力フィールドや URL パラメーターにコードを入力すると、そのコードが実行されます。
重要なのは、攻撃者が各 SELECT クエリに '」OR 1=1"しか追加できないということではなく、攻撃者はあらゆる種類の SQL クエリ (INSERT、UPDATE、DELETE、DROP など) を操作して、データベースがサポートしているものなら何でも拡張できるということです。素晴らしいものがあるのです。 リソース そして、何が可能かを示すツールがパブリックドメインで入手可能です。
この問題を修正する方法については、近日中に説明します。まず、どれだけのダメージを与えることができるかを理解しましょう。
SQL インジェクションが危険な理由
SQL インジェクションによる侵害の例を 3 つだけご紹介します。
- イリノイ州選挙管理委員会のウェブサイト 破られた SQL インジェクションの脆弱性が原因です。攻撃者は20万人の米国市民の個人データを盗みました。見つかった脆弱性の性質上、攻撃者はデータを変更した可能性はありましたが、実際には変更していませんでした。
- 南アフリカのウェブサイトホスティング会社であるHetznerは、 破られた 4万件の顧客記録に達しましたSQL インジェクションの脆弱性により、データベース内のすべての顧客レコードが盗まれる可能性がありました。
- 米国ミネソタ州のカトリック系金融サービスプロバイダーは、 破られた SQL インジェクションを使用する。約13万人の顧客の口座番号を含む口座情報が盗まれました。
機密データは、アカウントの乗っ取り、パスワードのリセット、金銭の盗難、または詐欺に使用される可能性があります。
機密情報や個人を特定できない情報でも、他の攻撃に使用される可能性があります。住所情報または政府発行の識別番号の下4桁は、企業になりすましたり、パスワードをリセットしたりするために使用される可能性があります。
攻撃が成功すると、顧客は会社への信頼を失う可能性があります。システムへの損害や規制違反による罰金からの回復には、数百万ドルの費用がかかる可能性があります。
しかし、そんなふうに終わらせる必要はありません。
SQL インジェクションを倒す
SQL インジェクションは、アプリケーションの一部に明確にラベルを付けることで阻止できます。これにより、コンピューターは特定の部分が実行すべきデータなのかコードなのかを知ることができます。これは、パラメータ化されたクエリを使用して行うことができます。
SQL クエリがパラメーターを使用する場合、SQL インタープリターはパラメーターをデータとしてのみ使用します。コードとしては実行されません。
たとえば、'」OR 1=1"のような攻撃は機能しません。データベースは「OR 1=1" という文字列を検索しますが、データベースには見つかりません。ただ肩をすくめて、「ごめんなさい、これが見つかりません」と言うだけです。
Java のパラメータ化されたクエリの例は次のようになります。
ほとんどの開発フレームワークには、SQL インジェクションに対する防御機能が組み込まれています。
オブジェクト・リレーショナル・マッパー (ORM)、など エンティティフレームワーク .NET ファミリでは、デフォルトでクエリをパラメータ化します。これにより、SQL インジェクションの処理はユーザー側で行う必要がありません。
ただし、特定のORMがどのように機能するかを知っておく必要があります。例えば、 休止状態、Javaの世界で人気のあるORMで、 まだ傷つきやすい 誤って使用するとSQLインジェクションに移行します。
クエリをパラメータ化することが最初の、そして最善の防御策ですが、他にもあります。ストアド・プロシージャは SQL パラメータもサポートしており、SQL インジェクションの防止にも使用できます。ストアドプロシージャは次の点に注意してください。 また、正しく構築する必要があります これがうまくいくように。
//これも検証すべきだ
文字列カスタム名 = request.getParameter (「顧客名」);
//入力検証を行って攻撃を検知
文字列クエリ =「ユーザーデータからアカウント残高を選択。ここで、ユーザー名=?「;
プリペアドステートメント pstmt = 接続。プリペアドステートメント (クエリ);
pstmt.SetString (1, カスタム名);
結果セット結果 = pstmt.ExecuteQuery ();
入力内容は常に検証してサニタイズしてください。「OR 1=1」などの一部の文字は、アプリケーションの正規ユーザーには入力されないため、許可する必要はありません。処理する前に、エラーメッセージをユーザーに表示したり、入力から取り除いたりできます。
とはいえ、身を守るために検証とサニタイズだけに頼らないでください。賢い人間はそれを回避する方法を見つけました。これらは優れた多層防御 (DiD) 戦略ですが、パラメーター化はすべての基地をカバーする確実な方法です。
もう1つの優れたDiD戦略は、データベース内で「最小権限」を使用し、入力をホワイトリストに登録することです。最小権限を適用するということは、アプリケーションがデータベース内で無限の能力を発揮できないということです。攻撃者がアクセス権を握ったとしても、攻撃者が与える被害は限定的です。
OWASPには素晴らしいものがあります SQL インジェクションチートシート この脆弱性を複数の言語やプラットフォームで処理する方法を紹介しています。ただし、さらに改善したい場合は、今すぐ当社のプラットフォームでお好みの言語で SQL インジェクションチャレンジをプレイできます。その中でも人気の高いチャレンジをいくつかご紹介します。
旅の始まり
SQL インジェクションとその修正に必要な手順を理解するうえで、大きな進歩を遂げました。素晴らしい！
ここまで、SQL インジェクションがどのように行われるのかについて説明してきました。一般的には、攻撃者が入力を使用してデータベースクエリを不正な目的で制御する場合です。
また、SQL インジェクションの脆弱性の悪用による被害も見てきました。アカウントが侵害され、数百万ドルの損失が発生する可能性があります。これは悪夢であり、コストもかかります。
SQL インジェクションを防ぐ方法を見てきました。
- クエリのパラメータ化
- オブジェクトリレーショナルマッパーとストアドプロシージャの使用
- ユーザー入力の検証とホワイトリスト登録
今、それはあなた次第です。学び続け、習熟を深めるには練習が一番です。ぜひチェックしてみてはいかがでしょうか。 学習リソース SQLインジェクションについては、次のことを試してください 無料デモ プラットフォームの？セキュア・コード・ウォリアーへの道は順調に進むでしょう。
簡単に言うと、SQL (または構造化照会言語) はリレーショナルデータベースとの通信に使用される言語であり、開発者、データベース管理者、およびアプリケーションがリレーショナルデータベースを管理するために使用するクエリ言語です 毎日大量のデータが生成されています。
私たちのデータは急速に世界で最も価値のある商品の1つになりつつあります。そして、何か価値のあるものがあると、悪者は自分たちの利益のためにそれを手に入れたいと思うでしょう。
攻撃者はSQLインジェクションを使用しています。これは最も古いものの1つです（1998 年以降!)そして、世の中で最も厄介なデータ脆弱性は、世界中の何百万ものデータベースにある機密情報を盗んだり変更したりすることです。これは陰湿なものであり、データを安全に保つためには、開発者は SQL インジェクション (およびその防御方法) を理解する必要があります。
そのために、SQL インジェクションの 3 つの重要な側面について説明します。
- 仕組み
- なぜそんなに危険なのか
- それに対する防御方法
SQL インジェクションを理解する
SQL インジェクションは、「コンテキスト」という単語だけで理解できます。
アプリケーション内には 2 つのコンテキストがあります。1 つはデータ用、もう 1 つはコード用です。コードコンテキストは、何を実行すべきかをコンピューターに伝え、それを処理対象のデータから分離します。
SQL インジェクションは、攻撃者が SQL インタープリターによって誤ってコードとして扱われるデータを入力した場合に発生します。
その一例が、Web サイトの入力フィールドです。攻撃者が '」OR 1=1"を入力すると、SQL クエリの末尾に追加されます。このクエリを実行すると、データベースのすべての行に「true」が返されます。つまり、クエリされたテーブルのすべてのレコードが返されるということです。
SQL インジェクションの影響は壊滅的なものになる可能性があります。これがログインページで発生すると、ユーザー名とパスワードを含むすべてのユーザーレコードが返される可能性があります。データを取り出す単純なクエリが成功すると、データを変更するクエリも成功します。
SQL インジェクションの脆弱性が実際にどのようなものかを確認できるように、脆弱なコードをいくつか見てみましょう。
このコードをチェックしてください：
文字列クエリ =「ユーザーデータからアカウント残高を選択 (user_name =)」
+ request.getパラメータ (「顧客名」);
試してみてください {
ステートメントステートメント = 接続. CreateStatement (...);
結果セット結果 = ステートメント。クエリの実行 (クエリ);
}
このコードは、クライアントからのパラメーター情報を SQL クエリの最後に追加するだけで、検証は行われません。この場合、攻撃者が入力フィールドや URL パラメーターにコードを入力すると、そのコードが実行されます。
重要なのは、攻撃者が各 SELECT クエリに '」OR 1=1"しか追加できないということではなく、攻撃者はあらゆる種類の SQL クエリ (INSERT、UPDATE、DELETE、DROP など) を操作して、データベースがサポートしているものなら何でも拡張できるということです。素晴らしいものがあるのです。 リソース そして、何が可能かを示すツールがパブリックドメインで入手可能です。
この問題を修正する方法については、近日中に説明します。まず、どれだけのダメージを与えることができるかを理解しましょう。
SQL インジェクションが危険な理由
SQL インジェクションによる侵害の例を 3 つだけご紹介します。
- イリノイ州選挙管理委員会のウェブサイト 破られた SQL インジェクションの脆弱性が原因です。攻撃者は20万人の米国市民の個人データを盗みました。見つかった脆弱性の性質上、攻撃者はデータを変更した可能性はありましたが、実際には変更していませんでした。
- 南アフリカのウェブサイトホスティング会社であるHetznerは、 破られた 4万件の顧客記録に達しましたSQL インジェクションの脆弱性により、データベース内のすべての顧客レコードが盗まれる可能性がありました。
- 米国ミネソタ州のカトリック系金融サービスプロバイダーは、 破られた SQL インジェクションを使用する。約13万人の顧客の口座番号を含む口座情報が盗まれました。
機密データは、アカウントの乗っ取り、パスワードのリセット、金銭の盗難、または詐欺に使用される可能性があります。
機密情報や個人を特定できない情報でも、他の攻撃に使用される可能性があります。住所情報または政府発行の識別番号の下4桁は、企業になりすましたり、パスワードをリセットしたりするために使用される可能性があります。
攻撃が成功すると、顧客は会社への信頼を失う可能性があります。システムへの損害や規制違反による罰金からの回復には、数百万ドルの費用がかかる可能性があります。
しかし、そんなふうに終わらせる必要はありません。
SQL インジェクションを倒す
SQL インジェクションは、アプリケーションの一部に明確にラベルを付けることで阻止できます。これにより、コンピューターは特定の部分が実行すべきデータなのかコードなのかを知ることができます。これは、パラメータ化されたクエリを使用して行うことができます。
SQL クエリがパラメーターを使用する場合、SQL インタープリターはパラメーターをデータとしてのみ使用します。コードとしては実行されません。
たとえば、'」OR 1=1"のような攻撃は機能しません。データベースは「OR 1=1" という文字列を検索しますが、データベースには見つかりません。ただ肩をすくめて、「ごめんなさい、これが見つかりません」と言うだけです。
Java のパラメータ化されたクエリの例は次のようになります。
ほとんどの開発フレームワークには、SQL インジェクションに対する防御機能が組み込まれています。
オブジェクト・リレーショナル・マッパー (ORM)、など エンティティフレームワーク .NET ファミリでは、デフォルトでクエリをパラメータ化します。これにより、SQL インジェクションの処理はユーザー側で行う必要がありません。
ただし、特定のORMがどのように機能するかを知っておく必要があります。例えば、 休止状態、Javaの世界で人気のあるORMで、 まだ傷つきやすい 誤って使用するとSQLインジェクションに移行します。
クエリをパラメータ化することが最初の、そして最善の防御策ですが、他にもあります。ストアド・プロシージャは SQL パラメータもサポートしており、SQL インジェクションの防止にも使用できます。ストアドプロシージャは次の点に注意してください。 また、正しく構築する必要があります これがうまくいくように。
//これも検証すべきだ
文字列カスタム名 = request.getParameter (「顧客名」);
//入力検証を行って攻撃を検知
文字列クエリ =「ユーザーデータからアカウント残高を選択。ここで、ユーザー名=?「;
プリペアドステートメント pstmt = 接続。プリペアドステートメント (クエリ);
pstmt.SetString (1, カスタム名);
結果セット結果 = pstmt.ExecuteQuery ();
入力内容は常に検証してサニタイズしてください。「OR 1=1」などの一部の文字は、アプリケーションの正規ユーザーには入力されないため、許可する必要はありません。処理する前に、エラーメッセージをユーザーに表示したり、入力から取り除いたりできます。
とはいえ、身を守るために検証とサニタイズだけに頼らないでください。賢い人間はそれを回避する方法を見つけました。これらは優れた多層防御 (DiD) 戦略ですが、パラメーター化はすべての基地をカバーする確実な方法です。
もう1つの優れたDiD戦略は、データベース内で「最小権限」を使用し、入力をホワイトリストに登録することです。最小権限を適用するということは、アプリケーションがデータベース内で無限の能力を発揮できないということです。攻撃者がアクセス権を握ったとしても、攻撃者が与える被害は限定的です。
OWASPには素晴らしいものがあります SQL インジェクションチートシート この脆弱性を複数の言語やプラットフォームで処理する方法を紹介しています。ただし、さらに改善したい場合は、今すぐ当社のプラットフォームでお好みの言語で SQL インジェクションチャレンジをプレイできます。その中でも人気の高いチャレンジをいくつかご紹介します。
旅の始まり
SQL インジェクションとその修正に必要な手順を理解するうえで、大きな進歩を遂げました。素晴らしい！
ここまで、SQL インジェクションがどのように行われるのかについて説明してきました。一般的には、攻撃者が入力を使用してデータベースクエリを不正な目的で制御する場合です。
また、SQL インジェクションの脆弱性の悪用による被害も見てきました。アカウントが侵害され、数百万ドルの損失が発生する可能性があります。これは悪夢であり、コストもかかります。
SQL インジェクションを防ぐ方法を見てきました。
- クエリのパラメータ化
- オブジェクトリレーショナルマッパーとストアドプロシージャの使用
- ユーザー入力の検証とホワイトリスト登録
今、それはあなた次第です。学び続け、習熟を深めるには練習が一番です。ぜひチェックしてみてはいかがでしょうか。 学習リソース SQLインジェクションについては、次のことを試してください 無料デモ プラットフォームの？セキュア・コード・ウォリアーへの道は順調に進むでしょう。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
簡単に言うと、SQL (または構造化照会言語) はリレーショナルデータベースとの通信に使用される言語であり、開発者、データベース管理者、およびアプリケーションがリレーショナルデータベースを管理するために使用するクエリ言語です 毎日大量のデータが生成されています。
私たちのデータは急速に世界で最も価値のある商品の1つになりつつあります。そして、何か価値のあるものがあると、悪者は自分たちの利益のためにそれを手に入れたいと思うでしょう。
攻撃者はSQLインジェクションを使用しています。これは最も古いものの1つです（1998 年以降!)そして、世の中で最も厄介なデータ脆弱性は、世界中の何百万ものデータベースにある機密情報を盗んだり変更したりすることです。これは陰湿なものであり、データを安全に保つためには、開発者は SQL インジェクション (およびその防御方法) を理解する必要があります。
そのために、SQL インジェクションの 3 つの重要な側面について説明します。
- 仕組み
- なぜそんなに危険なのか
- それに対する防御方法
SQL インジェクションを理解する
SQL インジェクションは、「コンテキスト」という単語だけで理解できます。
アプリケーション内には 2 つのコンテキストがあります。1 つはデータ用、もう 1 つはコード用です。コードコンテキストは、何を実行すべきかをコンピューターに伝え、それを処理対象のデータから分離します。
SQL インジェクションは、攻撃者が SQL インタープリターによって誤ってコードとして扱われるデータを入力した場合に発生します。
その一例が、Web サイトの入力フィールドです。攻撃者が '」OR 1=1"を入力すると、SQL クエリの末尾に追加されます。このクエリを実行すると、データベースのすべての行に「true」が返されます。つまり、クエリされたテーブルのすべてのレコードが返されるということです。
SQL インジェクションの影響は壊滅的なものになる可能性があります。これがログインページで発生すると、ユーザー名とパスワードを含むすべてのユーザーレコードが返される可能性があります。データを取り出す単純なクエリが成功すると、データを変更するクエリも成功します。
SQL インジェクションの脆弱性が実際にどのようなものかを確認できるように、脆弱なコードをいくつか見てみましょう。
このコードをチェックしてください：
文字列クエリ =「ユーザーデータからアカウント残高を選択 (user_name =)」
+ request.getパラメータ (「顧客名」);
試してみてください {
ステートメントステートメント = 接続. CreateStatement (...);
結果セット結果 = ステートメント。クエリの実行 (クエリ);
}
このコードは、クライアントからのパラメーター情報を SQL クエリの最後に追加するだけで、検証は行われません。この場合、攻撃者が入力フィールドや URL パラメーターにコードを入力すると、そのコードが実行されます。
重要なのは、攻撃者が各 SELECT クエリに '」OR 1=1"しか追加できないということではなく、攻撃者はあらゆる種類の SQL クエリ (INSERT、UPDATE、DELETE、DROP など) を操作して、データベースがサポートしているものなら何でも拡張できるということです。素晴らしいものがあるのです。 リソース そして、何が可能かを示すツールがパブリックドメインで入手可能です。
この問題を修正する方法については、近日中に説明します。まず、どれだけのダメージを与えることができるかを理解しましょう。
SQL インジェクションが危険な理由
SQL インジェクションによる侵害の例を 3 つだけご紹介します。
- イリノイ州選挙管理委員会のウェブサイト 破られた SQL インジェクションの脆弱性が原因です。攻撃者は20万人の米国市民の個人データを盗みました。見つかった脆弱性の性質上、攻撃者はデータを変更した可能性はありましたが、実際には変更していませんでした。
- 南アフリカのウェブサイトホスティング会社であるHetznerは、 破られた 4万件の顧客記録に達しましたSQL インジェクションの脆弱性により、データベース内のすべての顧客レコードが盗まれる可能性がありました。
- 米国ミネソタ州のカトリック系金融サービスプロバイダーは、 破られた SQL インジェクションを使用する。約13万人の顧客の口座番号を含む口座情報が盗まれました。
機密データは、アカウントの乗っ取り、パスワードのリセット、金銭の盗難、または詐欺に使用される可能性があります。
機密情報や個人を特定できない情報でも、他の攻撃に使用される可能性があります。住所情報または政府発行の識別番号の下4桁は、企業になりすましたり、パスワードをリセットしたりするために使用される可能性があります。
攻撃が成功すると、顧客は会社への信頼を失う可能性があります。システムへの損害や規制違反による罰金からの回復には、数百万ドルの費用がかかる可能性があります。
しかし、そんなふうに終わらせる必要はありません。
SQL インジェクションを倒す
SQL インジェクションは、アプリケーションの一部に明確にラベルを付けることで阻止できます。これにより、コンピューターは特定の部分が実行すべきデータなのかコードなのかを知ることができます。これは、パラメータ化されたクエリを使用して行うことができます。
SQL クエリがパラメーターを使用する場合、SQL インタープリターはパラメーターをデータとしてのみ使用します。コードとしては実行されません。
たとえば、'」OR 1=1"のような攻撃は機能しません。データベースは「OR 1=1" という文字列を検索しますが、データベースには見つかりません。ただ肩をすくめて、「ごめんなさい、これが見つかりません」と言うだけです。
Java のパラメータ化されたクエリの例は次のようになります。
ほとんどの開発フレームワークには、SQL インジェクションに対する防御機能が組み込まれています。
オブジェクト・リレーショナル・マッパー (ORM)、など エンティティフレームワーク .NET ファミリでは、デフォルトでクエリをパラメータ化します。これにより、SQL インジェクションの処理はユーザー側で行う必要がありません。
ただし、特定のORMがどのように機能するかを知っておく必要があります。例えば、 休止状態、Javaの世界で人気のあるORMで、 まだ傷つきやすい 誤って使用するとSQLインジェクションに移行します。
クエリをパラメータ化することが最初の、そして最善の防御策ですが、他にもあります。ストアド・プロシージャは SQL パラメータもサポートしており、SQL インジェクションの防止にも使用できます。ストアドプロシージャは次の点に注意してください。 また、正しく構築する必要があります これがうまくいくように。
//これも検証すべきだ
文字列カスタム名 = request.getParameter (「顧客名」);
//入力検証を行って攻撃を検知
文字列クエリ =「ユーザーデータからアカウント残高を選択。ここで、ユーザー名=?「;
プリペアドステートメント pstmt = 接続。プリペアドステートメント (クエリ);
pstmt.SetString (1, カスタム名);
結果セット結果 = pstmt.ExecuteQuery ();
入力内容は常に検証してサニタイズしてください。「OR 1=1」などの一部の文字は、アプリケーションの正規ユーザーには入力されないため、許可する必要はありません。処理する前に、エラーメッセージをユーザーに表示したり、入力から取り除いたりできます。
とはいえ、身を守るために検証とサニタイズだけに頼らないでください。賢い人間はそれを回避する方法を見つけました。これらは優れた多層防御 (DiD) 戦略ですが、パラメーター化はすべての基地をカバーする確実な方法です。
もう1つの優れたDiD戦略は、データベース内で「最小権限」を使用し、入力をホワイトリストに登録することです。最小権限を適用するということは、アプリケーションがデータベース内で無限の能力を発揮できないということです。攻撃者がアクセス権を握ったとしても、攻撃者が与える被害は限定的です。
OWASPには素晴らしいものがあります SQL インジェクションチートシート この脆弱性を複数の言語やプラットフォームで処理する方法を紹介しています。ただし、さらに改善したい場合は、今すぐ当社のプラットフォームでお好みの言語で SQL インジェクションチャレンジをプレイできます。その中でも人気の高いチャレンジをいくつかご紹介します。
旅の始まり
SQL インジェクションとその修正に必要な手順を理解するうえで、大きな進歩を遂げました。素晴らしい！
ここまで、SQL インジェクションがどのように行われるのかについて説明してきました。一般的には、攻撃者が入力を使用してデータベースクエリを不正な目的で制御する場合です。
また、SQL インジェクションの脆弱性の悪用による被害も見てきました。アカウントが侵害され、数百万ドルの損失が発生する可能性があります。これは悪夢であり、コストもかかります。
SQL インジェクションを防ぐ方法を見てきました。
- クエリのパラメータ化
- オブジェクトリレーショナルマッパーとストアドプロシージャの使用
- ユーザー入力の検証とホワイトリスト登録
今、それはあなた次第です。学び続け、習熟を深めるには練習が一番です。ぜひチェックしてみてはいかがでしょうか。 学習リソース SQLインジェクションについては、次のことを試してください 無料デモ プラットフォームの？セキュア・コード・ウォリアーへの道は順調に進むでしょう。
始めるためのリソース
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
