SQLインジェクション - セキュリティと対策 パート2

意図的な攻撃と検出方法

SQLインジェクションの脆弱性を把握するため、業界では貴社のサイトやアプリに対して攻撃を行うよう推奨されています。SQLやその派生形は魅力的な言語ですが、攻撃者はデータベースを操作できるコードを組み立てる手法を熟知しています。オープンソースのツールが増えたことで、脆弱性のテストは以前ほど困難ではなくなりました。

約10年前、US-CERTが発行した『SQLインジェクション脆弱性の特定方法』は、Web管理者がSQLインジェクション攻撃と戦うための指針を示しました。これには、アプリが特殊に作成された問い合わせにどう反応するかを検証するための検出手法が含まれており、以下のような方法が挙げられます。

‍

SQLインジェクション脆弱性のテスト

貴社では、SQLインジェクションの脆弱性をチェックするために、無料あるいは有料のツールを利用できます。

通常、これらのツールはまず貴社のサイトがどのデータベースを使用しているかを確認します。システムがデータベースの属性を調べるための問い合わせを組み立てる仕組みであり、利用者にほとんどSQLの知識を求めず、テーブルやフィールド、詳細な情報を対象から抽出することが可能です。

さらに多くのツールには、検出された脆弱性の一部を修正する機能が備わっています。また、多くの優れたSQLインジェクションツールがオープンソースで提供されているため、外部者より先に、貴社がアプリのテストを実施することが推奨されます。

SQLi検出ツールの利用

複数のオープンソース開発者やサイバーセキュリティベンダーが、自動SQLインジェクションツールを開発し、潜在的な脆弱性の検出に努めています。オープンソースの検出ツールでは、jSQLやSQLMapが特に有名で、他には以下のものがあります:

• BBQSQL
• Blisqy
• Blind-SQL-Bit shifting
• explo
• Damn Small SQLi Scanner (DSSS)
• NoSQLMap
• Leviathan
• Whitewidow
• Tyrant-SQL

SQLインジェクション攻撃を防ぐステップ

SQLインジェクション攻撃はWeb管理者が最も恐れるDBの脅威のひとつですが、実際には防止するためにできる対策は多く存在します。

以下は、SQLインジェクション攻撃の被害を軽減するために取れる18の実績ある対策です:

1. ‍ユーザー入力の検証

SQLインジェクション攻撃を防ぐ最初の基本対策は、利用者からの入力値を検証することです。まず、基本となるSQL文を特定し、認証済みのSQL構文のみを許可するホワイトリストを設定します。これによりクエリの検証、すなわちデータのチェックが行われます。

また、入力値に制限を設けることでサニタイズを強化します。例えば、メールアドレス入力欄では、メールアドレスに許容される文字のみを受け付け、必須の「@」記号などが正しく入力されるようにします。

さらに、社会保障番号などの識別番号も、それぞれの桁数のみを許可するように区切って設定するべきです。

この対策だけでSQLi攻撃者を完全に防ぐことはできませんが、一般的なパターンマッチング手法に対する追加の防御策となります。

2. ‍特殊文字の制限によるデータの洗浄

SQLインジェクション攻撃者は、特殊な文字列を利用してデータベースを攻撃する可能性があるため、不適切なデータサニタイズを防ぐことも重要です。入力されたデータに不要な文字が含まれないよう、厳しく洗浄する必要があります。

例えば、MySQLのmysql_real_escape_string()のように、利用者の入力をあらかじめ制限する手法を用いることで、単一引用符（'）などの危険な文字がSQLクエリに命令として渡されるのを防ぐことができます。クエリを検証せずに組み立てないよう、パラメータ化されたステートメントを利用する基本手法も覚えておく必要があります。

3. ‍プリペアドステートメントとパラメータ化の利用

残念ながら、単なる入力値の検証やデータの洗浄だけでは万全ではありません。すべてのデータベースクエリには、パラメータバインディングを用いたパラメータ化クエリを使用することが重要です。これにより、ユーザーの入力と実行すべき命令を明確に区別できます。

動的なSQLは柔軟性がある反面、SQLインジェクションの脆弱性を招く恐れがあります。規格に沿ったSQLを使用することで、危険なSQL文はデータとして扱われ、実行命令として処理されることを防げます。

4. ‍データベースに保存されたストアドプロシージャの利用

ストアドプロシージャを利用する際も、パラメータバインディングが必要です。プリペアドステートメントとは異なり、これらはデータベース内に配置され、アプリから呼び出されます。しかし、動的SQL生成を行う場合は完全に脆弱性を除去できるわけではありません。

OWASPなどの組織は、いずれか一方のパラメータ化手法で十分としていますが、最適なセキュリティを実現するためには、両方の手法の併用が望ましいです。

5. ‍パッチやアップデートの適切な管理

SQLインジェクションによって悪用される脆弱性は、アプリやデータベースにおいて日々発見され、公開されています。多くのネットワークセキュリティ脅威と同様、関連する組織は最新情報を収集し、パッチやアップデートを適宜適用しています。SQLi対策としては、データベースサーバーソフト、OS、ライブラリ、モジュール、Webサーバーソフトなど、すべてのWebアプリ構成要素を最新に保つことが必要です。

もし貴社がアプリの修正やアップデートに苦戦している場合、マネージドサービスの契約を検討する価値があります。

6. ‍仮想あるいは物理のファイアウォールの強化

製品や機器ベースのWebアプリファイアウォール（WAF）の利用が強く推奨され、これによりネットワーク上の悪意あるトラフィックを遮断できます。

近年、NGFWやFWaaSの機能が加わり、ファイアウォールは包括的なデフォルトルールと柔軟なポリシー変更が可能となっています。パッチやアップデートがまだ提供されていない場合にも、WAFは有用です。

有名な例として、Apache、Microsoft IIS、Nginxに対応した無料のオープンソースモジュールModSecurityがあり、洗練された常に更新されるルールセットで潜在的に危険なWeb要求を遮断します。そのSQLインジェクション対策は、多くの攻撃試みを阻止します。

7. ‍OSとアプリの強化

この対策は、SQLインジェクション攻撃を防ぐだけでなく、全体の物理および仮想インフラが適切に作動するよう強化するものです。2020年のクラウドネットワーク契約の大量データを背景に、多くの組織がNISTなどの業界標準のセキュリティフレームワークを参考に、OSやアプリの強化を進めています。

また、アプリ提供者のセキュリティガイドラインに従うことで、組織全体のセキュリティ体制が向上し、不要なアプリやサービスの特定と無効化が可能となります。

8. ‍攻撃対象の範囲を縮小する

攻撃対象の範囲とは、ハッカーが狙えるネットワーク上の潜在的なポイントすべてを指します。SQLi攻撃においては、公開する必要のないデータベース機能を排除または制限することで、このリスクを軽減します。

例えば、Microsoft SQL ServerのXP cmd shellという拡張ストアドプロシージャは、Windowsのコマンドシェルを起動し文字列を実行させることができます。しかし、この機能はSQL Serverのサービスアカウントと同じ権限で動作するため、攻撃者に大きな被害を及ぼす恐れがあります。

9. ‍適切な権限と厳格なアクセス制御の構築

SQLデータベースの重要性を踏まえると、厳格な最小権限のアクセス制御を採用することが不可欠です。例えば、SELECT文のみで十分な場合、INSERT、UPDATE、DELETEの権限は不要です。

さらに、必要な場合以外は管理者権限のアカウントを使用せず、複数のユーザーにアクセス権を与えないことが望ましいです。仮に低権限のアカウントが侵害された場合でも、アクセス制限があれば被害が限定されます。

10. ‍読取アクセスの制限

データベースの読取アクセス設定は、SQLインジェクション対策における最小権限の考え方に基づきます。貴社が読取専用のユーザーのみを必要とする場合、その設定は容易ですが、攻撃者による保存データの改竄を防ぐためには必須の措置です。

11. ‍暗号化：秘密は秘密にする

インターネットに接続するすべてのアプリは安全とは言えないため、パスワードや機密データ、接続文字列はすべて暗号化およびハッシュ化されるべきです。

今日、暗号化はデータ保護手法としてほぼ標準化しており、その理由も明白です。適切な暗号化やハッシュ化がなければ、機密情報が容易に攻撃者の目に触れる恐れがあります。Microsoftによれば、暗号化は「データ保護の問題を暗号鍵の保護の問題へと転換する」手法です。

12. ‍長すぎるURLへの対策

SQLi攻撃者は、URLを異常に長くすることでサーバがリクエスト全体を記録できなくする手法を用います。2013年、eSecurityPlanetは攻撃者が長いURLを送信してFoxitを悪用し、スタックベースのバッファオーバーフローを引き起こしたと報告しました。

例えば、Microsoft IISは4096バイトを超えるリクエストを処理する設計ですが、ログにはリクエスト全体が記録されないため、攻撃者は検出されずにクエリを実行できる恐れがあります。これを回避するため、URLの長さを2048バイトに制限することが推奨されます。

13. ‍エラーメッセージで必要以上の情報を漏らさない

エラーメッセージからデータベースの設計に関する情報が漏れる可能性があるため、エラー内容は最低限の情報に留める必要があります。ローカル環境では詳細なエラーを表示し、外部からのアクセスでは「RemoteOnly」などのカスタムエラーモードを用いることで、攻撃者にはエラー発生の事実だけが伝わるようにすることが重要です。この対策は、内部データベースの構造やアカウント、テーブル名の保護に不可欠です。

14. ‍共有データベースやユーザーアカウントの禁止

複数のサイトやアプリがデータベースを共有すると、大規模な問題に発展する可能性があります。同様に、異なるアプリと連携するユーザーアカウントもリスクとなります。共通のアカウントは管理上の柔軟性をもたらす一方で、大きなリスクを伴います。

通常、連携サーバはターゲットサーバへのアクセスが制限され、必要最低限のデータのみ扱います。ターゲットサーバ上のアカウントは、連携サーバのものと異なるユーザー名で設定されるべきです。

15. ‍アカウントおよびパスワードポリシーのベストプラクティスの徹底

自明に思えるかもしれませんが、完全な保護のためには、ベストなアカウントおよびパスワードポリシーの遵守が必要です。初期設定や組み込みのパスワードは、利用開始前に速やかに変更し、定期的な更新を行うべきです。SQLサーバの管理者、ユーザー、システムアカウントすべてに対し、適切な長さと複雑性を備えたパスワードが求められます。

16. ‍SQL文の継続的な監視

貴社または第三者ベンダーは、データベースに接続するアプリのすべてのSQL文を継続的に監視し、データベースアカウント、プリペアドステートメント、ストアドプロシージャを記録する必要があります。SQL文の動作が把握できれば、不正なSQL文や脆弱性の特定が容易になります。この監視により、不要なアカウントやプリペアドステートメント、ストアドプロシージャを無効化できます。

PAMやSIEMのような、機械学習や行動分析を活用する監視ツールは、ネットワークセキュリティの強化に有用です。

17. ‍定期的な監査と侵入テストの実施

定期的なデータベースやアプリのセキュリティ監査は、疑わしい活動ログ、グループおよび役割の権限、パラメータバインディングの設定などを含め、ますます重要になっています。

また、SQLiを含むさまざまな攻撃に対する防御体制の反応を確認する侵入テストの実施も、悪意ある行動の監査と同じくらい重要です。クロスサイトスクリプティング、旧式のソフトウェア、未修正の欠陥、インジェクション、セキュリティの弱いパスワードなどは、ほとんどの侵入テスト会社が検出可能なリスクです。

18. ‍コード開発とより良いソフトの調達

技術ソリューション市場には明確な階層が存在します。大企業は高価なサードパーティ製品を導入し、社内でさらにソフトを開発できる一方、小規模事業者はコストを抑えるか、無料のオープンソースの代替案を検討する必要があります。

とはいえ、最終的にはベンダーの開発者が、顧客のカスタムアプリにおける欠陥に責任を負うことになるため、ベンダーは契約条件にコードレビューの義務が含まれるよう留意すべきです。