Web屋のネタ帳

AppleのiTunes ミュージックストアでアカウント乗っ取りが発生して身に覚えナッシングな請求が何万円もきて涙目な人がかなりの数出ているそうで。 当事者の日記とか新聞報道とか、被害者じゃないけどちょっとしたつぶやきとか、ざっと並べてみましょう。

• iTunes Storeアカウントの不正利用の件　その後 - 続・怒涛のCDレビューマラソンのブログ(2009/9)
  （注：↑こちらの方には「「おまえがパスワードを流出させたんだ」と決めつける迷惑な人々」をお読みいただければと切に願う。）
• iTunesアカウントが乗っ取られた！その２ - isi の日記 (2009/11)
• Twitter / Jeff Lebowski: 誰かがボクの Apple ID をリセットして乗っ取 ...
• asahi.com（朝日新聞社）：ｉＴｕｎｅｓで不正請求被害　アップル社、ＩＤ流出否定 - ネット・ウイルス - デジタル (2010/1/25)
• asahi.com（朝日新聞社）：ｉＴｕｎｅｓ、ＩＤなりすましの恐れ　アップル社調査 - ネット・ウイルス - デジタル (2010/1/29)

種々の情報に当たるといくつかヒントが得られる。たとえば上の朝日の記事では、引用すると、

一方、愛知県の男性は昨年末まで約２週間、ｉＴＳ上で、神奈川県の男性の利用画面に入ってしまった。
　神奈川の男性がＩＤとパスワードを登録する際、同じ名字の愛知の男性のメールアドレスを自らのＩＤとして誤入力した。そのＩＤがメールのあて先となったため、登録完了通知などのメールが愛知の男性に送信された。
　愛知の男性が受信メールを基にパスワードを変えると、神奈川の男性のクレジットカードで買い物ができる状態になった。ただ、愛知の男性が神奈川の男性に連絡をとり、ＩＤとパスワードを直した。
　いずれのケースも、悪意を持ってなりすますことができる状態だった。

とのこと。これもひとつのヒントだ。

では、いつもはツタヤでCD借りてくる派なのだが、久々にiTunesストアを覗いてみることにする。

まさにこれが、焦点となっているIDとパスワード。購入ボタンを押すと出るダイアログだ。
「あれ？俺のIDとパスワードってなんだったっけ．．．．？！？！」
と思ったので、とりあえず「パスワードを忘れた場合」のボタンを押してみたら、 ブラウザが立ち上がって次の画面が現れた。（赤線は筆者による）

パスワードを再発行します。あなたのApple IDを入力してください：
(ヒント: Apple ID はメールアドレスの形式である場合も、そうでない場合もあります。たとえば、「yourname」という Apple ID が「yourname@me.com」とは別に存在することがあります。 MobileMe のお客様は、MobileMe のメールアドレスを「membername@me.com」などの完全な形式で入力してください)

唐突ですが、筆者の知人に鈴木N君（あくまでも仮名）という奴がいる。 実験台になってもらおう。自分のAppleIDの欄に「suzukin」と入力してみると。。。

赤い矢印のところにご注目。どうやら鈴木君のメルアドはsuzukin[AT]mac.com のようだ。 そういえば、昨日の電車でしゃべってた外人達が「Hey! Haward...」と言っていた。ハワード君というらしい。そこで、AppleIDの欄に「haward」と入力してみよう。

haward君のメルアドはhaward[AT]gmail.comらしいということがわかった。もちろん本当にそれが鈴木君やハワード君のメルアドであるかどうかは問題ではない。

カンのいい人はこのへんで気づいただろうと思う。

1. もしも、鈴木君やハワード君は、もうそのメルアドは使ってなくて、失効していて、そして赤の他人が同じメールアドレスを取得できる状態としたら？（それが可能かどうかはメールサービス事業者による）
2. そして鈴木君やハワード君がiTunesストアで使ったクレジットカードはまだ有効期限内だとしたら？（一般に、クレジットカードの有効期限は3年とか5年とか、結構長い）
3. そのクレジットカード番号はPC内のiTunesソフト上ではなくiTunesストアのサーバ上に保存されているとしたら？（たぶんそうだと思うんだけど）
4. 赤の他人が例のメールアドレスを取得しなおして、iTunesストアで「パスワード忘れ」の手続きを踏んでメールを受け取り、パスワードを再設定したら？

しかしそれにしても、責任をもって対処すべき者は誰なのだろう？ ユーザー？いやあ、うーん。このケースではそうともいえるし、そうとも言えない。 少なくともいまのiTunesストアのIDとパスワードの管理画面の設計思想には問題を感じる。 大人の事情を重ねるうちに混乱してしまったID体系そのものについても、だ。

あと、購入ボタンを押したときにクレジットカード決済の場合はその都度下4ケタぐらいいちいち打たせる、っていう程度のハードルはつけたほうがいいんじゃないの？ それだとユーザビリティ下がるっていうんなら、せめて、クレジットカード（の下4桁）情報のサーバー上での保存を前回入力時から24時間とか48時間といった有効期間を設けて再入力欄出す出さないを制御するとか、方法はいろいろある。有効期間という概念の重要性と有用性については前回書いたさくらインターネットの例のとおりだ。

なお、以上の話はすべて、ほかにも沢山あるであろう仮説のうちのひとつに過ぎない。

see also:

• メールアドレスが漏洩してると決めつける迷惑な人々 (2006/7)
• 「おまえがパスワードを流出させたんだ」と決めつける迷惑な人々　(2008/9)
• 拝啓 消費者支援機構関西 様 (2008/9)

本編と続編を同時に公開する理由？ためしにやってみただけであり、気分です。とくに意味は無い。

いまさら昔の話を蒸し返すようなことをするくらいなら、2007年当時に本編みたいな議論を続ければよかったじゃないか、と思う方がいらっしゃることかと思う。

ぶっちゃけ、こうなるとは思っていなかったのである。なんせ責任者（社長）が出てきてこと細かに説明し始めるという予想外の展開になったうえ、問題点がはっきりしたからにはなにかしら手をつけてくれるのだろうと思うじゃないですか。

そんなわけで、事後検証は数ヵ月後くらいにまたやろーと思ってほったらかしていたら、見事そのまんま（俺が）忘却の彼方。で、何年もたった最近になってMTのバージョンアップを試みているうちに（20分でめんどくさくなって挫折）、DBのなかをあれこれと覗いていて昔の件の自分のエントリを見かけて、「ハテ、そういえばあれはどうなったのだろう？」と思い出してもいっかい試してみたら、何ひとつ改善されていないことが判明して唖然とした次第。もうね、アホかと。

俺はセキュリティの専門家と呼べるほどの技量ではないしそっち系を目指してるわけでもないが、こんなのをほったらかすことがまずいことくらいはわかる。コンピュータセキュリティの世界で「フルディスクロージャ派」とそうでない派の議論があるのは知っていたが、なんでそんな議論になるものなのか？という理由の一端を身をもって感じることができた。

そこのお前、話が続編になってないぞとか言うな。

結局、何も改善されてはいない。 ガンプラーウィルス対策のお願い？ サーバのパスワードの変更？ 安全なWebサイトの作り方改訂第4版？ むなしいね。 レンタルサーバそのものの管理画面のセキュリティがこんななんだから、それを使う側がなにやったって無駄だよ。

ことの発端は「さくらインターネットの会員メニュー画面のセッション情報はログアウトしても1年たっても消えない件」という、筆者が2007年に書いた記事にさかのぼる。そして詳細はその一週間後のさくらインターネットの社長自身のブログで実にこと細かにつづられることになった。

焦点となった認証用Cookieは、いわゆる一般的なWebアプリのセッション維持Cookieと比べると構造や設計が（悪い意味でなく）異なる、という点で恥ずかしながら筆者には誤解があった。 そして結局のところ、その認証用Cookieの値に含めた認証日時に対するサーバ側での有効期間をどの程度の長さにするかの問題である、という帰着点を得たはずだ。（※Set-CookieヘッダのExpire属性の話ではないので勘違いしないように） この点については社長ブログでは次の1行にまとめられている。

現在の有効期限を今より短くしないといけないページがあるのかもしれない（コンパネ等）

さて、このとき、当の社長が筆者へメールを寄せている。メールを公開してもよいとのことだったので、3年後のいま、その一部を公開しよう。

（中略）以上のとおり、相当に長い期間が経過した後にクッキーが利用できるのでは ないかという指摘については、クッキー自体に改ざん不可能な形で発行日が含まれており、そのチェックが行われているために、実際にはいつまでも利用できるわけではないということをご理解頂ければと思います。 もちろん、ページ毎に設定されている有効期限については、人によってさまざまな考えがあると思いますので、こちらについては熟慮を続けていければと思います。

そろそろツッコミを入れるべき時だろう。「いまより短く」？「熟慮を続けて」？ 「短く」とか「熟慮」とかじゃなくて、「有効期限なんてない／認証用Cookieにその認証時刻も暗号化されて格納されているけどそんなもの見てない／熟慮する気はまるでない」の間違いだったのではないでしょうか。

少なくとも、古い認証用Cookieを使って会員メニューに入ってから契約しているサーバーのコントロールパネルのファイルマネージャ（エクスプローラっぽいやつ）の画面にたどり着いてファイルを削除または編集するまでの一連の流れを見ると、そうとしか思えない。再現手順は3年前の記事と同じで、次のとおり。

1. さくらインターネットのユーザーの契約情報などを見る画面において、ログインする。
2. cookie情報を参照し、secure.sakura.ad.jpドメインで発行されている「SID」というCookieに格納されている値をメモ帳かなんかにコピペして保存しておく。
3. 画面右上の「ログアウト」ボタンを押す。念のためブラウザ内のすべてのCookie情報を削除し、さらにブラウザを閉じる。
4. 30分または24時間または3日または3年待つ。どれでも結果は同じ。
5. 待った後、再びメニューの画面にアクセスする。IDとパスワードの入力を促す画面が出ることを確認する。そこで、Cookie情報を手作業で追加、編集する。具体的に言うと、上でメモっておいた値をSIDというCookie名で保存する。ドメインはsecure.sakura.ad.jp、パスは/、secureフラグはオンにして、期限は適当に1年後くらいの日時にしておく。
6. その状態で改めてメニューの画面にアクセスする。IDやパスワードを入力してないにもかかわらずログインした状態での画面が現れる。
7. 「サーバーの解約」をしようとすると、パスワードの再入力画面が現れる。どうやらそういう画面では認証用Cookieの値に仕込まれた時刻情報をちゃんとチェックしているようだ。
8. しかし、「サーバー設定」を押すと、素直にサーバーコントロールパネルの画面に遷移する。 そして「ファイルマネージャ」にアクセスすれば、エクスプローラーライクな管理画面に遷移する。ファイルの表示も削除も編集も自由自在。

なお、「会員情報」のページからパスワードを変更しても、同じ手順が可能だ。つまり、認証用Cookie（値はまとめて暗号化されている）の中には、パスワードそのものの情報は含まれておらず「ID（会員番号？）とその認証が成功した日時」の情報が入っており、それだけで判断されるようになっているわけだ。

それから、「Cookieの中身をコピペして保存するような手法まで気にしろというのか」という話をする者は、問題点をまるで理解していない。

少し話を変えて、わかりやすい事例を挙げよう。最近、ガンプラーというコンピュータウィルスが猛威を振るっているそうだ。 その亜種は、「「FFFTP」のパスワードが“Gumblar”ウイルスにより抜き取られる問題が発生 (Internet Watch 2010/1)」 といった悪さをする。 なんにせよ、特定のFTPソフトがOSのレジストリに書き込んでいる情報を狙ってパスワードを盗み取るくらいだ。 特定のレンタルサーバ会社を狙ってブラウザのCookie情報を盗み取るようなことが、より難しいとも突飛なアイデアだとも思えないし、そういう亜種の出現もそう遠い未来ではなかろう。

一般論としては、WebサイトのCookieを盗まれることはめちゃくちゃに危機的と言えるほどの脅威ではない。Cookieの情報というものはあくまでも「一時的」な意味合いのものがほとんどだからだ。

ただしそれは、Cookieの値としてのセッションIDないしはそれに類する認証情報の、「いつ発行したか」の値をちゃんとチェックしかつ古い認証情報をはじくという仕様がWebサイト側に実装されていれば、の話である。

また、例えばFTPのパスワードであれば、盗まれたと気づいた段階で慌てて別の安全なPCからパスワードを変更にかかればよいかもしれないが、前述のとおり、さくらインターネットの認証用Cookieは、パスワードを変更した後でもそれ以前に発行されたCookieさえ手元にあれば認証を通過できてしまう。少なくともサーバーのコントロールパネルやファイルマネージャ画面までは。 これをどう救えというのだろう。

認証結果の有効期限といったものは、未知の脅威にもなんとか耐えうるための概念であり設計思想だ。 しかし、現状のさくらインターネットのサーバーコントロールパネル機能（にたどり着くまでの認証機能）を見る限り、そういった基本的な設計思想というものが完全に無視されている。 レンタルサーバ会社の社長自身が実に細かく問題点を把握しかつそれを自分のブログで公開し、おっ、社長すげえ、とか一見そう思えたのだが、現状を見るに、実は根本レベルでの理解がまるで欠けていると感じざるを得ない。

有効期限なし（無期限）という実装の問題はもちろん、それをはっきり認識し、かつ、責任者としての自分のブログで問題点を広く公開しつつも、結局はさらに数年も放置するという行動は、ユーザーの利便性のためとかいうトンチンカンな言い訳で済むような次元をはるかに超えている。

「ボタンの二度押し対策」とか「二重送信の防止」と呼ばれる設計は、Webアプリにおいてとても重要だ。

なんでもかんでもダブルクリックするユーザーというのは驚くほど多くて、そうした人々はデスクトップ上のアイコンとWebページ上のsubmitボタンとを区別しない。 あるいはsubmitボタンを押したあとで十数秒たっても反応が無い＝ネットワーク遅延とかサーバがのろいとか＝の場合にも、もう一度ボタンを押したくなるのは当然の心理だろう。

二度押しの結果として同じ商品が2個届いてしまうような事態は避けたい。だからこそ、Web業界ではいろいろと対策が練られてきた。input type=hiddenのタグとサーバ側セッション情報とに同じトークン文字列を持たせて云々、というのがサーバ側での定番の手法。そして、クライアント側ではJavaScriptを使った手法が様々に考えられている。 サーバ側での対応は、アプリの誤作動や、それこそ注文伝票が2枚発生してしまうのを防ぐためだ。一方クライアント側での対応はユーザビリティ向上の側面が大きい。どっちの対応も正しく、そして必ず両方とも実装する必要がある。

ここではクライアントサイドでJavaScriptを使う手法の話をする。何年も前に議論がなされていて、すでに枯れた話題ではあるのだが、ブラウザは多様化（特に携帯とか）し、JavaScript開発での汎用ライブラリの活用は当たり前になってきたこの時代、どんな方法がシンプルかつベターなのかという観点で、あらためて手法の一つを紹介したい。

数ある方法論のなかで、最近気に入っているのが、これ。

jQuery Disable On Submit Plugin | EvanBot
/*
 * jQuery Disable On Submit Plugin
 * http://www.evanbot.com/article/jquery-disable-on-submit-plugin/13
 *
 * Copyright (c) 2009 Evan Byrne (http://www.evanbot.com)     
 */
$.fn.disableOnSubmit = function(disableList){
	
	if(disableList == null){var $list = 'input[type=submit],input[type=button],input[type=reset],button';}
	else{var $list = disableList;}
	
	// Makes sure button is enabled at start
	$(this).find($list).removeAttr('disabled');
	
	$(this).submit(function(){$(this).find($list).attr('disabled','disabled');});
	return this;
};

使い方↓(head内のscriptタグで）
$(function(){
  $('form').disableOnSubmit(); // 全てのformに作用させる場合
  $('#hoge').disableOnSubmit(); // 特定のid属性をセットしたformタグに作用させる場合
  $('.hoge').disableOnSubmit(); // 特定のclass属性をセットしたformタグに作用させる場合
});

submitボタンを押した瞬間にそれをdisabled（グレイアウト）にすることで二度押ししようにもできなくする、jQueryを使ったスクリプトである。おすすめする理由は次のとおり。

1. jQueryだから。どうせ他の部分でもjQuery使っていることがあるので、そのついででシンプルなスクリプトで済むのなら、気分的にもラクだ。
2. オリジナルにスクリプトを書こうとして素直に disabled=true とやるだけだと、次にいったページから「戻る」ボタンで戻られるとdisabledになったまま（Firefoxの場合）というワナがあるのだが、こいつはその点も考慮されている。
3. どのformに作用させるかを、html側のデザイン次第でどうにでもできる。ページ内の全てのformではなく特定のformにだけ使いたいという場合もあるだろう。
   • 例えばform id="foo"とform id="bar"の二か所だけに絞りたければ、
     $('#foo').disableOnSubmit();
     $('#bar').disableOnSubmit();
     と2行書けばいい。
   • HTMLでは、id属性はwebページ内での重複が許されない。同一ページ内に複数のformがあって、それらにいちいち違うid属性を与えるのが面倒だというのであれば、class属性を使うのがいいだろう。form class="foo" というclass属性を与えたformタグすべてに対して作用させたければ
     $('.foo').disableOnSubmit();
     の1行で済む。また、cssではclass属性はタグに複数個設定できる。つまり form class="aaa bbb" みたいにできるのだから、なんだったらデザイン(見栄え)制御用のclass属性とは別にdisableOnSubmit()専用のclass属性を追加してしまえばいい。
4. form onSubmit="hogefunction()" のようにonSubmit属性でJavascriptを呼び出す手法をよく見かける。しかしこれはちょっと危険で、ブラウザの種類によってはJavaScript関数どころかform全体が動かなくなるケースがあるらしい。少し古いケータイ向けフルブラウザに多い。これはinput type="submit" value="hoge" onClick="hogefunction()" のようにonSubmitではなくonClickでやっても似たような危険が伴う。ケースバイケースなのでなんとも言えないが、少なくとも formタグにはid属性やclass属性を指定するだけという手法ならその部分は普通のHTMLに過ぎない。よって、特殊なブラウザであっても動作不良を起こす可能性が低くなるんじゃなかろうかと。
5. すぐにやめられる(笑)。「やってみたけど気にいらなかった」というときは、headタグ内のJavaScriptを消すだけだ。使わないid属性やclass属性をformタグに残したところで、どんなブラウザであれ動きにも見栄えにもまったく影響は残らない。

なお、クリックしたときにsubmitボタンをdisabledにしてしまう、という手法それ自体に、 「submit ボタン disable 技の罠 - naoyaのはてなダイアリー」という問題があることは一応頭にいれておいたほうがいい。 しかし、submitボタンのvalue値でサーバ側の動作が変わるような設計は意外と見かけない。つまり、submitボタンのvalue値は「ボタン上に表示される文字」としてしか使ってないケースのほうが多いのではないだろうか。だとすると、そう深く心配するほどでもないだろう。

さらに、これはもはや蛇足だろう（であってほしい）が、下のような書き方をしているformでは、この方法は動作しない。

<table>
<form action="...">
<tr>
......

HTMLとしてありえない位置にformタグがある。 Transitionalならいいのかもしれないけど、strictなdoctypeだとするとおかしい。 そしてjQueryはstrictな方針でDOM要素をたどっていく（らしい）ので、こういう非準拠な書き方をされるとdocumentの中のform要素をうまく捕捉できないことがある。結果、このformではdisableOnSubmit()が動かない。 「formタグの上下に空白ができてしまうんだ、どうしたらいい？」という相談に対する答えとして、ひと昔、いやふた昔前くらいにごく一部のWeb屋の間で流行ってしまった手法だ。 CSSくらい使えよと。（正解は、form style="margin:0;" でいい） 古いページ/デザインだといまだにこういうのが残っていたりすることも頭の隅にいれておこう。

カービューは自動車関係のサイト。新車/中古車の情報サイトやクルマ好きのSNSの運営とその広告事業が主。2007年にマザーズ上場。

で、つい先日、ちょっとした発表をした。

http://www.carview.co.jp/company/append/irr-20100122.pdf

当社はこれまで、月間ページビュー数の集計方法について、平成11年11月のサービス提供開始時より継続した集計方法を採用して参りました。ウェブ技術の進化に伴い、近年、Ajax（注１）やWebAPI（注２）といわれる呼び出しページが増加する傾向にあり、当社においてはそれらを実質的なページビューに含めることが望ましくないと考え、除いた数値で開示するものと致しました。
（コピーこっち）

結果、過去1年ぶんの月間PV数の数値がざっと2,3割ほど小さくなりましたと。 なお、カービューのサイトを見たところ、本格的な検索APIみたいなものは見当たらなかったことから、文中にあるWebAPIというのは単なるRSS/Atom情報のことと思われる。

当たり前のこととはいえ、ちゃんと宣言して過去1年分の発表PV数との差異まで公開するってのは、うそっぱち数値の渦巻く業界においてなかなか好感が持てる。

see also:

• ブログ「Web屋のネタ帳」が月間100億PVを突破しました (2009/8)