2012年8月10日金曜日

Tポイントツールバーを導入するとSSL通信の履歴までもが盗聴可能になる

twitterなどでTポイントツールバーの利用規約が話題になっています。このエントリでは、Tポイントツールバーを実際に導入して気づいた点を報告します。結論として、当該ツールバーを導入すると、利用者のアクセス履歴(SSL含む)が平文で送信され、盗聴可能な状態になります。

追記(2012/08/10 20:10)
たくさんの方に読んでいただき、ありがとうございます。一部に誤解があるようですが、ツールバーが送信している内容はURLだけで、Cookieやレスポンスまでも送信しているわけではありません。URLを送信するだけでも、以下に示す危険性があるということです。
追記終わり

追記(2012/08/13 23:50)
ポイントツールバーにバージョンアップがあり、WEB閲覧履歴の送信がSSL通信に変更されました。従って、WEB閲覧履歴が盗聴可能な状況は回避されました。本日22:50頃確認しました。
追記終わり

導入

Tポイントツールバーの導入は以下の手順です。
  1. T-IDの登録(アカウント作成)
  2. ツールバーのダウンロード
  3. ツールバーの導入
詳しくはサイトのインストール手順をご覧下さい。私は、WindowsXP SP3とInternet Explorer 8の組み合わせで検証しました。インストールの途中で ieframe.dll が見つからないというエラー(下図)でインストーラーが停止しましたが、再度実行するとインストールできました。


使ってみる

それでは、さっそくTポイントツールバーを使ってみましょう。IE起動時の画面は以下となります。



ツールバーの左端にTポイントカードのロゴがあり、その右に検索キーワードの入力欄があります。Tポイントツールバーは、Tサイトにログインした状態で使用する想定のようです。ログインしてから、入力欄に「育毛剤」と入力して検索してみます。



検索結果のドメインは、tsearch.tsite.jp ですし、T-IDでログインした状態なので、利用者のキーワード収集は、ツールバーではなく、このサイトの側で行っているのかもしれませんね。画面の検索ボタンの右に「Powered by Yahoo!」とあるので、検索エンジンはYahoo!のOEMなのでしょう。キーワード検索広告もYahoo!のもののようです。


WEB閲覧履歴の送信

ところで、Tポイントツールバーの利用規約には以下のように書かれています。
第6条(履歴の収集)

1. 利用者は、当社が提供した本ツールバーをインストールした利用者端末による全てのWEB閲覧履歴(閲覧したURL、検索キーワード、ファイル名及びアクセス日時等の履歴情報をいい、以下「WEB閲覧履歴」といいます)が当社により取得されることをあらかじめ承諾するものとします。
実際のところツールバーがWEB閲覧履歴を収集しているかを確認してみましょう。IEで、https://www.hash-c.co.jp/?PHPSESSID=ABCDEFGHIJK0123456789 を閲覧してみます。すると、以下のHTTPリクエストがPOSTされます。文字の一部をマスク表示して、読みやすいように改行を追加しています。xxxとなっているのは、謎の3バイトです。
POST /service/track.cgi?y=-8588570930699932058 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727)
Content-Type: application/x-www-form-urlencoded
Host: log.opt.ne.jp
Content-Length: 183
Expect: 100-continue
Connection: Keep-Alive

xxx&
mid=4A7DZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ50170&
tlsc_l=NVEpO4ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZU_s&
u=https%3a%2f%2fwww.hash-c.co.jp%2f%3fPHPSESSID%3dABCDEFGHIJK0123456789
log.opt.ne.jpというホストに、閲覧履歴が平文で(HTTPSではなくHTTPで)送信されています。
これは問題がありますね。閲覧履歴がカルチュア・コンビニエンス・クラブ株式会社によって取得されることは利用規約に書いてありますが、「閲覧履歴が平文送信されるので、カルチュア・コンビニエンス・クラブ株式会社以外のものに盗聴により取得されるかもしれない」ことは利用規約には書かれていないからです。
実はTカードツールバーの利用規約には以下のようにも書かれています。
第10条(免責事項)
1.利用者は、自己の判断と責任の下で、本ツールバーを利用するものとします。本ツールバーを利用したこと又は利用できなかったこと若しくは第3条に基づくTポイントの付与が受けられなかったことにより、利用者に損害、その他の不利益が生じたとしても、当社は一切責任を負いません。
一般的に利用規約にはこの種の免責事項を書くものではありますが、免責を記しているからと言って利用者の閲覧履歴を粗末に扱ってよいということにはならないと思います。それに、FAQのページには以下のように書かれています。


上記は、データが漏洩しないとは書いていませんが、「テスト済みですので、ご安心下さい」と書いてあれば、多くの利用者は、カルチュア・コンビニエンス・クラブという大きな会社が運営していることもあって、データの安全性にも配慮してあるのだろうと暗黙に了解するのではないでしょうか。


URLの平文送信の影響

利用者の閲覧履歴であるURLを平文送信することにより、HTTPSアクセス時のURLが盗聴される可能性が出て来ます。この影響について考えます。
まず、URLにセッションIDを埋め込んであるサイト(携帯電話向けサイトでは一般的な方式ですが、他のサイトにも存在します)では、セッションIDが盗聴されることにより、成りすましのリスクがあります。
また、セッションIDでなくても、URLに秘密情報を埋め込むことによりアクセス制御をする場合があります。また、画像ファイルやPDFについても、URLを秘密にすることによりアクセス制御をしているサイトがあります。とあるネットバンクの取引明細のPDFは、URLに乱数が埋め込まれていますが、URLを知っているとパスワードなしでアクセスできてしまいます。 このようなサイトについても、URLを盗聴されることにより、成りすましやデータの窃取の危険性が生じます。
これら、成りすまし等以外にも、どのページをアクセスしたかを第三者に知られたくないという状況もあるでしょう。Tポイントツールバーを導入すると、Webのセキュリティ強度は強制的に低下します。それは、利用規約などには書いていないことです。

利用者固有番号


追記(2012/08/10 20:25)
以下のパラグラフで、「固有の利用番号」を利用者にひもつくものと解釈しておりましたが、そう解釈する必然性はないことに気がつきました。むしろ、端末の結びついた情報と解釈した方が日本語としては自然かもしれません。しかし、端末にひもつく「番号」は機能の実現に不可欠とは言えないと考えます。一方、利用者にひもつく情報は、閲覧履歴を収集するという仕様を実現するためには不可欠なもので、それを番号と呼ぶか、ユーザIDと呼ぶかということに過ぎず、以下の指摘はやや的外れでした。指摘している脅威が存在することには変わりませんが、その原因は、(1)Web閲覧履歴を収集すること自体が問題、(2)仮に閲覧履歴を収集するなら暗号化して送信するべき、ということです。
追記終わり

Tポイントツールバーの利用規約には以下のように「利用番号」についての記載があります。
第6条(履歴の収集)
【略】
3. 本ツールバーには固有の利用番号が登録されています。当該利用番号は、本ツールバーが機能するために必要な情報であり、無効化あるいは削除することはできません。
「固有の利用番号」というと嫌な感じですが、先ほどのPOSTデータの中に、この「利用番号」は含まれるのでしょうか。先のPOSTデータには、mid および tlsc_l と言うパラメータがあり、ログイン・ログアウトしてもこの値は変わりません。これらのいち、私は tlsc_l の方が「固有の利用番号」のような気がしました。その根拠は、以下の通りです。
  • ツールバーインストール直後のT-SITEにログイン前の状態では、tlsc_lは空である
  • T-SITEのWebアプリケーションの発行するCookieにも tlsc_l というCookieがあり、TポイントツールバーのPOSTする tlsc_l と値が同じ
  • 端末を変えても、T-IDが同じなら tlsc_l は同じ。midの方は端末毎に変わる
  • Cookieのtlsc_lの方も、ログイン毎に値は変化しない

「固有の利用番号」が、TポイントツールバーのPOSTデータについていることから、以下のような困ったことが起こり得ます。


利用者固有番号の悪影響

たとえば、PROXYサーバーを経由でアクセスしている場合、平文の(HTTPSでない)リクエストはPROXYサーバー上で監視することができます。一方、HTTPSのリクエストについては、アクセスしているホスト名まではわかりますが、URLは分かりません。
しかし、TポイントツールバーのPOST値を監視できる立場の人は、「固有の利用番号」がついていることにより、特定ユーザの挙動把握が容易になります。
たとえば、とあるユーザが、https://twitter.com/#!/ockeghem/HiddenList を頻繁にアクセスしているとします。これはtwitterのリストのURLですが、このリストが非公開となっている場合、このユーザは、twitter IDがockeghem(すなわち私)であると推測できます。
すると、このユーザと同じ「固有の利用番号」がついてるWEB閲覧履歴は、すべて私のアクセスできることが分かってしまいます。

Tポイントツールバーの利用者にとって、WEB閲覧履歴がCCCに伝わることは利用規約上で(建前上は)許諾しています。しかし、第三者にもWEB閲覧履歴が漏れることまでは許諾していません。それが起こってしまう原因は、Tポイントツールバーの以下の設計上の問題に起因しています。
  • WEB閲覧履歴の平文送信(根本原因)
  • 「固有の利用番号」の存在(攻撃を容易にする要因)

まとめ

Tポイントツールバーについて紹介しました。
Tポイントツールバーは、利用者のアクセス履歴(URL)をログ収集サーバーに送信しますが、(1)平文通信である、(2)固有の利用番号がつく、ことがセキュリティ上の問題となります。

とくに、利用者のアクセス履歴を平文で送信することにより、Webサイトのセキュリティ強度を勝手に下げてしまう点は致命的であると考えます。これが許容できる利用者は、ほとんどいないでしょう。カルチュア・コンビニエンス・クラブ株式会社は、至急、以下のいずれかの対処をすべきです。

  • 利用規約に上記セキュリティ上のリスクを明記する
  • WEB閲覧履歴の送信をSSL通信に変更する
  • Tポイントツールバーの提供を停止し、既存ユーザには強制アップデートにて履歴送信機能を止める。log.opt.ne.jpも停止する

※前2項を一応考えましたが、どう考えてもダメなので、当エントリ公開時に削除しました。

2012年7月6日金曜日

PHPの入門書を書くことになりました&レビュアー募集のお知らせ

PHPの入門書をソフトバンククリエイティブさん出すことになりました。かねがね、PHPの入門書がよろしくないという問題意識を持ち、かつ色々な場でお話ししておりましたが、またしても「言い出しっぺの法則」が発動して、自分で書くことになりました。
PHPの入門書を(たぶん)10冊以上読んで(あるいは眺めて)、以下のような感触を持っています。
  • ものすごく初歩的な本は悪くないが、行き着くゴールが極めて限定される
  • SQLなどまで行き着く入門書は、後述する欠点を持つ傾向がある
  • 中級者・上級者向けについては、良いものが出て来た
PHP入門書の欠点というのは以下のようなものです。私の読んだPHP入門書は、次のいずれかに該当します。
  • 執筆者のスキルが低いために説明やサンプルの品質が低い
  • 執筆者のスキルは高いはずだが、説明のスキルが低く、不正確
  • 執筆者のスキルが高く説明も正確だが、初心者には難しく入門書でなくなってしまっている
ということから、上記の欠点のない(許容できる程度に少ない)入門書が書けないか考えました。
セキュリティについては前面に出さず、ふつーに、当然のように安全なものができあがることを目指しております。

現時点の構想は下記の通りです。変更の可能性があります。ノンプログラマ向けの本ではなく、開発者の卵向けという位置づけです。

対象読者

  • プログラマ・SE一年生でこれからPHPを学習する人
  • なにかプログラミング言語の経験があるとなお可
  • HTMLの基礎を知っていて簡単なHTMLを書けるとなお可(ただしHTMLの基礎知識は説明する)

学習環境

学習環境は以下を考えています。変更の可能性があります。
  • PC / Macに対応
  • VMware / Virtual Box ※XAMPPにするかもしれません(検討中)
  • Ubuntu + PHP + MySQL ※XAMPPにするかもしれません(検討中)
  • NetBeansによる開発・デバッグ環境
  • テストについても言及するかも
  • デプロイについても言及するかも

目標

本書のゴールは以下を考えています。変更の可能性があります。
  • 簡単なWebアプリがPHPにより作れる
  • PHPの基本をマスターする
  • 関数やクラスの使い方をマスターする
  • メールフォームが作れる
  • SQLを用いた検索フォームが作れる
  • 会員管理、認証のあるアプリケーションが作れる
  • NetBeansによるデバッグの仕方を習得する
  • より高度な技術を習得するための土台ができる
  • セキュリティ的な問題はなくす
    • ただし、あまりセキュリティの原理的なところは踏み込まず、「こうするとよい」というハウツーにとどめる
    • 要は「安全なWebアプリケーションの前に読む本」という位置づけにもなる

レビュアー募集

現状のPHP入門書に不満があるとして、自分なら十分なものが書ける根拠があるかというと、なかなか難しいと感じています。このため、今回も、レビュアーを公募して、皆様のお力をお借りしながら、少しでも良いものにしたいと希望しております。レビュアーに期待していることは以下のようなことです。
  • 初心者目線で、読んでわかりにくい箇所の指摘
  • PHPのエキスパートとしての指摘
  • 文章表現に対する指摘
  • 正確でない用語の指摘
  • 誤字・脱字・誤変換などいわゆるTYPOの指摘
  • その他、説明や構成に対するアドバイスなど
とくに初心者目線での指摘を頂ける方を募集します。自薦だけでなく、部下・教え子・後輩の推薦も歓迎します。ただし、応募はご本人からお願い致します。
レビュアーには「あの○○さん」のようなすごい方もおられますが、その中でも臆せずに「自分には分かりにくい」と言えるガッツのある人を歓迎(大歓迎)します。

当方からの謝礼としては以下を予定しています
  • 本の中での謝辞(本名またはハンドル)
  • 献本(紙の本と電子版)
  • 打ち上げへのご招待(会費は当方が負担します)
以下の条件を承諾していただけることが前提です。
  • いただいた指摘やアドバイスは真剣に検討致しますが、採用するとは限りません
  • ご意見を採用する・しない、採用後の表現は、最終的には徳丸が決定します
  • 具体的な修正案を盛り込んだ場合、著作権は徳丸に帰属します
  • 本の内容について秘密保持をしていただきます(常識的な範囲で)
人数としては、十数名程度と思っています。

レビュアーをやってみたいという方は、以下のいずれかの都合の良い方法で徳丸までご連絡ください。応募期間は、7月13日金曜日までとします。
  • phpbook @ tokumaru.org へのメール(@を半角にしてください)
  • twitter, facebookでのDM
連絡いただく内容としては、基本的には以下の内容です。
  • お名前(本名 または ハンドルネーム)
  • メールアドレス
  • 自己紹介(簡単で結構です)
  • アピール(こんな指摘がしたい and/or できる)
  • ブログなどのURL
徳丸が面識のない方については、基本的にブログなどでアウトプットを出している方から選考させていただきたいと考えています。これは、判断基準として既存のアウトプットを見させていただくという意味です。高度な内容である必要はまったくありません。逆に、既に面識がある方(twitter、facebookなども含みます)の場合は、単に「レビュアー立候補します」のみで結構です。

選考結果については、「レビュアー選考が終わり当選者の方にメールで通知しました」という形にしようと思っています。選に漏れた方は、別に「劣っている」という判断ではありませんので、恨まないでくださいね。

それでは、よろしくお願い致します。

PS.
今朝、某社のJavaScript勉強会に参加させていただきました。ツッコミどころ満載のテキストに各位がツッコムのを最初は自分も笑っていたのですが、段々顔が引きつってくるのを感じました。他人事ではありません。入門書を書くのは大変ですね。

追記(2012/7/10))

大変多くの募集をいただきありがとうございます。現時点では、「他の言語は経験があるがPHPは知らない」という方の応募をたくさんいただいております。もちろんそのような方も歓迎ですが、「他の言語も含めてプロクラムは書けない」という方を優先枠として選定させていただきたいと思っております。
プログラムが書けるようになるまでの過程では、多くの困難があると予想されますので、疑問点等については徳丸ができる限りフォローいたします。場合によっては他のレビュアーの方もフォローしてくれるかも知れません。いわば「プログラミング道場」のようなものですね。
以下の条件に当てはまる方を歓迎いたします。
  1. 現時点ではプログラムが書けない(HTMLは書けてもよい)
  2. プログラミングができるようになりたいと強く思っている
  3. 約半年掛けてプログラミングを習得する時間的猶予がある
という方の応募をお待ちしています。また、これ以外の募集についても引き続き行います。

追記(2012/7/18))

昨日選考を終わり、当選の方にはメールで連絡差し上げました。たくさんのご応募ありがとうございました。

2012年6月26日火曜日

COOKPADの「伏せ字にせず入力」ボタンは素晴らしい

@tokuhiromから教えてもらったのですが、COOKPADのスマートフォン向けWebサイトのログインページには、パスワードを「伏せ字にせず入力」するボタンがついているのですね。

さっそく見てみましょう。まずはログイン画面です。パスワード欄の下側に、「伏せ字にせず入力」ボタンが見えます。


まずはこのままでメールアドレスとパスワードを入力してみましょう。デフォルトでは、パスワードは伏せ字になりますね。


ここで「伏せ字にせず入力」のボタンを押すと、入力中のパスワードが表示されます。メールアドレスとパスワードは例ですので、まねしないように。


「元に戻す」ボタンを押すと、伏せ字に戻ります。

僕はこれを知って興奮しました。なぜなら、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」には以下のように書いたからです(P337~P338)。
パスワード入力欄のマスク表示は、現在の常識的なガイドラインですが、実は筆者自身は疑問を持っています。パスワード入力欄をマスク表示にすると、記号や大文字・小文字交じりの安全なパスワードを入力しにくくなるので、利用者は簡単な(危険な)パスワードを好むようになり、かえって安全性を阻害するリスクの方が大きいのではないかというのがその理由です。
【中略】
パスワード認証の最大の脅威は、インターネット越しの総当たり的な攻撃であり、その対抗策は良質なパスワードを設定することに尽きます。そのため、今後は「パスワードの文字を表示する」チェックボックスを備えるWebサイトが増えるかもしれませんね。ただし、ブラウザのパスワードの自動補完機能により画面表示の初期状態からパスワードが設定されている場合があるので、他人が見ている場でいきなりパスワードが表示されると困ります。このため、「パスワードの文字を表示する」チェックボックスの初期状態はオフになっていることが条件です。
こう書いたものの、同書執筆時には、現物のWebサイトの例を示すことができませんでした(良く探せばあったかもしれません)。COOKPADのスマートフォン向けサイトは、私の予言(?)を完全に満たしていますね。

パスワードの取り扱いについては、「定期的に変更するべきか」、「どう保存すればよいのか」、「入力中のパスワードは表示するべきか」という3大論争(?)がありますが、COOKPADのこの実装は、「パスワードを見せる」先駆的な取り組みと言えそうです。

もっとも、ケータイ(フィーチャーフォン)向けのサイトでは、パスワードを表示させる例は珍しくありませんでした。これは、テンキーでパスワードを入力するのが難しい機種があったからだと思います。いきおい、モバイルバンキングでもパスワード代わりに4桁暗証番号というサイトが珍しくないわけですが、これは本当に本末転倒だと思います。良質なパスワードを利用者につけてもらうことこそが第一優先であって、その次に、入力中のパスワードをのぞき見されない工夫をすべきと考えます。

というわけで、COOKPADの取り組みは素晴らしいと感じました。

追記(2012/06/26 19:10)

つい興奮して手放しの絶賛をしましたが、注意すべき点もあります。この点についてご指摘をいただきました
パスワードフィールドを伏字にしない話、理念としては頷けるのだが、現状で徳丸さんの提案に従ってサイト側で実装するのは考えものかもしれない。問題は2種類ある。ひとつはアクセシビリティ、ひとつは特定環境におけるパスワード漏洩リスクの増大。さらに実装がばらつくことによる実効性の低下も懸念される。やはりこの手の基本的な UI の改良はブラウザ側で行われることが望ましい。【後略】続きを読む
詳しくはkokuboさんのエントリをお読みいただくとして、このような試みは始まったばかりですので、本当にどう実装するのがよいのか、見落としているリスクはないのかという検討が必要だと思います。ご指摘ありがとうございました。

[PR]
安全なWebアプリケーションの作り方DRMフリーのPDFによる電子版もあります。
[PR]
7月5日インフィニテック社のセミナーで基調講演します

2012年6月19日火曜日

IPAからAndroidアプリの脆弱性に関するレポート出ました

「Androidアプリを作っている(作ってもらっている)けど、脆弱性が心配」という声はtwitterでも目にすることがあります。そして、「『安全なウェブサイトの作り方のAndroidアプリ版』があったらいいのに」という希望を目にしたこともあります。
6月13日にIPAから公表された「IPA テクニカルウォッチ『Androidアプリの脆弱性』に関するレポート」は、この『安全なウェブサイトの作り方のAndroidアプリ版』に相当する位置づけのドキュメントです。なぜそう思うかというと、以下の性格が『安全なウェブサイトの作り方』と共通するからです。
  • Androidアプリの基本的な問題に絞っている
  • 届出の多い脆弱性にフォーカスしている
以下、もう少し詳しく紹介します。

Androidアプリの脆弱性とは何か

同レポートでは、Androidアプリの脆弱性を以下のように定義しています(同書P3)。
■ 「脆弱性」
Android OSに備わっている仕組みを”Androidアプリが適切に使用していない”場合、他のアプリが所有しているデータに不正アクセスしたり、他のアプリの権限を不正に使用したりするセキュリティ上の問題が発生する。本書では、このようなセキュリティ上の問題をAndroidアプリにおける脆弱性と位置づけている。
この不正なことを誰が(何が)するかというと、不正なアプリであるわけで、これも以下のように定義されています。
■ 「不正なアプリ」
本書では、他のAndroidアプリの脆弱性を悪用し、他アプリのデータにアクセスしたり、他アプリの権限を不正に使用したりするAndroidアプリを指す。
ということで、要は、「アプリケーションが、Androidに備わっている仕組みを適切に使用していないことが原因で、不正なアプリ(マルウェア)が、アプリのデータに不正にアクセスできる、あるいはアプリの権限を不正に使用できる」状態をAndroidアプリの脆弱性として位置づけています。

では、Androidアプリには他のタイプの脆弱性はないかというと、必ずしもそうではないと思います。例えば、AndroidアプリがSQLiteを使っていて、そこにSQLインジェクション脆弱性がある場合、アプリの脆弱性ですが、「Androidの仕組みを適切に使用していない」ことが原因とは言えません。
このため、同書はAndroidアプリ「固有の」脆弱性にフォーカスして解説しているととらえればよいと思います。その結果、同書は表紙を含めても24ページと大変コンパクトにまとまっています。この薄さは読者にはありがたいですね。

■『Androidの仕組み』とは

Androidに備わっている仕組みを適切に使用しないことで脆弱性が生まれるわけですから、脆弱なAndroidアプリを作ってしまう開発者は、Androidの仕組みを正しく理解していないと推測されます。このため、同書は、2章をAndroidの仕組みの解説にあてています。その中から、「図2-1 Androidの仕組みの動作イメージ」という図を引用します。


「おいおい、これはAndroidの基本そのものではないか。そんなものは知っている」と思われた読者が多いかもしれませんが、現実に、その基本がちゃんと分かっていないために多くの脆弱性が生まれているわけで、分かっているつもりの方でも、もう一度同書でおさらいをしておくと良いのではないでしょうか。

■届出の多い脆弱性

同書の3章は、「IPAに報告されたAndroidアプリの脆弱性」ということで、IPAに届出のあったAndroidアプリの脆弱性42件のうち、31件が「アクセス制限の不備」と分析し、そのうち21件がコンポーネントのアクセス制限の不備、10件がファイルのアクセス制限の不備となっています。ということから、同書は、以下のように分析しています。
これらの設定は、Androidにおいては基本的な設定である。しかし、多くの届出があったという事実から、このAndroid特有の設定内容が開発者に周知できておらず、結果的に、アクセス制限の不備の脆弱性を作り込んでしまっているのではないかとIPAでは推測する。

■脆弱性例の紹介

同書の4章はIPAに届出のあった脆弱性の中から、典型的なものを5種類紹介しています。このような脆弱情報の現物(アプリ名などは伏せてありますが)は中々目にする機会がないので、とても貴重で興味深い内容です。以下に目次を紹介します。
4.1. ファイルのアクセス制限不備の脆弱性
(1) SD カードに機微な情報を保存
(2) ファイルが不正なアプリからアクセス可能
4.2. コンポーネントのアクセス制限不備の脆弱性
(1) 不正なアプリに機能を悪用される
(2) ファイルが不正なアプリからアクセス可能
4.3. ログ出力に関する情報漏えい
(1) 機微な情報をログに出力
4.1と4.2の両方に「(2) ファイルが不正なアプリからアクセス可能」がありますが、4.1はファイルのアクセス許可の問題に起因するもの、4.2はコンテントプロバイダの設定不備に起因する問題です。特に4.2節は、Androidの特徴がよく出ていて興味深い内容だと思います。

■まとめ

「IPA テクニカルウォッチ『Androidアプリの脆弱性』に関するレポート」について紹介しました。既にAndroidアプリの脆弱性については、「Android Security 安全なアプリケーションを作成するために」やJSSECの『Android アプリのセキュア設計・セキュアコーディングガイド』があり、いずれも素晴らしい内容だと思いますが、どちらも「分厚い」もので、Androidアプリのセキュリティ入門としては、少しとっつきにくいという人もおられたと思います。
一方、IPAの「『Androidアプリの脆弱性』に関するレポート」の方は、24ページという薄さと、基本にフォーカスして説明してあるという点で、全てのAndroidアプリ開発者およびAndroidアプリを発注する立場の方に読んでいただきたい内容です。

なお、徳丸はIPA非常勤職員として同書のレビューに参加いたしました。しかし、このエントリは個人の見解として書いているものであり、IPAとしての見解ではありません。

2012年6月14日木曜日

さくらDNSにサブドメインハイジャックを許す脆弱性

さくらインターネット株式会社のDNSサービスにセキュリティ上の問題がありましたが、改修されましたので報告します。
DNSサービスへのドメイン登録時における不具合について 
障害内容 :
当社の提供するネームサーバサービスにおいて、既に登録されているドメインのサブドメインが、他の会員IDの方に登録できる状態となっておりました。この障害により、悪意のある第三者がドメインの一部を乗っとれる脆弱性につながる危険性がありました。
本問題につきましては現在は解消されており、全ての登録について不正がないかの調査を行っております。
この問題の発見者は前野年紀氏で、私はさくらインターネット株式会社に問題を通告し、改修を促すための連絡などでお手伝いをしました。
(12:00追記)なお、この脆弱性が混入したのは6月8日頃で、さくらインターネットは6月11日から修正を開始し、昨日(6月13日)には改修されましたので迅速な対応であったと考えます(追記終わり)。

問題の概要

さくらのレンタルDNSサーバーにおいて、他人(ドメイン名の保有者でない人)が勝手にサブドメインを登録できることが問題でした。 たとえば、架空の会社エグザンプル株式会社がホームページwww.example.jpを運営しており、ドメイン名example.jpをさくらDNSで運用しているとします。この状況で、第三者がexample.jpのサブドメインwww2.example.jpのゾーンを追加し、www2.example.jpのAレコード(IPアドレスの指定)を登録できました。この結果、第三者がwww2.example.jpというサイトを公開できることになります。

勝手にDNSサーバーを立てて他人のサブドメインを登録できることは問題ない

ここからは、問題点を説明するために、本来できてよいこと、できてはまずいことを順に説明します。 まず、第三者が独自のDNSサーバーを立てて、そこに勝手に別人のドメイン名を登録することはできてしまいます。私が運営するDNSサーバーに、google.comやamazon.comやapple.comなどを勝手に設定することできるし、問題にもならないということです。
それが問題にならない理由は、この勝手なDNSサーバーは上位DNSサーバーからgoogle.comなどのドメイン名を委譲されていないので、どこからも参照されないからです。

権威サーバーと同じサーバー上に、他人がサブドメインを登録できることが問題

次に、話を進めるために、以下のシナリオを考えます。
私がもつドメイン名 tokumaru.org の適当な預け先がなく、知り合いのいるエグザンプル株式会社に「御社のDNSサーバーを貸して下さい。そして、tokumaru.orgを設定させて下さい」と頼んだとします。この設定自体は問題がなく、交渉次第では貸してくれるでしょう。
ところが、私が悪い奴で、tokumaru.orgを追加するついでに、www2.example.jpのゾーンも追加したとします。example.jpのゾーンはいじれないので、www2.example.jpは、example.jpから委譲されてはいません。しかし、example.jpとwww2.example.jpは同じDNSサーバー上にあるので、外部からwww2.example.jpを問い合わせると、このDNSサーバーに登録された内容を応答してしまいます。これが問題です。
すなわち、さくらDNSの問題は、「ちょっとDNSサーバー貸して下さい」と頼みながら、そのDNSサーバーに元々設定されているドメイン名のサブドメインが登録できてしまう(チェックされない)ことが問題です。

実験

これだけだと分かりにくいと思うので、実験をしました。 私は元々tokumaru.orgをさくらDNSで運用していました。その状態で、前野年紀氏が徳丸の許可の元、私とは別アカウントでサブドメインqmail.tokumaru.orgの登録を試み、成功しました(この設定は現在はできません)。本稿執筆時点で、qmail.tokumaru.orgは参照可能です。


このドメイン名を外部から問い合わせると以下のような流れになります。

# ネット利用者が qmail.tokumaru.org にアクセスしようとする
# ブラウザがDNSキャッシュサーバーに qmail.tokumaru.org を問い合わせる
# DNSキャッシュサーバーはルートDNSサーバーに qmail.tokumaru.org を問い合わせる

$ dig +norecurse qmail.tokumaru.org @198.41.0.4
;; AUTHORITY SECTION:
org.                    172800  IN      NS      a0.org.afilias-nst.info.
;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 172800 IN      A       199.19.56.1

# ルートDNSサーバーは、qmail.tokumaru.org は知らないけど
# orgドメインの権威サーバーなら知っているよと、a0.org.afilias-nst.info などを返す
# DNSキャッシュサーバーは、a0.org.afilias-nst.infoにqmail.tokumaru.orgを問い合わせる

$ dig +norecurse qmail.tokumaru.org @199.19.56.1
;; AUTHORITY SECTION:
tokumaru.org.           86400   IN      NS      ns1.dns.ne.jp.

# a0.org.afilias-nst.infoは、tokumaru.orgの権威サーバーはns1.dns.ne.jp(さくらDNS)だよと返す
# DNSキャッシュサーバーはns1.dns.ne.jpのIPアドレスを知らないので、あらためてルートDNSサーバーにns1.dns.ne.jpを問い合わせる

$ dig +norecurse ns1.dns.ne.jp @198.41.0.4
;; AUTHORITY SECTION:
jp.                     172800  IN      NS      a.dns.jp.
;; ADDITIONAL SECTION:
a.dns.jp.               172800  IN      A       203.119.1.1

# ルートDNSサーバーは、jpドメインの権威サーバーがa.dns.jpなどであると返す
# DNSキャッシュサーバーは、ns1.dns.ne.jpをa.dns.jpに問い合わせる

$ dig +norecurse ns1.dns.ne.jp @203.119.1.1
;; AUTHORITY SECTION:
dns.ne.jp.              86400   IN      NS      ns1.dns.ne.jp.
;; ADDITIONAL SECTION:
ns1.dns.ne.jp.          86400   IN      A       210.188.224.9

# ns1.dns.ne.jpのIPアドレスが返ってくる
# DNSキャッシュサーバーは、ns1.dns.ne.jpにqmail.tokumaru.orgを問い合わせる

$ dig +norecurse qmail.tokumaru.org @210.188.224.9
;; ANSWER SECTION:
qmail.tokumaru.org.     3600    IN      A       14.192.44.5

# ns1.dns.ne.jpは、(前野氏が設定した)qmail.tokumaru.orgのIPアドレスを返す
tokumaru.orgの権威サーバーをさくらDNS(ns1.dns.ne.jp)に設定したのは徳丸ですが、その状態で前野氏が、さくらDNSにqmail.tokumaru.orgゾーンを勝手に(実際には徳丸の承認の元)設定したために、結果として qmail.tokumaru.orgを前野氏が有効に設定できたことになります。

影響

この問題の直接の影響は、サブドメインのゾーンを勝手に登録され、AレコードやMXレコードなどを自由に登録されてしまうことですが、その結果として、以下のような影響が考えられます。

自ドメインでのクッキーを勝手にセットさせられる
先ほどのqmail.tokumaru.org上のコンテンツで、やろうと思えば、domain=tokumaru.orgのクッキーをセットすることができます。通常、クッキーは第三者から勝手にセットされることはないので、アプリケーションのクッキー利用方法によっては影響を受ける場合があります。
具体的には、以下の場合に影響を受けます。
  • セッション・フィクセイション脆弱性がある場合
  • クッキーに意味のある文字列を入れている場合
いずれも好まし良くない実装ですが、クッキーを勝手に改変されることはないという想定に依存しているアプリケーションは、潜在的な問題が顕在化します。

フィッシングに悪用される
攻撃者が勝手にwww2.example.jpを設定して独自のコンテンツを作成した場合、フィッシングサイトに悪用することが考えられます。多くのフィッシングサイトは、あきらかに不自然なURL上にあるので、そこが見分けるポイントの1つになりますが、本物のドメイン名のサブドメイン上にフィッシングサイトがあると、だまされる人が増えると考えられます。

成りすましメールアドレスに悪用される
メールアドレスのドメイン名として、mx.example.jpやmail.example.jpなどのサブドメインを使っている企業は珍しくありません。このため、mx.example.jpを勝手に登録して、このドメインのメールアドレスから、偽のメールを出すという悪用が考えられます。やはり本物のドメイン名を使っていることから、「メールアドレスは今後 xxx@mx.exmaple.jpになります」と書いてあれば、だまされる人はかなり多いと予想されます。
通常、送信元のアドレスを偽装することは容易ですが、その場合返信を受け取ることはできません。しかし、サブドメインを悪用すると、返信メールを受け取ることができるので、秘密情報の聞き出しなどにも悪用可能です。

まとめ

さくらDNSの「サブドメインハイジャック」の脆弱性について報告しました。
ドメイン名はインターネットの信頼の基幹となるサービスですので、サブドメインといえども乗っ取られることは極めて危険と考えられます。私自身、さくらDNSの利用者でしたので、他人事ではありません。とりあえず、さくらDNSで運用していたhash-c.co.jpドメインは引っ越しました。tokumaru.orgも時期を見て引っ越そうと思っていますが、この記事のサンプルになっているのでとりあえずそのままにしています。
Webサイトを運営する個人や中小企業にとって、安全なDNSサーバーの確保は頭の痛い問題です。さくらDNSに引っ越す前は、お名前.comのレンタルDNSを使っていましたが、以前長時間サービス停止するというトラブルがあり、私も被害にあいました。
さくら以外のレンタルDNSサーバーを利用している方は、サービス提供元に対して、この種の問題がないか確認するとよいでしょう。

2012年5月7日月曜日

CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823)

CGI環境でPHPを動作させているサイトには、リモートからスクリプト実行を許してしまう脆弱性があります。php.netから提供されている修正リリース(PHP 5.3.12 / PHP 5.4.2)は不完全なため、該当するサイトは至急回避策を導入することを推奨します。

概要

CGIの仕様として、クエリ文字列に等号を含めない場合は、クエリ文字列がCGIスクリプトのコマンドライン引数として指定されます。
例えば、http://example.jp/test.cgi?foo+bar+bazという呼び出しに対しては、test.cgiは以下のコマンドラインで呼び出されます。
test.cgi foo bar baz
この仕様を悪用して、CGI版のPHPにコマンドライン引数としてPHPのオプションを指定できます。例えば、http://example.jp/test.php?-s というリクエストは、-sオプション(スクリプトソースを表示)と解釈され、PHPスクリプトを実行する代わりに、ソースを表示します(下図)。


これはPHPの脆弱性CVE-2012-1823と識別されています。

実証例

CVE-2012-1823の影響はスクリプトソースの表示だけではありません。PHPのオプションを組み合わせることにより、外部から任意のスクリプト実行が可能となります。具体的には、-dオプションを用いて、php.iniのディレクティブを外部から指定できます。metasploitminute.comで紹介されていたExploitを元に、攻撃例を紹介します。以下の2つのphp.iniディレクティブを指定します。
allow_url_include=On
auto_prepend_file=php://input
最初のディレクティブは、includeするファイルをURL指定でリモートから読み出すことを許可するものです。2番目のディレクティブは、PHP実行に先立ち、スクリプトをincludeしておくものですが、ファイル名としてphp://inputを指定しているため、POSTパラメータとして送信した内容をPHPスクリプトとして実行します。両者の組み合わせにより、外部から指定したスクリプトを実行することができます。
BurpSuiteのrepeater機能を用いて上記Exploitを実行した例を以下に示します。


readfile('/etc/passwd');により、/etc/passwdファイルが表示されています。また、X-Powered-Byヘッダから分かるように、上記はPHP5.4.2で実行されており、改修が不完全であることが分かります。

影響

外部からスクリプト実行が可能であることから、機密性・完全性・可用性の全てで大きな影響があります。影響を受けるサイト(下記)は至急の対策を推奨します。

影響を受けるサイト

当脆弱性の影響は、PHPをCGIとして実行しているサイトに限られます。
ApacheモジュールやFastCGIとしてPHPを実行しているサイトには影響ありません。

回避策

当脆弱性の対策としては、ApacheモジュールまたはFastCGIへの移行を推奨します。

どうしてもCGIのままにしなければならない場合は、php-cgiを呼び出すラッパー(/cgi-bin/php-wrapper)を以下のように記述します。実行権限を付与してください。php-cgiにはコマンドライン引数を渡さないところがポイントです。
#!/bin/sh
exec /usr/local/bin/php-cgi
PHPの設定を以下のように変更します。/cgi-bin/ディレクトリにphp-cgi(CGI版PHP)がコピーしてある場合は削除してください。
AddHandler application/x-httpd-php5 .php
Action application/x-httpd-php5 /cgi-bin/php-wrapper
すると、php-cgiにパラメータが渡されなくなることから、CVE-2012-1823の影響を回避することができます。php-cgiにコマンドライン引数を渡さなくてもPHPの実行に支障ありません。

参考


注記

当脆弱性は極めて影響が大きい反面、影響を受けるサイトは限られます。
当脆弱性が判明した時期が、日本の連休中にあたっていたため、対策に必要な最低限の情報のみ提供しておりましたが、海外では攻撃のための情報が流通し始めており、かつ日本での連休が明けたことから、詳細情報を公開しました。

[PR]HASHコンサルティングが提供するセキュリティ情報メールマガジン(無料)

2012年4月16日月曜日

情報処理試験問題に学ぶJavaScriptのXSS対策

平成24年度春期の情報処理技術者試験の問題と解答(一部)が公開されていますね。情報セキュリティスペシャリスト試験(SC)の午後Ⅰ(全4問中2問を選択)では、問1と問2がWebアプリケーションに関する問題でした。このエントリでは問1について書きます。

問1は、インターネット通販A社のサイトで脆弱性検査を実施したところ、指摘事項2点が報告されたところから始まります。

指摘事項A:画面の遷移の中で、暗号化通信と非暗号化通信が混在しているが、暗号化通信でだけ使用されるべきクッキーに、(   a   )属性が設定されていないページが存在する。
指摘事項B:任意のスクリプトが実行可能であるページが存在する。

指摘事項A中の(a)は、他を見なくても「セキュア」属性だと分かりますね。徳丸本(体系的に学ぶ 安全なWebアプリケーションの作り方)では、4.8.2クッキーのセキュア属性不備(P209)に説明があります。

指摘事項Bは、ここだけ読むと、XSSのようでもあり、サーバーサイドのスクリプトインジェクションのようでもありますが、検査ログからXSSであることがわかります(下図はIPAからの引用)。XSSは、徳丸本4.3.1クロスサイトスクリプティング(基本編)と4.3.2クロスサイトスクリプティング(発展編)にて説明しています。


ここまでは、ごく基本的な問題ですが、問題文P6に出てくる以下の部分は、少しだけひねってますね。
このプログラムは、利用者が入力した文字列をダイアログに表示するために、受け取ったパラメタの値をスクリプトに埋め込み、動的にスクリプトを生成する。図4の(   c    )行目では、通常のHTMLにパラメタの値を埋め込むときと同じ方法でエスケープ処理を行っていたことから、生成されるスクリプトに問題が生じてしまうことが分かった。
JavaScriptの文字列リテラルにパラメータを埋め込んでいる箇所を探すと、37行目であることが分かります。
37:  out.println("<a name=\"#\" onclick= \"alert('" + escape(word) + "')\">");
これは、徳丸本では、◆イベントハンドラのXSS(P109)に説明がある内容です。
イベントハンドラのJavaScript文字列リテラルの中味を動的生成する場合は、徳丸本P110に説明するように、二段階でエスケープしなければなりません。

①まず、データをJavaScript文字列リテラルとしてエスケープする
②この結果HTMLエスケープする

情報処理試験の問題文もそうなっていますが、問題はエスケープする文字です。徳丸本では、最低限エスケープが必要な文字として以下の4種を挙げています。


これに対して、情報処理試験の問題文では、エスケープすべき文字を2種類に限定しています。従って、上記4文字から2文字を除外する必要があります。
まず除外できるのがダブルクォート「"」です。JavaScriptの文字列リテラルは、シングルクォートでもダブルクォートでも囲むことができるので、両方の場合に対応する前提では、両方の引用符をエスケープする必要があります。しかし、この問題では、シングルクォートで文字列を囲っていることが分かっているので、ダブルクォートの方は、エスケープ対象から除外することができます。
残り3文字のうち、シングルクォート「'」とバックスラッシュ「\」はエスケープしないとXSS脆弱性となるので、この2文字が解答でしょうね。

なお、バックスラッシュのエスケープを怠ると、以下の文字列で攻撃が可能です。
\');alert("XSS");//
この場合、シングルクォートのみがエスケープされると、生成されるJavaScriptは下記となります。
alert('\\');alert("XSS");//')
攻撃文字列先頭の「\」と、シングルクォートのエスケープの「\」があわせて「\」一文字と解釈され、後続のシングルクォートがエスケープされない状態で余ります。このため、文字列リテラルが終端され、その後ろはJavaScriptのコマンドとして解釈されます。すなわち、スクリプトのインジェクションができたことになります。

一方、改行については、エスケープしなくても上記のような攻撃には至りませんが、JavaScriptのエラーにはなります。また、JavaScriptの文字列リテラルの引用符をシングルクォートで統一しているプロジェクトはマレだと思われるので、徳丸本の基準に従うのが実務上はよいと思います。あくまで、テストとして、エスケープの原理を理解していることを問う問題と考えるべきでしょう。

twitter等でたまに「情報処理試験対策のために徳丸本読んでる」等のツイートを見かけることがありますが、私は「試験対策になるのだろうか」と思っておりました。この問題を見る限り、情報セキュリティスペシャリスト試験(SC)の対策になる場合もありそうですね。但し、今回引用していませんが、実際に攻撃があったかどうかをログから判定する問題など、徳丸本の知識だけでは解答出来ないものも当然あります。

追記(2012/04/30)

水無月ばけらさんから指摘がありました。「平成24年度春期情報セキュリティスペシャリスト試験のXSS問題
  • 「このコードに限定した話」という仮定を置かない場合、escape2は単引用符、バックスラッシュ、改行に加え、二重引用符などもエスケープする必要があるかもしれない。
  • 「このコードに限定した話」と仮定し、かつ「不具合なく動作する」ことを想定した場合、escape2は単引用符、バックスラッシュ、改行をエスケープする必要がある。
  • 「このコードに限定した話」かつ「攻撃さえ防げれば良く、不具合があっても良い」と想定した場合、escape2は少なくとも単引用符をエスケープする必要がある。
    • 単引用符を「\'」にエスケープすれば、バックスラッシュのエスケープも必須になる
    • 単引用符を「\u0027」にエスケープすれば、バックスラッシュのエスケープは必要ないかもしれない (見落としがある? 突破できる?)
たしかにそうですね。
ということは、上記に指摘した解以外に、複数の解が正答になってしまうということで、問題としてはよろしくない、ということになります。この問題については全員を正解とするか、理論的に正答と見なせる解(何種類かありそうですが)を全て正答にする、という対処が必要になりそうです。IPAとしてはどうするのでしょうか。

追記(2012/06/08)

IPAから正答が公開されました。これを読むと、設問3(2)はやはりシングルクォートとバックスラッシュのエスケープを想定正解としていますね。\u0027にエスケープするとした人はいなかったのでしょうか。

[PR]
WAF始めました。詳しくはHASHコンサルティング株式会社まで。
安全なWebアプリケーションの作り方DRMフリーのPDFによる電子版もあります。

読者