サイト脆弱性をチェックしよう!--第1回:ウェブアプリケーションに潜む危険

池田雅一(テクマトリックス)

2007-07-26 20:36

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

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

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

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

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

既製品の脆弱性
既知の脆弱性
市販製品の設定ミス
カスタマイズアプリケーションの脆弱性
設計時に発生する脆弱性
コーディング時に発生する脆弱性

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

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

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

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

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

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

画面遷移に関係する脆弱性
強制ブラウズ
クロスサイトリクエストフォージェリ
機能設計に関係する脆弱性
機能の悪用
・メール送信機能
・パスワードエラー通知機能
・バックドア、デバッグオプション

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ZDNET Japan クイックポール

所属する組織のデータ活用状況はどの段階にありますか?

NEWSLETTERS

エンタープライズコンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]