<前の日記(2010年04月09日) 次の日記(2010年04月15日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1143   昨日: 2328

2010年04月11日

ユニークIDがあれば認証ができるという幻想

2008年のNTTドコモによるiモードID送信開始以降、ケータイWebの世界に「かんたんログイン」なるエセ認証方式が急速に広がり、その実態は「はてなのかんたんログインがオッピロゲだった件」のように惨憺たるものになっている。こうした欠陥サイトはかなりあると考えられ、すべてを調べて廻ることはできないが、いくつかのメジャーどころのサイトについては、IPAの脆弱性届出窓口に通報して、対策を促す作業をやっている。

各サイトの「かんたんログイン」に欠陥があるかどうかは、実際に他人のIDでなりすましログインしてテストすることは許されない(不正アクセス禁止法違反になる)ので、自分用のアカウントを作成して(会員登録して)、自分のIDについてテストするのであるが、誰でも会員登録できるわけでないサイトがかなりあるようで、そういったサイトはどうしたらよいのか。以下は、会員登録が制限されているサイトでの事例である。

日経就職ナビ」は、Wikipediaエントリにあるように由緒ある著名サイトであり、しっかりした体制で製作されていると思われる*1ところだが、このサイトが、「モバイル版」で「かんたんログイン」を提供していた。

簡単ログインを設定すると、次回のアクセスより会員ID・パスワードの入力なしでサイトへログインすることができます。(略)

携帯電話固有の情報(電話番号ではありません)を利用するため、設定しても別の携帯電話からログインされる心配はありません

日経就職ナビモバイル版の使い方, 日経就職ナビ

「携帯電話固有の情報を利用する」から「心配ありません」という。

「別の携帯電話から」はそうかもしれないが、PCからはどうか。以下は、今年2月の時点で、日経就職ナビモバイル版のサイトに、一般のインターネット回線経由でアクセスしたときの様子である。

画面キャプチャ
図2: 日経就職ナビモバイル版サイトをFirefoxでアクセスした様子

ここでは、Firefoxの設定を変更して、User-Agentとして au携帯電話のUser-Agent文字列が送出されるようにしている。このように、ケータイ向けの画面が現れている。

このサイトの会員登録規約には「会員とは、就職活動を行う2011年3月以降卒業予定の大学生・大学院生・短大生・専門学校生が(略)に会員登録を申し込み、日経HRがこれを承認した方を指します。」とあるので、私は会員登録することができない。

そこで、会員登録しないまま「簡単ログイン」ボタンを押してみた。すると次の図のようになった。

画面キャプチャ
図3: 「簡単ログイン」ボタンを押したときの様子

「端末を特定する情報が取得できませんでした」「端末の設定を確認してください」と出ている。

ここで、Firefoxのアドオンを使って、リクエストヘッダに「X-Up-Subno」として私のau携帯電話の契約者固有ID(EZ番号)を付与するようにし、同じように「簡単ログイン」ボタンを押したところ、次の図の画面になった。

画面キャプチャ
図4: リクエストヘッダに契約者固有IDを付けて「簡単ログイン」ボタンを押した様子

「簡単ログイン設定がされていません」と出ている。つまり、このサイトは、通常のインターネット回線経由で送信された私の契約者固有IDを取得して、それがデータベースに登録されていないことを調べたということだ。

この時点で、なりすましログインが可能な状態にあると推定して、IPAの脆弱性届出窓口に届け出た。もっとも、この挙動から必ずなりすましができるとまでは言えず、たとえば、このサイトの造りが、取得した契約者固有IDがデータベースに登録されていることを確認し(てユーザを特定し)た後の段階に入ってからようやく送信元のIPアドレスを確認するように書かれてる可能性が考えられなくもないが、まあ普通はそんな変態的なコーディングはしないだろう。

この挙動について、2月23日に届け出たところ、3月15日に取り扱いを開始したとの連絡があり、3月25日に修正が完了したとの連絡があった。現在では、日経就職ナビのモバイル版サイトには、通常のインターネット回線経由ではアクセスできなくなっている。ファイアウォールで制御されるようになったのか、サーバへのTCP接続自体ができないようになった。これほどの重要サイトであってもこういう状況であったことに慄く。

それにしても、どうしてこういうことをやってしまうのか。昨年の8月に別の(はてなや日経就職ナビとは別の)あるサイトにこの問題を見つけて、サイト運営者に直接指摘を送ったとき、先方から来た最初の返事はこうだった。

これは、現実的には運営者側に悪意があれば、何でも出来てしまうと言う認識でよろしいでしょうか? その他の危険性が考えられるのであれば、ご指摘頂ければと思います。

運営者に悪意がある場合だけの問題と思われたようで、ようするに、ケータイのIDが誰でも取得できるものという認識が欠けている様子だった。他の人のユニークIDはわからないはずだから大丈夫と思ってしまうらしい。

このような、ユニークIDで認証ができると思ってしまう幻想は、世界的に古くから知られている問題で、たとえば、国民番号制に伴って生じ得る弊害の一つとして知られている。

つまり、国民番号の入力によって本人確認とするWebサイトを考えたとき、最初のうちはまあまあ機能するだろうが、そういうWebサイトが増えていくにつれて、しだいに本人確認として機能しなくなっていく。

実際、韓国では、Webサイトで住民登録番号の入力が必要となっているところが多いらしいが、もはや本人確認としては破綻していて、Wikipediaによると、2015年までに禁止する方針が明らかにされているそうだ。

住民登録番号の入力が韓国の多くのサイトで求められている中で、他人の住民登録番号を盗用するケースが目立ち、もはや、本人確認の手段として機能しづらい状況にある。そのため政府は、2015年までにインターネット上で住民登録番号による本人確認手続きを完全に禁止する方針を明らかにした。

住民登録番号 - Wikipedia

その点、日本は、そういう危険をちゃんと想定して、住民基本台帳法第30条の43(住民票コードの利用制限等)で、「市町村長等以外の者は、何人も、(略)住民票コードを告知することを求めてはならない。」と定めている。愚かな事業者がユニークIDの入力を認証代わりに使ってしまう危険を、国が防いでいる。

IDだけで認証にならないのは真っ当な技術者からすれば肌感覚でわかる当然のことで、だからこそ、様々なセキュアプロトコルが開発されて工夫されてきた歴史がある。PKIを使った方法では、公開鍵暗号の力を借りて、クライアント側の秘密情報を送信せずに認証するプロトコルが実現されている(VPNやSSLのクライアント認証等)。

PKIに限らず、パスワードによる認証だってそれなりに妥当なものであり、これは、もし各サイトに同じIDとパスワードを登録してしまえば、上の住民登録番号に近い事態になってしまうわけだが、それは利用者の責任であるし、信用できるサイトとできないサイトで分けてパスワードを登録することで、それなり妥当なところに落ち着いている。

それに対しケータイWebが決定的に違うのは、ユニークIDが常に送信される点にある。パスワードなら、利用者が意識して送信先を選ぶことになるが、ケータイのユニークIDは、本人が制御できないところで勝手にどこにでも送ってしまうわけで、それではまったく本人確認の役割を果たさない。

IPアドレスで制限すればいいなどとセンスのない技術者は言うが、それについてはこれまでにも書いてきた通りだし、今後も新たに書く予定がある。

ケータイ業者では、その抱えている技術者までもがその独自の世界で閉じこもって、技術的センスが狂わされているのではないかという疑いについては、以前にも示した。

そのときは流儀の違いだなどという反論も出ていたが、これはそれ以前の技術センスの問題である。これがわからない技術者はヤバい。

ちょうど先日も、Twitterでこんな発言をする人がいた。

画面キャプチャ
図5: 「ISPも認証情報を提供せよ」とするTwitter発言

これは、ケータイ脳業者とか言われそうという声も出ていたように、ケータイ世界のようにインターネットもなってくれという願望の表れなのだろう。

これは危険思想であり、周りのセンスある技術者が諭していかないといけない。同種のことはしばしば、通信レイヤ屋の人々が言い出すことがあって、やっかいになっている。たとえば、総務省の「通信プラットフォーム研究会」の2008年10月のパブリックコメント募集で公開された報告書案には、次の記述があった。

(b)移動通信分野の認証基盤と他の認証基盤との相互運用性の確保

携帯端末は日常生活において最も身近な情報端末であり、かつ、我が国の携帯端末は高度な機能を搭載したハイエンド端末となっている。そこで、こうした携帯端末について、固定通信網、移動通信網のいずれかを問わず、シームレスネットワークにおいてコンテンツ・アプリケーション等を利用する際の中心的な端末と位置付けることも可能である。

そのため、移動通信分野における認証基盤について固定系・移動系を問わず他の認証基盤との相互運用性を確保することは、我が国の強みをいかした新規性の高い事業を生み出す可能性があり、積極的に推進していくことが望ましい。

例えば、今後はIPv4アドレスが2011年頃に枯渇するものと見込まれることから、インターネットは段階的にIPv6アドレスに移行していくが、それに併せてIPv6アドレスが各携帯端末にも 付与されれば、従来の電話番号等をベースとしたユーザーIDに替わって、IPv6アドレスを携帯端末の識別子とする新たな移動通信の認証基盤を構築すること等も考えられる

通信プラットフォーム研究会報告書「通信プラットフォームの在り方」案, 総務省, 2008年10月24日

これが典型的な通信レイヤ屋の陥る危険思想で、これに対しては、複数の反対意見が寄せられ、最終報告書ではこの部分を削除する措置がとられている。

  • 「通信プラットフォーム研究会」報告書案に対する意見の募集の結果, 2008年11月28日
  • 報告書案に対する意見の募集の結果及びこれに対する考え方, 2009年1月30日

    意見63
    IPv6アドレスはアクセス先のウェブサイト等に常時通知され、ユーザーが送信の可否を選択できないことから、固定されたIPv6アドレスを認証用IDとして用いることは、セキュリティやプライバシー上問題があり、また、国際標準の動向にも反することとなる。

    考え方63
    以下の記述を削除する。

    「例えば、今後はIPv4アドレスが2011年頃に枯渇するものと見込まれることから、インターネットは段階的にIPv6アドレスに移行していくが、それに併せてIPv6アドレスが各携帯端末にも付与されれば、従来の電話番号等をベースとしたユーザーIDに替わって、IPv6アドレスを携帯端末の識別子とする新たな移動通信の認証基盤を構築すること等も考えられる。」

実はこの「通信プラットフォーム研究会」の最終報告書は侮れない。数々のパブリックコメント提出意見を取り入れ、脚註などに記入されており、プライバシーとセキュリティを両立させる認証方式にしていかなければならないと謳っている。

元の案に書かれていた記述の何が危険思想かというと、ユーザ認証は、アプリケーションが必要としているものなのだから、アプリケーションレイヤで行うべきものであるところ、通信レイヤでもできるからといってそうしてしまうと、通信している限り常に認証されてしまうことになり、つまり、人々の「認証されない自由」が剥奪されるからである。

この種の危険思想は過去にも「安心・安全インターネット推進協議会」の設立趣意書の記述(2003年当時)にも見られ、あちこちの関係者に忠告して事なきを得たという経緯もある。

こうした勘違いが、技術者の意見に耳を傾けないタイプの組織の幹部に出てくると危ない。今年1月のインタビュー記事でも、NTTドコモの辻村清行代表取締役副社長が次のように述べている。

  • 新春インタビュー:新たな10年で変わるモバイルビジネス──NTTドコモ 辻村氏に聞く(後編), ITmedia +D モバイル, 2010年1月3日

    ITmedia まさしくクラウドの世界ですね。そこで重要になる要素は何でしょうか。

    辻村氏(NTTドコモ代表取締役副社長) やはり確実で安全なユーザー認証技術ですね。そこで鍵になるのは、携帯電話の認証情報だと考えています。お客様が1人ずつ持っている回線契約に紐づく形で個人認証を行うのです。携帯電話は究極の個人認証番号を持っており、(その認証情報は)なりすましや不正利用ができません。ここがマルチデバイス時代における携帯電話キャリアの強みになっていくでしょう。

そもそもNTTドコモは、どうやったら「かんたんログイン」が安全になるのかの要件を公表していないのだから、この言い草はなかろう。

同様の発言は、先々週の金曜夜に開かれた、ケータイ評論家のUstream中継の座談会「SIM LOCK Japan ケータイ・ITジャーナリストによる討論会」でも出ていた。

画面キャプチャ
図6: 「サブスクライバIDはなりすましリスクが低い」と語るケータイ評論家の神尾寿(左)

(神尾寿)
コンテンツプロバイダで言うと、公式やっているかどうかというのも当然ありますけども、あともう一つ、ケータイ系のコンテンツっていうのは、サブスクライバID、まあいわゆる端末識別情報と、あとキャリアさんの課金を使っているので、あれに代わるものが今のところ、オープンなインターネットの世界にはないんですね。クレジットカードを日本人は使わないっていうのは、ネットの世界ではもうこれは常識なので、やっぱそれに代わる? ちゃんとそのクレジットカード以外の決済がどうやって整うのか、既にドコモさんとauはやるって、キャリア決済をやるとは言ってますけども、それがどれだけ使いやすいものになるのかだとか。あと、意外と課金に比べると注目されてないんですけども、サブスクライバIDがあることで認証が楽っていう。(一同、うんうん。)しかもね、なりすましリスクが低いっていう*2、セキュリティ上、またユーザビリティ上のプラスもあって、そういうものがじゃあSIMフリーになると、これたぶん、使えなくなる可能性が高くなってくるんで……(別の人が話し始める)

(本田雅一)
たしかにあの、セキュリティ上の問題っていうのはこれたしかにあると思うんですけど、それ以外のことに関しては、ルールが変わったらルールがわかったとこで、また新しくうまく生まれていくものなんじゃないですか。だから、既存のルールがこうだからやっぱり変われないよねっていうのは……、たしかにね、急に変われっていうのは無理ですよ、急に変わるのは難しいかもしれないけども……(別の人が話し始める)

SIM LOCK Japan ケータイ・ITジャーナリストによる討論会, 後半 33分20秒より

あまりにも現状礼賛の発言ばかりする神尾に対し、本田雅一氏が「また新しくうまく生まれていくもの」と遠慮がちに苦言を呈しているが、それでも「セキュリティ上の問題っていうのはこれたしかにある」と、その部分に反論できずにいる体たらくだった。

この様子に対して、視聴者からTwitterで批判の声が飛んでいた。

画面キャプチャ 画面キャプチャ 画面キャプチャ
図7: 「ケータイ・ITジャーナリストによる討論会」に対する視聴者の声 その1

この後、視聴者からの質問に答えるコーナーで、司会の日経コミュニケーション菊池氏が、サブスクライバIDは危ないというTwitterからの声を取りあげた。

(司会:菊池隆裕)
さっきの認証の話で質問が出ていますね。日本のユーザの心理的なものなんでしょうかね、キャリアの携帯の方が安心? なかなかクレジットの方に移っていかない話があって、サブスクライバID、キャリアのIDですよね、そちらの方が受け入れやすい、安全、安全って言いってましたっけ?

(神尾寿)
安全ですね。

(司会:菊池隆裕)
安全というのは誤解があるんじゃないかという質問もあったんですが。認証の仕組み? つまり、KindleでありAppleの仕組みであり、他の認証手段が出てきたというのがこの最近の動きかと思うんですけどね。キャリアじゃなくてもいいんじゃないかという。こういう流れができつつあると思うんですけども、このあたり将来的な見通しというか、

(本田雅一)
技術的にはインターネットの技術なので、べつに、セキュアじゃないかと言ったら、セキュアなものも作ることはできると思うけども、現状、安心して確実に100パーセントコミットできるような仕組みが、やっぱり閉じたキャリアが提供するネットワークということだと思うんです。それがいいかというと、その次に行かないといけないとは思いますけども。

(神尾寿)
認証に関して言うと、確かにキャリアさんが持っている強い武器がやっぱり携帯電話番号なんですよね。携帯電話は確実になりすましのできないツールなので、まあ一時期クローン携帯とか言われましたけども*3、実際あれ、科学的に証明されてはいないと。実際それが事件として事例があるわけでもなくてですね、あのセキュリティの高さっていうのは一つ見るべきところがある。さらにセキュリティだけじゃなくて、同一番号で、しかも本人性確認をしたユーザさんが使っているので、いわゆる本人性認証をすごくしやすいっていう、使い勝手の良さもあるんですね。なので、あの辺が今後キャリアの武器にはなっていくと思います。(略)

(略)

(西田宗千佳)
ただ、そこで一つ問題になるとすれば、たしかに携帯電話のサブスクライバIDっていうのは、非常に良くできた仕組みなんですけども、セキュリティ的に、技術を精査すると、正直な話、ザルなんですね。でも、今の段階で課金してる人とコンテンツを買ったという情報、もしくは物を払ったという情報をつなぎ止める、現実的な手段としては、現状でサブスクライバIDを使った方法が一番優れているということだと思うんですね*4。もしかすると、これはひとつ期待したいところではあるんですけども、ビジネスモデルを組み立てる段階において、ひょっとすると携帯電話のサブスクライバID以外で、課金者と買った人をきちんと結びつける方法ってのが、生まれる可能性がないわけではない。水平分業モデルを議論するときは、そこがすごく重要だと思う。現状で水平の議論というのが、究極的に成り立たないところがあるとすれば、今のところそれが見つかってないからだろうと。それがアメリカだったら、クレジットカードでいいかもしれないけど、ワールドワイドではそういうわけではない。

(神尾寿)
アメリカはソーシャルナンバーがありますよ。

(西田宗千佳)
ソーシャルナンバーって使ってるところありましたっけ?

(木暮祐一)
韓国に国民番号があって、コンテンツの最初の使用のときに入れて、そうすると全部認証されます。

(一同)
…………。
(別の話へ)

SIM LOCK Japan ケータイ・ITジャーナリストによる討論会, 後半 47分33秒より

駄目だこいつら。ケータイ評論家らの周回遅れぶりに慄く。通信プラットフォーム研究会報告書に書かれていることさふまえていない。

このとき、Twitterでは以下の声が出ていた。

画面キャプチャ 画面キャプチャ 画面キャプチャ
図8: 「ケータイ・ITジャーナリストによる討論会」に対する視聴者の声 その2

中継を見ていてこのケータイ評論家をどうにかしろと思ったが、まあ、あまり影響は及ばさなそうだから放置でいいのだろう。

僕らのインターネットWebは、技術者が作っていけばいい。それにはWebアプリケーション技術者にできることがある。駄目な方式は使わないこと。わかっている技術者は、まず、契約者固有IDの使用をやめることだ。もう始めてしまったところは、今すぐやめられてないにしても、今後やめられるように今から準備をしておくことだ。

先月にはついに「かんたんログイン」の提供を中止するところも現れてきた。

  • Buzzurlからのお知らせ: Buzzurlモバイル向け、「かんたんログイン」機能終了のお知らせ, 2010年3月5日

    Buzzurの携帯電話向けBuzzurlモバイルにおきまして、携帯端末のいわゆる端末固有IDを用いた「かんたんログイン」機能を提供しておりました。 しかし昨今の携帯端末を取り巻く環境の変化により、Buzzurlでは「かんたんログイン」機能はその役割を終えたと考えております。つきましては2010年3月末日を持ちまして本機能の提供を終了いたします。

  • Buzzurlからのお知らせ: 【Buzzurlモバイル】かんたんログイン機能終了のお知らせ, 2010年4月3日

    3月末日までに提供を終了するとお伝えしておりました、Buzzurlモバイルの簡単ログイン機能ですが、本日を持ちまして提供を終了いたしました。

    簡単ログイン機能を提供するために、簡単ログインの設定を行われたお客様の端末固有IDを技術的に復元困難な形式に変換した上で保存しておりましたが、簡単ログイン機能の廃止に合わせましてすべて削除いたしました。

ECナビはちゃんとわかっている技術者がやっているらしいということがわかる。

*1 たとえば、会員登録のURLは「……/registration/」となっていて「……/regist.php」ではない。

*2 「なりすましリスクが低い」の意味を好意的に汲み取って解釈すれば、「パスワード方式は、破られるような弱いものを付けている人がいるから、危ない」という意味なのかもしれないが、それを言うなら、パスワードをなくしてしまわないとそれは達成されない。現状の「かんたんログイン」方式は、パスワードがあった上でそれの入力を単に省略するものなので、リスクは増えることはあっても、減っているわけじゃない。パスワードをなくしてしまうには、最初からずっとサブスクライバIDだけで認証する方式となり、従来の着メロなどのコンテンツ課金や1か月単位での課金にはよかったかもしれないが、サブスクライバIDが変わらざるを得ないタイミングを超えて継続して使用する必要のある性質のサービス(SNS等)において、はたしてそこまで割り切れるだろうかという疑問がある。

*3 いや、だから、そういう問題じゃないんだってば。

*4 いや、そんなの他にいくらでもやり方があるってば。ドコモがcookieサポートしてこなかったからできなかっただけ。これまで携帯電話が課金で成功してきた理由は単に、携帯電話の契約だけで料金引き落としの契約が同時に済んでいるって点と、寡占事業なので成り立ってるってだけなんだってば。

本日のTrackBacks(全19件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20100411]

Projects/Symbio/Cbarq 定例会議 2010年4月20日 18:00 - 21:00 参加予定者: Symbio 高木様、TriAx 林、金子、佐藤、大石(デザイナ)、川村 資料: 本レジメ ラフデザイン(会員登録・Cbarq回答) サイトマップ ファイルマップ 画面仕様書 ユーザストーリー 議題 ...

「簡単ログイン」とは、主に会員制携帯サイトで利用されているログイン方法で、初回の会員登録時に個体識別番号を取得しておき、2回目以降は個体識別番号が同一であれば認証OK(IDやパスワード入力をせずに自動的にログイン状態)とするものです。 ポイントはID、パス...

読書SNSから、WEB本棚となった「趣味は読書2」のケータイ版も作った。
もともと既読未読管理と重複購入チェックのためのサイトなので、ケータイ版は必須といえば必須。「趣味は読書。」でも、ケータイ版を作ってあって、本屋でよく使ってたのだ。

こわいなぁ。イナガワジュンジの怪談より怖い気がする。...

検索

<前の日記(2010年04月09日) 次の日記(2010年04月15日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2010年04月09日) 次の日記(2010年04月15日)> 最新 編集