MailData

SQLインジェクション攻撃を防ぐための5つのヒント

SQLインジェクション攻撃を防ぐための5つのヒント

SQLインジェクションを防ぐための基本と実践的な方法

2024年3月31日
著者: Ahona Rudra
翻訳: 逆井 晶子

この記事はPowerDMARCのブログ記事 5 Tips to Prevent SQL Injection Attacks の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

SQLインジェクションとは何か？
「SQLインジェクション」という用語を聞いたことがありますか？
それを防ぐ方法を考えたことがありますか？
これらは多くのウェブ開発者が自問する質問です。

誰でもこの攻撃の対象となる可能性がありますが、自分を守る手段はあります。
適切な予防措置を講じることで、データベースを不正アクセスから簡単に守ることができます。
特に、SQLインジェクションのような攻撃からウェブサイトの利用者を守ることは、安心してサービスを利用できる環境を提供するために重要です。

SQLインジェクション攻撃とは何か、そしてSQLインジェクションを防ぐための5つのヒントを見ていきましょう。

SQLインジェクション攻撃とは？

SQLインジェクション攻撃とは、ウェブサイトやアプリケーションに組み込まれたデータベースを狙った攻撃方法です。
攻撃者は、データベースに悪意のあるSQLコードを実行して、情報を盗んだり破壊したりします。

SQLインジェクション攻撃は、データベースセキュリティを侵害する最も一般的な手法の一つです。
SQL（Structured Query Language）は、データベースにアクセスし、データベースを操作するためのプログラミング言語です。
ウェブアプリケーションは、データを保存、検索、操作するためにSQLデータベースを使用します。

攻撃者はこうした入力フィールドに特別なコードを仕込み、データベースを意図しない形で操作しようとします。
これにより、本来アクセスできない情報を盗んだり、データを破壊したりすることが可能になるのです。

どの種類のデータベースであっても、完全に安全とは言い切れません。
MariaDBやMySQLのような有名なデータベースでも攻撃を受ける可能性があります。
そのため、攻撃を防ぐために前もってしっかり対策を取ることが必要です。
革新的なウェブ開発者は、さまざまなサイバーセキュリティの脅威に対する堅牢なデジタル防御を作成するために不可欠です。

SQLインジェクション攻撃を防ぐためのヒント

SQLインジェクション攻撃は、以下のベスト・プラクティスを実装することで防ぐことができます。

ゼロトラストアプローチ

ゼロトラストとは、管理者や外部パートナー、サプライヤーを含む全てのユーザを潜在的な攻撃者と見なして、厳密なアクセス制御を行うセキュリティ手法です。
組織は、情報へのアクセスと使用に厳格な制御を適用する必要があります。

これには、データベースやアプリケーション、サービスへの外部接続に対する依存を排除または最小限に抑えることが含まれます。

ストアドプロシージャは、動的SQLクエリよりも安全であるため、SQLインジェクション攻撃のリスクを最小限に抑える方法の1つです。
ただし、ストアドプロシージャと動的クエリを両方使用する場合、テスト時にストアドプロシージャに脆弱性が存在しないことを確認する必要があります。

権限の制限
新しいアカウントを作成する際には、必要最低限の権限のみを割り当てます。
例えば、レポートを作成するアカウントと削除するアカウントを分けるなどです。
これにより、ハッカーがアプリケーションコードや設定ファイルの脆弱性を悪用して機密データにアクセスしたり、アカウントを乗っ取ったりすることが困難になります。
ストアドプロシージャの使用

ストアドプロシージャは、複数のSQLコマンドを1つのステートメントで実行することができます。
これにより、ユーザが「ユーザ名」や「パスワード」のような入力フィールドを通じてデータベースサーバーに直接アクセスすることを防ぎます。
代わりに、ユーザ (Webアプリ開発者) によって渡されたパラメーターを使用して、アプリケーションコード内から呼び出すことができる定義済みの関数を使用します。
外部サービスを統合する場合、REST、SOAP、GraphQLといった選択肢のトレードオフを比較し、ペイロードサイズ、キャッシュの効率性、ドキュメントの整備状況などを考慮して、最適な技術的判断を下します。

MySQLでストアドプロシージャを作成する方法を次に示します。
たとえば、次のようなテーブルがあるとします。 

CREATE TABLE 'salary' (
    'empid' INT(11) NOT NULL,
    'sal' INT(11) DEFAULT NULL,
    PRIMARY KEY ('empid')
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

この方法では、攻撃者がパラメータに悪意のあるコードを注入しようとしても失敗します。
アプリケーションとデータベースサーバーが直接接続されることはなく、すべての処理がローカルで行われるためです。

パラメータ化されたクエリの使用

SQLインジェクション攻撃は、ユーザが提供した入力がサニタイズされないままSQLクエリに使用される場合に発生します。
これを防ぐ方法の1つは、パラメータ化されたクエリを使用することです。
パラメータ化されたクエリでは、クエリ文字列に定数の代わりに変数を使用します。
例： 

SELECT * FROM table WHERE column = ?

上記のように変数を使うことで、次のような直接的な値の挿入によるリスクを防ぎます。 

SELECT * FROM table WHERE column = 'value'
多層セキュリティの実装

SQLインジェクションは、アプリケーションのSQL文に悪意のあるコードが挿入されることで発生します。
このコードはウェブサーバーによって実行され、開発者が意図しなかったデータがデータベースから返される原因になります。

このような攻撃を防ぐためには、複数の防御層を設ける必要があります。

  • ファイアウォールの設置
  • 強力な認証メカニズムの実装（例：二要素認証（2FA））

これらを組み合わせることで、攻撃の成功をより困難にします。

SQLインジェクション攻撃の種類

SQLインジェクションには以下の3つの種類があります。

サニタイズされていない入力
このタイプのSQLインジェクションは、アプリケーションが入力をフィルタリングまたはサニタイズせず、検証やエンコーディングを実行せずにクエリで直接使用する場合に発生します。
これにより、予期しないクエリの実行、制限されるべき関数の呼び出し、テーブルの内容の変更など、意図しない結果につながる可能性があります。
アウトオブバンドインジェクション
アウトオブバンドインジェクションは、指定されたユーザ入力チャネル（例：ウェブフォーム）以外の方法で、悪意のあるデータがアプリケーションに送信される場合に発生します。
これには、インスタントメッセージングやファイルアップロードなどの非テキスト通信チャネルが含まれます。
ブラインドSQLインジェクション
ブラインドSQLインジェクションは、無効な値が入力された場合に、ターゲットシステムがエラーメッセージを返さないため、攻撃者が内部で何が起こっているのかを確認できない場合に発生します。

SQLインジェクションテスト

SQLインジェクションテストは、WebアプリケーションにおけるSQLインジェクションの脆弱性をテストするために設計されています。
これは、特にWeb開発者にとっては特に価値があります。

このテストは、OWASP Zed Attack Proxy (ZAP)を使用して作成されました。
SQLインジェクションテストは、OWASP Foundationが提供する無料のサービスで、SQLインジェクション攻撃に対するアプリケーションのセキュリティ体制を評価するのに役立ちます。
テストでは、アプリケーションで検出されたSQLインジェクションの脆弱性と、それらを修復するための推奨事項が強調表示されます。

Sqlmapは、SQLインジェクションの脆弱性を自動で検出し、さらにその脆弱性を利用してデータベースサーバーを制御するためのオープンソースのペネトレーションテストツールです。
強力な検出エンジンを備えており、経験豊富なセキュリティテスター向けに設計された多くの高度な機能を提供します。

このツールを使用すると、データベースの種類や構成を特定するだけでなく、データベース内の情報を取得したり、サーバーのファイルシステムにアクセスしたりすることが可能です。
さらに、アウトオブバンド接続を利用して、オペレーティングシステム上でコマンドを実行することもできます。
Sqlmapは、ペネトレーションテストを効率的かつ包括的に行うための信頼性の高いツールです。

最後に

SQLインジェクション攻撃が発生する主な原因は、知識不足です。
データベースクエリやコマンドの基本を理解することが非常に重要です。
そして、それらを学んだ後も忘れずに実践することが必要です。

アプリケーションを起動する前に、これらの攻撃がどのように発生し、それに対してどのような対策を講じることができるかを理解することが重要です。
また、すでにWebサイトを開発している場合は、コードを定期的に監査してセキュリティを確保することも同様に重要です。
わずかな予防策でも大きな効果をもたらすことがあるため、コーディング時には注意が必要です。