
コーダーはセキュリティを制する。共有と学習 - SQLインジェクション
簡単に言うと、SQL(Structured Query Language)とは、リレーショナルデータベースと通信するための言語で、開発者やデータベース管理者、アプリケーションが日々生成される膨大なデータを管理するために使用する問い合わせ言語のことです。
私たちのデータは急速に、世界で最も価値のある商品のひとつになりつつある......そして価値のあるものであれば、悪者は自分たちの利益のためにそれを手に入れようとするだろう。
攻撃者は、世界中の何百万ものデータベースに存在する機密情報を盗んだり変更したりするために、最も古く(1998年以降)、最も厄介なデータ脆弱性の1つであるSQLインジェクションを使用しています。データを安全に保つためには、開発者はSQLインジェクションについて理解する必要があります(また、その防御方法についても)。
そのために、SQLインジェクションの3つのポイントについて説明します。
- その仕組み
- なぜ危険なのか
- どうやって防御するか
SQLインジェクションの理解
SQLインジェクションは、「コンテキスト」という言葉で理解することができます。
アプリケーションの中には、データ用とコード用の2つのコンテキストが存在します。コードのコンテキストは、何を実行するかをコンピュータに伝え、処理されるべきデータから分離します。
SQLインジェクションは、攻撃者が入力したデータが、SQLインタープリターによって誤ってコードとして処理されることで発生します。
一例として、ウェブサイトの入力フィールドに攻撃者が「'' OR 1=1」と入力すると、それがSQLクエリの最後に付加されます。このクエリが実行されると、データベースのすべての行に対して「true」が返されます。これは、クエリを実行したテーブルのすべてのレコードが返されることを意味します。
SQLインジェクションの影響は、壊滅的なものになる可能性があります。ログインページで発生した場合、ユーザー名やパスワードを含むすべてのユーザー記録が返される可能性があります。データを取り出すための単純なクエリが成功すれば、データを変更するためのクエリも成功するでしょう。
SQLインジェクションの脆弱性がどのようなものかを実際に確認するために、脆弱なコードを見てみましょう。
このコードをチェックしてください。
String query = "SELECT account balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");
try {
Statement statement = connection.createStatement( ... );
ResultSet results = statement.executeQuery( query );
}
ここでのコードは、検証を行わずに、クライアントからのパラメータ情報を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」という文字列を検索しますが、データベース内には見つかりません。単に肩をすくめて、"Sorry, I can't find that for you. "と言うだけです。
Javaでのパラメータ化されたクエリの例は次のようになります。

ほとんどの開発フレームワークには、SQLインジェクションに対する防御機能が組み込まれています。
.NETファミリーのEntity Frameworkのようなオブジェクトリレーショナルマッパー(ORM)は、デフォルトでクエリをパラメータ化します。これにより、SQLインジェクションの対策が何もしなくてもできるようになります。
しかし、特定のORMがどのように機能するかを知っておく必要があります。例えば、Javaの世界では人気の高いORMであるHibernate も、使い方を誤るとSQLインジェクションの危険性があります。
クエリのパラメータ化は最初で最良の防御策ですが、他にもあります。ストアドプロシージャもSQLパラメータをサポートしており、SQLインジェクションを防ぐために使用することができます。ただし、ストアドプロシージャも正しく構築されていなければなりませんのでご注意ください。
// This should REALLY be validated too
String custname = request.getParameter("customerName");
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.preparedStatement( query );
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery( );
常に入力を検証し、サニタイズしてください。OR 1=1 "のような文字は、アプリケーションの正当なユーザーが入力することはないので、許可する必要はありません。ユーザーにエラーメッセージを表示したり、入力を処理する前にそれらの文字を取り除くことができます。
とはいえ、バリデーションやサニタイズだけに頼っていてはいけません。賢い人間はそれを回避する方法を見つけています。それらは深層部への防御(DiD)として有効ですが、パラメータ化は、すべてのベースをカバーする確実な方法です。
もうひとつの優れたDiD戦略は、データベース内で「最小特権」を使用し、入力をホワイトリスト化することです。最小限の特権を行使するということは、アプリケーションがデータベース内で無限の権限を持たないことを意味します。仮に攻撃者がアクセスしたとしても、その被害は限定的です。
OWASPでは、いくつかの言語やプラットフォームでこの脆弱性をどのように処理するかを示した素晴らしいSQLインジェクション・チートシートを用意していますが、さらに上を目指したい方は、今すぐ私たちのプラットフォームで、お好きな言語でSQLインジェクション・チャレンジをプレイすることができます。
旅の始まり
SQLインジェクションを理解し、それを修正するために必要なステップを理解する上で、あなたは大きな進歩を遂げました。すばらしいですね。
これまで、SQLインジェクションがどのように起こるかを説明してきました。通常、攻撃者は入力を使用してデータベースのクエリを制御し、悪意のある目的を達成します。
また、SQLインジェクションの脆弱性が悪用されることによる被害も目にしてきました。アカウントが侵害され、何百万ドルものお金が失われる......悪夢のような、そして高価なものです。
SQLインジェクションを防ぐ方法を見てきました。
- クエリのパラメータ化
- オブジェクトリレーショナルマッパーとストアドプロシージャの使用
- ユーザー入力の検証とホワイトリスト化
あとは、あなた次第です。練習は、学習と習得を続けるための最良の方法です。だからこそ、私たちの ラーニングリソースSQLインジェクションの学習資料をご覧になり、無料体験版をお試しください。 無料デモプラットフォームの無料デモを試してみませんか?そうすれば、Secure Code Warrior に近づくことができるでしょう。


攻撃者は、最も古く(1998年以降)、最も厄介なデータ脆弱性の1つであるSQLインジェクションを利用して、世界中の何百万ものデータベースにある機密情報を盗み出し、変更しています。
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。

Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約するJaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。


簡単に言うと、SQL(Structured Query Language)とは、リレーショナルデータベースと通信するための言語で、開発者やデータベース管理者、アプリケーションが日々生成される膨大なデータを管理するために使用する問い合わせ言語のことです。
私たちのデータは急速に、世界で最も価値のある商品のひとつになりつつある......そして価値のあるものであれば、悪者は自分たちの利益のためにそれを手に入れようとするだろう。
攻撃者は、世界中の何百万ものデータベースに存在する機密情報を盗んだり変更したりするために、最も古く(1998年以降)、最も厄介なデータ脆弱性の1つであるSQLインジェクションを使用しています。データを安全に保つためには、開発者はSQLインジェクションについて理解する必要があります(また、その防御方法についても)。
そのために、SQLインジェクションの3つのポイントについて説明します。
- その仕組み
- なぜ危険なのか
- どうやって防御するか
SQLインジェクションの理解
SQLインジェクションは、「コンテキスト」という言葉で理解することができます。
アプリケーションの中には、データ用とコード用の2つのコンテキストが存在します。コードのコンテキストは、何を実行するかをコンピュータに伝え、処理されるべきデータから分離します。
SQLインジェクションは、攻撃者が入力したデータが、SQLインタープリターによって誤ってコードとして処理されることで発生します。
一例として、ウェブサイトの入力フィールドに攻撃者が「'' OR 1=1」と入力すると、それがSQLクエリの最後に付加されます。このクエリが実行されると、データベースのすべての行に対して「true」が返されます。これは、クエリを実行したテーブルのすべてのレコードが返されることを意味します。
SQLインジェクションの影響は、壊滅的なものになる可能性があります。ログインページで発生した場合、ユーザー名やパスワードを含むすべてのユーザー記録が返される可能性があります。データを取り出すための単純なクエリが成功すれば、データを変更するためのクエリも成功するでしょう。
SQLインジェクションの脆弱性がどのようなものかを実際に確認するために、脆弱なコードを見てみましょう。
このコードをチェックしてください。
String query = "SELECT account balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");
try {
Statement statement = connection.createStatement( ... );
ResultSet results = statement.executeQuery( query );
}
ここでのコードは、検証を行わずに、クライアントからのパラメータ情報を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」という文字列を検索しますが、データベース内には見つかりません。単に肩をすくめて、"Sorry, I can't find that for you. "と言うだけです。
Javaでのパラメータ化されたクエリの例は次のようになります。

ほとんどの開発フレームワークには、SQLインジェクションに対する防御機能が組み込まれています。
.NETファミリーのEntity Frameworkのようなオブジェクトリレーショナルマッパー(ORM)は、デフォルトでクエリをパラメータ化します。これにより、SQLインジェクションの対策が何もしなくてもできるようになります。
しかし、特定のORMがどのように機能するかを知っておく必要があります。例えば、Javaの世界では人気の高いORMであるHibernate も、使い方を誤るとSQLインジェクションの危険性があります。
クエリのパラメータ化は最初で最良の防御策ですが、他にもあります。ストアドプロシージャもSQLパラメータをサポートしており、SQLインジェクションを防ぐために使用することができます。ただし、ストアドプロシージャも正しく構築されていなければなりませんのでご注意ください。
// This should REALLY be validated too
String custname = request.getParameter("customerName");
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.preparedStatement( query );
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery( );
常に入力を検証し、サニタイズしてください。OR 1=1 "のような文字は、アプリケーションの正当なユーザーが入力することはないので、許可する必要はありません。ユーザーにエラーメッセージを表示したり、入力を処理する前にそれらの文字を取り除くことができます。
とはいえ、バリデーションやサニタイズだけに頼っていてはいけません。賢い人間はそれを回避する方法を見つけています。それらは深層部への防御(DiD)として有効ですが、パラメータ化は、すべてのベースをカバーする確実な方法です。
もうひとつの優れたDiD戦略は、データベース内で「最小特権」を使用し、入力をホワイトリスト化することです。最小限の特権を行使するということは、アプリケーションがデータベース内で無限の権限を持たないことを意味します。仮に攻撃者がアクセスしたとしても、その被害は限定的です。
OWASPでは、いくつかの言語やプラットフォームでこの脆弱性をどのように処理するかを示した素晴らしいSQLインジェクション・チートシートを用意していますが、さらに上を目指したい方は、今すぐ私たちのプラットフォームで、お好きな言語でSQLインジェクション・チャレンジをプレイすることができます。
旅の始まり
SQLインジェクションを理解し、それを修正するために必要なステップを理解する上で、あなたは大きな進歩を遂げました。すばらしいですね。
これまで、SQLインジェクションがどのように起こるかを説明してきました。通常、攻撃者は入力を使用してデータベースのクエリを制御し、悪意のある目的を達成します。
また、SQLインジェクションの脆弱性が悪用されることによる被害も目にしてきました。アカウントが侵害され、何百万ドルものお金が失われる......悪夢のような、そして高価なものです。
SQLインジェクションを防ぐ方法を見てきました。
- クエリのパラメータ化
- オブジェクトリレーショナルマッパーとストアドプロシージャの使用
- ユーザー入力の検証とホワイトリスト化
あとは、あなた次第です。練習は、学習と習得を続けるための最良の方法です。だからこそ、私たちの ラーニングリソースSQLインジェクションの学習資料をご覧になり、無料体験版をお試しください。 無料デモプラットフォームの無料デモを試してみませんか?そうすれば、Secure Code Warrior に近づくことができるでしょう。

簡単に言うと、SQL(Structured Query Language)とは、リレーショナルデータベースと通信するための言語で、開発者やデータベース管理者、アプリケーションが日々生成される膨大なデータを管理するために使用する問い合わせ言語のことです。
私たちのデータは急速に、世界で最も価値のある商品のひとつになりつつある......そして価値のあるものであれば、悪者は自分たちの利益のためにそれを手に入れようとするだろう。
攻撃者は、世界中の何百万ものデータベースに存在する機密情報を盗んだり変更したりするために、最も古く(1998年以降)、最も厄介なデータ脆弱性の1つであるSQLインジェクションを使用しています。データを安全に保つためには、開発者はSQLインジェクションについて理解する必要があります(また、その防御方法についても)。
そのために、SQLインジェクションの3つのポイントについて説明します。
- その仕組み
- なぜ危険なのか
- どうやって防御するか
SQLインジェクションの理解
SQLインジェクションは、「コンテキスト」という言葉で理解することができます。
アプリケーションの中には、データ用とコード用の2つのコンテキストが存在します。コードのコンテキストは、何を実行するかをコンピュータに伝え、処理されるべきデータから分離します。
SQLインジェクションは、攻撃者が入力したデータが、SQLインタープリターによって誤ってコードとして処理されることで発生します。
一例として、ウェブサイトの入力フィールドに攻撃者が「'' OR 1=1」と入力すると、それがSQLクエリの最後に付加されます。このクエリが実行されると、データベースのすべての行に対して「true」が返されます。これは、クエリを実行したテーブルのすべてのレコードが返されることを意味します。
SQLインジェクションの影響は、壊滅的なものになる可能性があります。ログインページで発生した場合、ユーザー名やパスワードを含むすべてのユーザー記録が返される可能性があります。データを取り出すための単純なクエリが成功すれば、データを変更するためのクエリも成功するでしょう。
SQLインジェクションの脆弱性がどのようなものかを実際に確認するために、脆弱なコードを見てみましょう。
このコードをチェックしてください。
String query = "SELECT account balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");
try {
Statement statement = connection.createStatement( ... );
ResultSet results = statement.executeQuery( query );
}
ここでのコードは、検証を行わずに、クライアントからのパラメータ情報を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」という文字列を検索しますが、データベース内には見つかりません。単に肩をすくめて、"Sorry, I can't find that for you. "と言うだけです。
Javaでのパラメータ化されたクエリの例は次のようになります。

ほとんどの開発フレームワークには、SQLインジェクションに対する防御機能が組み込まれています。
.NETファミリーのEntity Frameworkのようなオブジェクトリレーショナルマッパー(ORM)は、デフォルトでクエリをパラメータ化します。これにより、SQLインジェクションの対策が何もしなくてもできるようになります。
しかし、特定のORMがどのように機能するかを知っておく必要があります。例えば、Javaの世界では人気の高いORMであるHibernate も、使い方を誤るとSQLインジェクションの危険性があります。
クエリのパラメータ化は最初で最良の防御策ですが、他にもあります。ストアドプロシージャもSQLパラメータをサポートしており、SQLインジェクションを防ぐために使用することができます。ただし、ストアドプロシージャも正しく構築されていなければなりませんのでご注意ください。
// This should REALLY be validated too
String custname = request.getParameter("customerName");
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.preparedStatement( query );
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery( );
常に入力を検証し、サニタイズしてください。OR 1=1 "のような文字は、アプリケーションの正当なユーザーが入力することはないので、許可する必要はありません。ユーザーにエラーメッセージを表示したり、入力を処理する前にそれらの文字を取り除くことができます。
とはいえ、バリデーションやサニタイズだけに頼っていてはいけません。賢い人間はそれを回避する方法を見つけています。それらは深層部への防御(DiD)として有効ですが、パラメータ化は、すべてのベースをカバーする確実な方法です。
もうひとつの優れたDiD戦略は、データベース内で「最小特権」を使用し、入力をホワイトリスト化することです。最小限の特権を行使するということは、アプリケーションがデータベース内で無限の権限を持たないことを意味します。仮に攻撃者がアクセスしたとしても、その被害は限定的です。
OWASPでは、いくつかの言語やプラットフォームでこの脆弱性をどのように処理するかを示した素晴らしいSQLインジェクション・チートシートを用意していますが、さらに上を目指したい方は、今すぐ私たちのプラットフォームで、お好きな言語でSQLインジェクション・チャレンジをプレイすることができます。
旅の始まり
SQLインジェクションを理解し、それを修正するために必要なステップを理解する上で、あなたは大きな進歩を遂げました。すばらしいですね。
これまで、SQLインジェクションがどのように起こるかを説明してきました。通常、攻撃者は入力を使用してデータベースのクエリを制御し、悪意のある目的を達成します。
また、SQLインジェクションの脆弱性が悪用されることによる被害も目にしてきました。アカウントが侵害され、何百万ドルものお金が失われる......悪夢のような、そして高価なものです。
SQLインジェクションを防ぐ方法を見てきました。
- クエリのパラメータ化
- オブジェクトリレーショナルマッパーとストアドプロシージャの使用
- ユーザー入力の検証とホワイトリスト化
あとは、あなた次第です。練習は、学習と習得を続けるための最良の方法です。だからこそ、私たちの ラーニングリソースSQLインジェクションの学習資料をご覧になり、無料体験版をお試しください。 無料デモプラットフォームの無料デモを試してみませんか?そうすれば、Secure Code Warrior に近づくことができるでしょう。

以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約するJaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
簡単に言うと、SQL(Structured Query Language)とは、リレーショナルデータベースと通信するための言語で、開発者やデータベース管理者、アプリケーションが日々生成される膨大なデータを管理するために使用する問い合わせ言語のことです。
私たちのデータは急速に、世界で最も価値のある商品のひとつになりつつある......そして価値のあるものであれば、悪者は自分たちの利益のためにそれを手に入れようとするだろう。
攻撃者は、世界中の何百万ものデータベースに存在する機密情報を盗んだり変更したりするために、最も古く(1998年以降)、最も厄介なデータ脆弱性の1つであるSQLインジェクションを使用しています。データを安全に保つためには、開発者はSQLインジェクションについて理解する必要があります(また、その防御方法についても)。
そのために、SQLインジェクションの3つのポイントについて説明します。
- その仕組み
- なぜ危険なのか
- どうやって防御するか
SQLインジェクションの理解
SQLインジェクションは、「コンテキスト」という言葉で理解することができます。
アプリケーションの中には、データ用とコード用の2つのコンテキストが存在します。コードのコンテキストは、何を実行するかをコンピュータに伝え、処理されるべきデータから分離します。
SQLインジェクションは、攻撃者が入力したデータが、SQLインタープリターによって誤ってコードとして処理されることで発生します。
一例として、ウェブサイトの入力フィールドに攻撃者が「'' OR 1=1」と入力すると、それがSQLクエリの最後に付加されます。このクエリが実行されると、データベースのすべての行に対して「true」が返されます。これは、クエリを実行したテーブルのすべてのレコードが返されることを意味します。
SQLインジェクションの影響は、壊滅的なものになる可能性があります。ログインページで発生した場合、ユーザー名やパスワードを含むすべてのユーザー記録が返される可能性があります。データを取り出すための単純なクエリが成功すれば、データを変更するためのクエリも成功するでしょう。
SQLインジェクションの脆弱性がどのようなものかを実際に確認するために、脆弱なコードを見てみましょう。
このコードをチェックしてください。
String query = "SELECT account balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");
try {
Statement statement = connection.createStatement( ... );
ResultSet results = statement.executeQuery( query );
}
ここでのコードは、検証を行わずに、クライアントからのパラメータ情報を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」という文字列を検索しますが、データベース内には見つかりません。単に肩をすくめて、"Sorry, I can't find that for you. "と言うだけです。
Javaでのパラメータ化されたクエリの例は次のようになります。

ほとんどの開発フレームワークには、SQLインジェクションに対する防御機能が組み込まれています。
.NETファミリーのEntity Frameworkのようなオブジェクトリレーショナルマッパー(ORM)は、デフォルトでクエリをパラメータ化します。これにより、SQLインジェクションの対策が何もしなくてもできるようになります。
しかし、特定のORMがどのように機能するかを知っておく必要があります。例えば、Javaの世界では人気の高いORMであるHibernate も、使い方を誤るとSQLインジェクションの危険性があります。
クエリのパラメータ化は最初で最良の防御策ですが、他にもあります。ストアドプロシージャもSQLパラメータをサポートしており、SQLインジェクションを防ぐために使用することができます。ただし、ストアドプロシージャも正しく構築されていなければなりませんのでご注意ください。
// This should REALLY be validated too
String custname = request.getParameter("customerName");
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.preparedStatement( query );
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery( );
常に入力を検証し、サニタイズしてください。OR 1=1 "のような文字は、アプリケーションの正当なユーザーが入力することはないので、許可する必要はありません。ユーザーにエラーメッセージを表示したり、入力を処理する前にそれらの文字を取り除くことができます。
とはいえ、バリデーションやサニタイズだけに頼っていてはいけません。賢い人間はそれを回避する方法を見つけています。それらは深層部への防御(DiD)として有効ですが、パラメータ化は、すべてのベースをカバーする確実な方法です。
もうひとつの優れたDiD戦略は、データベース内で「最小特権」を使用し、入力をホワイトリスト化することです。最小限の特権を行使するということは、アプリケーションがデータベース内で無限の権限を持たないことを意味します。仮に攻撃者がアクセスしたとしても、その被害は限定的です。
OWASPでは、いくつかの言語やプラットフォームでこの脆弱性をどのように処理するかを示した素晴らしいSQLインジェクション・チートシートを用意していますが、さらに上を目指したい方は、今すぐ私たちのプラットフォームで、お好きな言語でSQLインジェクション・チャレンジをプレイすることができます。
旅の始まり
SQLインジェクションを理解し、それを修正するために必要なステップを理解する上で、あなたは大きな進歩を遂げました。すばらしいですね。
これまで、SQLインジェクションがどのように起こるかを説明してきました。通常、攻撃者は入力を使用してデータベースのクエリを制御し、悪意のある目的を達成します。
また、SQLインジェクションの脆弱性が悪用されることによる被害も目にしてきました。アカウントが侵害され、何百万ドルものお金が失われる......悪夢のような、そして高価なものです。
SQLインジェクションを防ぐ方法を見てきました。
- クエリのパラメータ化
- オブジェクトリレーショナルマッパーとストアドプロシージャの使用
- ユーザー入力の検証とホワイトリスト化
あとは、あなた次第です。練習は、学習と習得を続けるための最良の方法です。だからこそ、私たちの ラーニングリソースSQLインジェクションの学習資料をご覧になり、無料体験版をお試しください。 無料デモプラットフォームの無料デモを試してみませんか?そうすれば、Secure Code Warrior に近づくことができるでしょう。
目次
始めるためのリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.





.png)
