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日インフィニテック社のセミナーで基調講演します

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. ファイルのアクセス制限不備の脆弱性
（１） SD カードに機微な情報を保存
（２） ファイルが不正なアプリからアクセス可能
4.2. コンポーネントのアクセス制限不備の脆弱性
（１） 不正なアプリに機能を悪用される
（２） ファイルが不正なアプリからアクセス可能
4.3. ログ出力に関する情報漏えい
（１） 機微な情報をログに出力

4.1と4.2の両方に「（２） ファイルが不正なアプリからアクセス可能」がありますが、4.1はファイルのアクセス許可の問題に起因するもの、4.2はコンテントプロバイダの設定不備に起因する問題です。特に4.2節は、Androidの特徴がよく出ていて興味深い内容だと思います。

■まとめ

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

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

さくら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サーバーを利用している方は、サービス提供元に対して、この種の問題がないか確認するとよいでしょう。