2014年を揺るがしたインジェクション攻撃の手口と対策：セキュリティ強化塾（4/4 ページ）

2014年はOpenSSL、Struts2、bashと、深刻な脆弱（ぜいじゃく）性が次々に公表された。特に顕著だった攻撃手口と対策を紹介する。

[キーマンズネット]

その他の注意すべき脆弱性

　インジェクション攻撃の他、最近特に注意が必要な脆弱性に、ディレクトリトラバーサル（ファイル名指定の実装に問題があるケース）、アクセス制御や認可制御の欠落（認証機能の欠落、あるいは認証はしていてもユーザーごとのアクセス認可制御を施していないケース）、クロスサイトスクリプティング（Webページへの不正なスクリプトの埋め込み、図3）などがある。特にクロスサイトスクリプティングはIPAへの報告例が抜きん出て多く、警戒が必要だ。

図3 クロスサイトスクリプティングの手口の例（出典：IPA）

　これらの脆弱性の説明と対策についてもIPA「安全なウェブサイトの作り方」が参考になるので、ぜひ一読をお薦めする。

脆弱性が解消できない場合の回避策

　Webアプリケーションの脆弱性は、基本的に改修してなくすのが王道であり、利用するシェルやフレームワークなどは脆弱性対策パッチが公表され次第に適用し、最新版があればできるだけ早く移行を図ることが大事だ。

　しかし、現実的にはアプリケーション開発を委託した時点で後々の脆弱性対策のための改修を見込んだ契約が交わされることはあまりなく、改修が必要になったときには既に委託した業者が存在していなかったり、当時のドキュメントが保管されていなかったりと、トラブルが生じることがままある。

　脆弱性が公表されたツールを利用しているか否かについても自社内では分からないことも多い。また、開発当時の自社内技術者が改修のときにも現役でいるとは限らない。そのため改修やツールのバージョンアップが技術的にできない場合がある。

　そんな羽目に陥らないよう、そもそもWebアプリケーション開発時に、運用、保守に関する契約を交わしておくか、スポットでも保守、改修を引き受けてもらえる取り決めをしておくことが望ましい。これが、いずれ必ずといっていいほど発生する脆弱性への対策の大事なポイントの1つだ。

　しかし、委託業者としても改修が難しい場合もあるだろうし、発注会社にしても改修コストがあまり高額になるようでは困る。そこで、脆弱性の回避策として、WAFの利用を検討するのも一策だ。

　WAFは、Webアプリケーションの前段で通信内容（HTTPリクエストやレスポンス）をチェックし、不正な部分の有無を判定する機能をもったゲートウェイ設置のセキュリティ製品だ。専用製品もあれば、UTMなど他のセキュリティ製品に備えられる場合もある。

　図4に見るように、通信が正当（陰性）であれば通過させ、不正（陽性）であればブロックする。このようなツールを導入すれば、各種のインジェクション攻撃を水際で防御できる。

図4 陰性判定と陽性判定（出典：IPA）

　脆弱性の有無は自社内で気付くことが難しいが、第三者による脆弱性テストサービスやコンサルティングなども提供されるので、脆弱性の有無を診断しながら必要な対策を講じることをお薦めする。

　また、各種攻撃への対策がとれているか否かを自社内でも診断できるように、IPAでは「ウェブ健康診断仕様」という冊子（「安全なウェブサイトの作り方」別冊）を用意する。これで基本的な対策ができているかどうかを簡易的に診断できるので、試してみるとよいだろう。