ウェブアプリケーションに潜む危険は数多くあるが、これまでのセキュリティ対策で指摘されてきたのは脆弱性の種類から見た危険性とその対策だった。

　たとえば、クロスサイトスクリプティングの脆弱性とは何か、SQLインジェクションの脆弱性とは何か、そしてそれらへの対策とは……。これらについては、既に的確な解説をウェブ上で見つけることができるので、この連載では改めてその視点での解説はしない。

　この連載では逆の視点から、つまり原因となる行動に焦点をあてて、ウェブアプリケーションにおける脆弱性を考えていきたいと思う。

　まず、ウェブアプリケーションの脆弱性が発生する原因だが、「既製品の脆弱性」および「カスタマイズアプリケーションの脆弱性」の大きく2つに分類される。

　さらに、既製品の脆弱性は「既知の脆弱性」と「市販製品の設定ミス」の2つに、カスタマイズアプリケーションの脆弱性は「設計時に発生する脆弱性」「コーディング時に発生する脆弱性」の2つに分類できる。

　既製品の脆弱性については無視することはできないが、これらについてはメーカーなどから正しい対応策が公開されているものがほとんど。ユーザーとして、あるいはシステム構築者としてベンダー各社からの最新情報を入手して対策を行うことが最善の方法となる。

　一方、カスタマイズアプリケーションの脆弱性は開発者が修正することが基本的な対策となる。もちろん、ウェブアプリケーション用のファイアウォールを導入するといった別解もあるが、そのような製品を扱うためにも“なぜ脆弱性が生じるのか”を理解しなければ正しい設定は行えない。そのために、どのような要因から脆弱性が生み出されるのかを認識しておく必要があるだろう。

　そこで今回は、紹介した脆弱性のパターンのうち、「設計時に発生する脆弱性」について解説してみたい。

設計時に発生する脆弱性とは？

　開発の初期段階からセキュリティ対策を行えば、コストを抑えられると言われている。しかし、既存の対策方法の多くは、コードレベルの修正方法に終始していて、実際に設計段階で何を行えばよいか分からないのが現状だろう。

　そこで、まずは設計時に作りこんでしまう脆弱性と、設計時のセキュリティ対策について考えてみたい。ここには大きく分けて2つの脆弱性が作られる可能性がある。ひとつは「画面遷移に関係する脆弱性」であり、もうひとつは「機能設計に関係する脆弱性」である。それぞれに対応する具体例は、以下のとおりだ。