緊急点検！Webアプリ・セキュリティ（前編）

最新の攻撃手法に適応する

　最新の攻撃手法に適応していくことは，ユーザー企業やSIベンダーの担当者には荷が重い。 自前のテストでは不足する網羅性や最新動向への適応性を補うために，セキュリティの専門家によるセキュリティ監査サービスを適宜活用したい。

　例えば，「セカンドオーダーSQLインジェクション」という攻撃は，自前のテストではテスト項目として挙がりづらい。 この攻撃は，一般的に言われている「SQLインジェクション対策」では防げない特徴がある。

　クラッカは，ユーザーからの入力値をサニタイジングするという，“正しい”とされるSQLインジェクション対策を逆手に取る。 仮にユーザー情報を登録・変更するようなアプリケーションでこの攻撃が成功すれば，図7のように他人のパスワードを自由に書き換えられてしまう。

図７　入力時のサニタイジングやパラメータ化クエリーの採用では防げない 「セカンドオーダーSQLインジェクション」【クリックで拡大】

　一般にSQLインジェクション対策としては，（1）「Prepared Statementなどバインド機構の利用を徹底する」（携帯電話向けサービス事業者），（2）「フレームワークに盛り込んだO-Rマッピング機能を使用する」（大和総研ネットトレードシステム開発部次長増田哲也氏），（3）「ユーザーからの入力値を信頼せず，厳密にサニタイジングする」（ソフトクリエイトプロダクト開発第3グループ長取締役林雅也氏）――という三つのいずれか，あるいは（1）＋（3）か（2）＋（3）の組み合わせが採用されている。

　だが，セカンドオーダーSQLインジェクションは，これらの対策をくぐりぬける。この攻撃を防ぐにはさらに， （4）「変数を使ってSQL文を組み立てているすべての個所でサニタイジングする」（ラックシステムソリューション5部部長倉持浩明ことが欠かせない。 例えば，データベースに格納済みの値を利用する場合や，ファイルに保存した値を利用する場合なども，必ずサニタイジングする。 セキュリティ・ベンダーの監査サービスを使えば，こうした盲点になりがちな脆弱性も指摘してくれると期待される。

ソース・レベルから洗い出す

　予算と時間に余裕があるなら，ソースコードや仕様書の解析に基づくホワイト・ボックス・テストも検討したい。 「思い込みや盲点など，設計者や開発者といった当事者には見つけづらい脆弱性を，第三者の視点で効率よく洗い出せる」（ネットワンシステムズ応用技術本部第1技術部第7チームリーダー大木直人氏）。 ライオンや小田急電鉄（前ページの別掲記事を参照）などが，既に稼働中のシステムに対してホワイト・ボックス・テストを実施済みだ。

　ライオンの場合は2003 年12 月，BtoB向けの販売/調達システムを対象とした。 同社はブラック・ボックス・テストのサービスを年2回ずつ利用していたが，「アプリケーションの脆弱性を本当の意味で洗い出すために，1度は検査する必要があると考えた」（椎名氏）。

　結果，ブラック・ボックス・テストでは見つけられなかった「アクセス権限を持たないページを参照する方法がある」という脆弱性を見つけることができた。 料金は数百万円と見られ，椎名氏は「残念ながら頻繁には利用できない」と苦笑するが，システムの価値によっては実施すべきだろう。

小田急サイトから個人情報が流出
バグでセッションIDを取り違える

　セキュリティ事件は，常にクラッカの攻撃によって起こるものとは限らない。仕様の取り違えやテスト不足といった，自らの責任においても起こり得ることに，十分注意する必要がある。

　小田急電鉄の場合は，「複数ユーザー環境でのテスト網羅率が不足していた」（開発を担当した東芝交通情報システム部部長桑嶋一成氏）ことが原因で，個人情報を流出させてしまった。 2005年10月6日から6日間にわたって特急券予約・購入システム「ロマンスカー＠クラブ」で，他人の個人情報が見えたり，他人に自分の名義で座席を予約・購入されてしまったりというトラブルが起きた。

図Ａ　小田急電鉄は改修時に混入し たバグで個人情報を漏洩
【クリックで拡大】

　直接的な原因は，「ユーザーの体感アクセス速度を向上する目的」（小田急電鉄旅客サービス部設備・システム・制度・審査担当課長眞野大輔氏）で，10月6日未明に改修したプログラムにバグが混入したことだった。 小田急電鉄と東芝は，バグが発生した経緯については「詳しく説明したくない」（眞野氏）と頑なに口を閉ざすが，関係者の話を総合すると，バグそのものは次のようなものだった（図A）。

　バグが含まれていたのは，クライアントの画面に「ログアウト」というリンクを生成するセッション制御プログラムである。 このシステムではセッションIDをURLに格納する仕様だが，ログアウト・リンクに格納するセッションIDをなぜか別のユーザーのセッションIDと取り違えた。

　例えば，ユーザーAとユーザーBがログインしている状態で，ユーザーAのログアウト・リンクにユーザーBのセッションIDを格納してしまった。 この結果，ユーザーAがリンクをクリックすると，ユーザーBとしてログアウトする現象が生じた。

　クライアントとサーバーの双方で，そのままユーザーBのセッションIDを無効化すれば，個人情報の流出は起きなかったはずだ。 だが，このシステムでは仕様上，ログアウト後もURLにセッションIDを引き継ぎ，一定時間は再利用する仕組みを採っていた。 このため，Webブラウザを閉じずに再度ユーザーAがログイン操作したときに，ユーザーBのセッションIDを使いユーザーAとしてログインしてしまった。

　この状態で，ユーザーBが元々は自分のものであったはずのセッションIDを使いシステムを操作すると，ユーザーAの操作として扱われる。 会員情報を確認すると他人（ユーザーA）の個人情報が見えた。



日経システム構築（2005年12月号）
日経システム構築（2005年12月号）より

　上記の記事「緊急点検！ Webアプリ・セキュリティ――多層の防御ラインでシステムを守る」は，『日経システム構築』2005年12月号の特集から掲載したものです。
　『日経システム構築』はセキュリティはもちろんのこと，ITエンジニアが現場で直面するさまざまな問題を解決するために必要な情報を，豊富なユーザー事例をもとに，やさしく掘り下げて提供しています。最新号の主な記事内容やその他のコンテンツについては，こちらのサイトを，年間ご購読のお申し込みはこちらのサイトをご参照ください。
　このほか，不正アクセスや情報漏洩の防止に関して徹底解説した別冊書籍「Webアプリケーションのセキュリティ完全対策」も全国の書店で好評発売中です。ぜひお求めください。

SAFETY JAPAN メール

日経BP社の書籍購入や雑誌の定期購読は、便利な日経BP書店で。オンラインで24時間承っています。