Web アプリケーションセキュリティ

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

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

前回 、インジェクション型攻撃がウェブ・アプリケーションにもたらすリスクについて議論した。これらの攻撃は（以前はより一般的であったが）まだ一般的であり、典型的には、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クエリを発見できるように、ジェネリッククエリを利用する必要がある。 ...