WebアプリケーションやWebサービスのセキュリティ向上を目的に、共同研究や関連活動を進める非営利団体のOWASP（Open Web Application Security Project）。セキュリティの有識者集団であるOWASPのメンバーが選んだ、Webアプリケーションの最も危険な10個の脆弱性を記した年次調査リポートが「OWASP TOP 10」だ。

最も危険な脆弱性は「インジェクション攻撃」

　まず、2010年と2013年に公開されたOWASP TOP 10を比較し、Webアプリケーションセキュリティの変化を見ていこう（表1）。

　2013年に最も高い危険性があると判断されたのは、2010年と同様に「インジェクション攻撃」である。続いて「不適切な認証とセッション管理」「クロスサイトスクリプティング（XSS）」「安全でないオブジェクトの直接参照」など、若干の順位の変化はあるものの、危険性が高いと評価された脆弱性の上位4位までは、2010年と同じ顔ぶれだ。

　トレンドという観点で見ると、2010年から2013年への大きな変化として、以下の3点が挙げられる。

1. 「セキュリティの不適切な設定」（2010-A6）から、「既知の脆弱なコンポーネントの使用」（2013-A9）を分離して追加
2. 「安全でない暗号化によるデータ保存」（2010-A7）と「不十分なトランスポート層の保護」（2010-A9）を統合し、「機密データの露出」（2013-A6）を追加
3. 「URLアクセス制限の不備」（2010-A8）から、「機能レベルのアクセス制御の欠落」（2013-A7）へ変更

　この中で、私は2013年に新たに追加された「既知の脆弱なコンポーネントの使用」（2013-A9）に着目した。

「既知の脆弱性」がWebアプリを危険にする理由

　「既知の脆弱なコンポーネントの使用」と聞くと、Webアプリケーションセキュリティに詳しい読者は、疑問に思うかもしれない。一般的に「既知の脆弱性」に起因するリスクは、OSやOSSのミドルウェアなどに影響を与えるものであり、Webアプリケーションに関係するリスクとしてのイメージがあまりないからだ。

　それではなぜ、今回のOWASP TOP 10に「既知の脆弱なコンポーネントの使用」が新たに追加されたのか。

　OWASP Top 10を作成するプロジェクトの「OWASP Top Ten Project」によると、企業などがWebサイト用に独自にコーディングしたオリジナルコードの量は、ここ10年変化が見られないという。ただし、同プロジェクトは、Webアプリケーションを構成するコードの中に含まれる既存のライブラリやフレームワークなど、いわゆるサードパーティー製コードの量が急速に増加していることを指摘。オリジナルコードが1つのWebサイト当たり平均20万行なのに対し、サードパーティー製コードは今や約80万行にもなっており、その割合は今後さらに増え続けるだろうと推測する（図1）。

　この背景にあるのは、「Apache Struts」などのWebアプリケーション開発のフレームワークの発展やコンテンツ管理システム（CMS）の普及だ。

サードパーティー製コードの危険性

　開発者自らがフルスクラッチ（既存コードを使わない新規開発）で書いたコードではなく、第三者が作成したコードであるサードパーティー製コード。先ほど触れたように、Apache Strutsなどのフレームワークやライブラリ、CMS、プラグインなどが、サードパーティー製コードの代表例だ。Webアプリ開発においてサードパーティー製コードの利用が進んでいる理由は、開発費用や工数を少なくでき、短納期での開発ができるためである。

　一方で、サードパーティー製コードを積極的に利用することは、同時にセキュリティ上の課題を増大する危険をはらんでいる。

　「Apache HTTP Server」や米非営利団体Internet Systems Consortium（ISC）の「BIND」など、歴史がありユーザー企業数も多いサーバアプリケーションと比較した場合、Webアプリケーションで最近よく利用されるライブラリやCMSプラグインなどは、セキュリティチェックを十分にできるスキルを持ったエンジニアが少ない。十分にセキュリティチェックをしないままリリースしてしまうので、リリース後に重大な脆弱性が発見されることが多くなる。

　Webサイト内で利用しているサードパーティー製コードを十分に管理するのが難しいことや、エンドユーザーのセキュリティ意識が低いことも憂慮すべき問題だ。さらに、自身で作成したコードとは異なり、脆弱性が見つかった場合に利用者側で修正ができないケースも多いのも、サードパーティー製コードの難点だといえる。

　サードパーティー製コードを利用する際の現状と、セキュリティの懸念を以下の表2にまとめた。

　こうした懸念は、そのまま攻撃者が取る攻撃手法のトレンドにも反映されている。それこそが、2013年のOWASP Top 10に「既知の脆弱なコンポーネントの使用」が追加された大きな要因なのである。

サードパーティー製コードへのセキュリティ対策

　重大な脆弱性をもたらす可能性のあるサードパーティー製コード。とはいえ、Webアプリ開発の効率向上が重視される現状を踏まえると、サードパーティー製コードを全く使用しないという選択肢を取れる企業は少ないはずだ。

　危険性を理解しつつ、サードバーティー製コードを使用しなければならない企業へのアドバイスとして、以下の3点を挙げることができる。

1. サードパーティー製コードの使用にまつわる、技術面、運用面におけるセキュリティポリシーを策定する
2. サードパーティー製コードに関するセキュリティ情報のキャッチアップと、攻撃防御機構を導入する
3. サードパーティー製コードは脆弱性を含んでいる可能性がある、という意識を徹底する

　企業の間にセキュリティポリシーを策定する動きは広がりつつあり、OSや使用アプリケーションに関するセキュリティポリシーを定めている企業は少なくない。ただし、上記の3点を明確な規定や細則に盛り込んでいる企業は、極めて少ないのが実情である。

　また、侵入検知システム（IDS）や侵入防御システム（IPS）、Webアプリケーションファイアウォール（WAF）を用いた攻撃の検知、防御に取り組む企業も増えつつあるが、欧米諸国と比べて、国内では、こうしたセキュリティ製品の導入率はまだまだ低い。日々のセキュリティモニタリングや脆弱性検出時の防御を徹底するには、こうしたセキュリティ製品の導入検討は喫緊の課題だと考えられる。

　サードパーティー製コードを利用する場合の、具体的なセキュリティ対策の一例を示したのが以下の図2だ。

　上述した通り、サードパーティー製コードは自身で作成したコードではないため、その修正は人任せにならざるを得ない場合もある。また最近の傾向を見てみると、脆弱性が公開された後、その脆弱性を狙った攻撃手法が出回るまでの時間が短縮化しており、管理者側の対策猶予時間も短くなっている。修正パッチやアップデートがリリースされるまでの間、いわゆるゼロデイ期間をWAFなどのセキュリティ製品で防御することは非常に有効である。

　サードパーティー製コードの使用者側に求められるのは、「サードパーティー製コードには脆弱性があり得る」のだと意識することだ。その意識の下で、自社のWebサイトで使用しているサードパーティー製コードの棚卸しをする必要がある。

　自ら管理するWebサイトにおいて、保有する脆弱性管理ができていない管理者には、一度「Webアプリケーションの脆弱性診断」を受けることをお勧めする。企業自身で十分に実施できるのであればそれでもいいが、可能であれば第三者視点による脆弱性診断を受ける方が望ましい。

　脆弱性診断サービスを利用する場合は、サービスの見極めに注意が必要だ。いわゆる「Webスキャナツール」を使って調べるだけのサービスは利用しない方がよいだろう。こうしたサービスは得てして安価だが、ツールだけでは見つからない脆弱性は少なくないからだ。

　棚卸しや脆弱性診断の結果、脆弱性が見つかった場合は、リスクを評価した上で適切なアップデートを速やかに実施しなければならないのは言うまでもない。

　次回は、企業利用が近年増えており、サードパーティー製コードの代表格であるコンテンツ管理システム（CMS）を取り上げ、そのトレンドやセキュリティリスクについて掘り下げていく。