ウェブアプリケーションセキュリティ 第2版

第31章. インジェクションから身を守る

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

第13章では、 インジェクション型攻撃がウェブ・アプリケーションにもたらすリスクについて議論した。これらの攻撃はまだ一般的であり（以前はもっと一般的であったが）、典型的には、CLI とユーザが投稿したデータを含む、あらゆるタイプの自動化を書いている開発者側の不適切な注意の結果である。

インジェクション攻撃はまた、広い表面領域をカバーしている。インジェクションは、CLIやサーバ上で実行されているその他の分離されたインタプリタに対して使用することができる（OSレベルに達すると、代わりにコマンド・インジェクションになる）。その結果、インジェクションスタイルの攻撃に対してどのように防御するかを考える場合、そのような防御手段をいくつかのカテゴリーに分ける方が簡単である。

まず最初に、SQLインジェクション攻撃に対する防御を評価すべきである。SQLインジェクションを防御するために何ができるかを調査した後、どの防御が他の形式のインジェクション攻撃にも適用できるかを確認する。最後に、インジェクションに基づく攻撃の特定のサブセットに特化しない、インジェクションに対するいくつかの汎用的な防御メソッドを評価することができる。

SQLインジェクションを緩和する

SQL インジェクションは、インジェクション攻撃の中で最も一般的なものであり、同様に最も防御しやすいものでもある。SQLインジェクションは、（SQLデータベースが普及しているため）ほとんどすべての複雑なウェブ・アプリケーションに影響を与える可能性があり、非常に広範囲に広がっているため、SQLインジェクションに対する多くの緩和策や対策が開発されてきた。

さらに、SQLインジェクション攻撃はSQLインタプリタ内で行われるため、このような脆弱性の検出は非常に簡単である。適切な検出と緩和戦略があれば、ウェブ・アプリケーションがSQLインジェクション攻撃にさらされる確率はかなり低くなる。

SQLインジェクションを検出する

SQLインジェクション攻撃に対する防御のためにコードベースを準備するには、まずSQLインジェクションがどのような形で行われるのか、そしてコードベースの中で最も脆弱な場所はどこなのかをよく理解することだ。ほとんどの最新のウェブ・アプリケーションでは、SQL演算子はサーバ側のルーティング・レベルを超えて発生する。つまり、クライアント側にはあまり興味がないということだ。例えば、ウェブ・アプリケーションのコード・リポジトリは次のようなファイル構造になっている：

/api
  /routes
  /utils
/analytics
  /routes
/client
  /pages
  /scripts
  /media

クライアントの検索を省略できることは分かっているが、アナリティクス・ルートを検討する必要がある。たとえOSSで構築されていても、アナリティクス・データをストアするために何らかのデータベースを使用している可能性が高いからだ。デバイスやセッション間でデータが永続化される場合、サーバ側のメモリ、ディスク（ログ）、データベースのいずれかに保存されることを覚えておこう。

サーバ上では、多くのアプリケーションが複数のデータベースを利用していることに注意する必要がある。例えば、あるアプリケーションはSQLサーバとMySQLを利用している。そのため、サーバを検索する際には、複数のSQL言語実装にまたがるSQLクエリを発見できるように、ジェネリッククエリを利用する必要がある。 ...