Webサイトの脆弱性対策の基本

Webサイトの脆弱性対策の基本

Webサイトの脆弱性対策の基本は、以下の2点です。キーワードは「脆弱性を元から絶つ」です。

1. 脆弱性の無いWebアプリケーションを作成する
2. 脆弱性を修正する

1. 脆弱性の無いWebアプリケーションを作成する

1.1. 開発時に、プログラムに脆弱性を作り込まない

アプリケーションの開発時に、プログラムに脆弱性を作り込まないことが理想であり、重要です。IPAが公開している、以下の資料が参考になります。

• 安全なウェブサイトの作り方
• 安全なSQLの呼び出し方
• セキュア・プログラミング講座

1.2. 発注時に、要求仕様（RFP）に具体的なセキュリティ要件を盛り込む

情報システム部門やシステム開発会社にアプリケーション開発を発注する立場であったのなら、要求仕様（RFP）に具体的なセキュリティ要件を盛り込むことが重要です。JNSA（特定非営利活動法人、日本ネットワークセキュリティ協会）が公開している、以下の資料が参考になります。

• JNSAセキュアシステム開発ガイドライン「Webシステムセキュリティ要求仕様（RFP）」編 β版

2. 脆弱性を修正する

運用開始当初は脆弱性が見当たらなかったWebアプリケーションでも、月日が経つにつれて新たな脅威（攻撃手法）にさらされ、脆弱性が生まれることがあります。この場合の基本的な対応は、脆弱性を修正することです。

しかし、脆弱性の修正は、多くのケースで困難をともないます。例えば、以下のような障壁があります。

• Webアプリケーションを自社で開発したものの、開発者がすでに退職しているなどの理由で、修正方法が分からない
• 商用のWebアプリケーションに新たな脆弱性が見つかったが、修正パッチが提供されるのに時間がかかる。もしくは、パッチ提供の予定が無い
• 修正のためには、多大のコストと時間がかかる

このような場合（アプリケーションの修正が困難な場合）に有効な手段が、WAF（Webアプリケーション・ファイアウォール）の導入です。

IPS（侵入防止システム）ではだめなのか

では、WAFではなくてIPSではだめなのでしょうか。答えは、だめです。IPSの基本技術は、既知の攻撃パターンをシグネチャ化して、テキスト・パターンのマッチングによって攻撃を検知・特定します。しかし、現実には、シグネチャを回避するための攻撃手法が存在します。

例えば、SQLインジェクションで考えてみましょう。もちろん、一般的なシグネチャであれば、前述の"or 1=1"攻撃を防御することができます。さらに、正規表現が使える場合は、"or 1=1"攻撃の、できるだけ多くの変種を検出することが可能です。しかし、それでも、以下の文字列によって、簡単にその防御をすり抜けられてしまいます。

or 'Junpei' = ' Junpei’ 
or ' Junpei ' = ' Jun '+'pei' 

この攻撃に対する、さらなる防御策として、後ろに"="が続く"or"文字を探すようになっているシグネチャがあったとします。しかし、これでも、以下の攻撃によってすり抜けられてしまいます。

or ' Junpei ' LIKE ' Jun%' 
or ' Junpei ' > 'J' 
or 2 > 1

• 参考: SQL インジェクションとシグネチャ回避技法