<前の日記(2008年07月26日) 次の日記(2008年07月30日)> 最新 編集

高木浩光@自宅の日記

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

2008年07月27日

無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者

契約者固有IDによる「簡単ログイン」の危うさ

一年ほど前、「携帯電話の「簡単ログイン」は個体識別番号を使ってこんなふうに作れます | WEBクリエイターの木」といった、この手の話題が盛んにホッテントリ入りしていた。このエントリにもおびただしい数の無言ブックマークが付けられている。

中には「なりすましとか問題ないんだろうか?」「あれってHTTPヘッダだから簡単に偽装できたんじゃ?」「重要な個人情報まで通過できるような構造にしちゃ絶対ダメ」といった声も見られるが、ほとんどはそのまま鵜呑みにしている様子だった。

IDだけで「認証」したつもりになってはいけないことは、昨年2月23日の日記「携帯電話向けWebアプリの脆弱性事情はどうなっているのか」でも書いた。

そもそも、「ID/パスワードを毎回入力するのでは携帯の場合では特に面倒です」などといって、端末IDをパスワード代わりにしてはいけない。端末IDは他のサイトにも同じものが送信されるのだから、パスワード代わりになどならない。

携帯電話向けWebアプリの脆弱性事情はどうなっているのか, 2007年2月23日の日記

これに対し、「y-kawazの日記:珍しく間違った批判をしている高木先生」というトラックバックを頂き、

キャリア毎にIPアドレス制限をする限りにおいては端末IDやユーザIDは偽装不可能*3なので、むしろ他人でも入力可能なパスワード認証よりも強力な認証かもしれません。逆にいえばその認証方法があるからこそ携帯業界ではクッキー無しでのセッション管理が可能になっていると言えます。なので高木氏の以下の批判は的外れと言えるでしょう。

携帯業界の認証事情, y-kawazの日記, 2007年2月24日

と言われたが、そんなことはわかっていて言っているのであって、脚注1で「IPアドレスを確認すればそれで本当になりすまし不可能にできるのかは知らない。それは携帯電話事業者が公式に示すべきことだ。」と言っている。このことについて、「おさかなラボ - 携帯電話のIPアドレス制限神話」も次の通り批判している。

  • DoCoMo(i-mode)

    本情報はあくまでも目安としてご参照ください。iモードセンタ以外から本IPアドレスでのアクセスがない事を保証するものではありません。

  • SoftBank

    本情報はあくまでも目安としてご参照ください。ゲートウェイ以外から本IPアドレスでのアクセスがない事を保証するものではありません。

  • au(EZweb)

    本情報はEZサーバ以外のホストによる上記表のIPアドレスでのアクセスがないことを保証するものではありません。

まるでコピp…いや判で押したような記述だ。つまり、この情報を元にIPアドレス制限を行なっても携帯電話からのアクセスであると保証されるわけではないということだ。これではいわゆる野良サイト(勝手サイト)では「IPアドレス制限ができる」という前提自体が成り立たないのではないか。

携帯電話のIPアドレス制限神話, おさかなラボ, 2007年2月25日

それから1年が経過し、「iモードID」の全サイト送信も始まり、その後もますます、「IPアドレス制限 + 契約者固有ID」による「認証モドキ」のサイト構築手法が広まりつつある。「簡単ログイン」で検索してみるとその様子が見えてくる。

「IPアドレス帯域」をどうやって安全に更新するのか

先日のWASForum Conference 2008でも、「携帯電話向けWebのセキュリティ」と題して、GREEの藤本真樹氏に、ケータイWebにありがちな脆弱性についてご講演頂いたが、その際に、この「IPアドレス制限」のやっかいな点が議論となった。このときの様子は「水無月ばけらのえび日記」にレポートされている。

質問

携帯キャリアのIPアドレス範囲のチェックはどうしているか?
→ アンテナでキャリアのサイトをチェックしたりして頑張っている

逆引きするのはどうか?
→ それは良いかもしれない

感想

質疑応答の「逆引きで見る」という話は瞬間的に「ヤバイかも」と思いましたが、高木さんが「そのDNSが安全かどうかという問題がありますが」とナイスフォロー。逆引きで判断する場合、PTRの値はそもそも信用できないのでパラノイド検査が必須になりますが、それでも大丈夫かどうかは怪しい感じがしますね。

「WASForum Conference 2008: 携帯電話向けWebのセキュリティ」, 水無月ばけらのえび日記, 2008年7月5日

携帯電話会社(キャリア)は、上の「おさかなラボ」のエントリが参照しているように、「IPアドレス帯域」と称して、キャリアのゲートウェイのIPアドレスの範囲を公表している。

これが、(予告なく)しばしば変更される(通常は追加が行われる)ため、すぐに対応しないと、アクセスできないユーザが出てしまうため、ケータイWebの運営者らは、このページが更新されていないか、アンテナ等を使って常時監視しているというわけだ。私の記憶では、WASForumでは、「メールマガジンで更新情報を得ている」という発言もあったように思う。

このとき心底ヤバいと私は思った。WASForumでは時間が迫っていたので言い出す機会がなかったが、「メールで更新情報を得ている」となると、その担当者に偽の更新通知メールが送られたら、どうなるだろうか。

つまり、攻撃者のIPアドレスが混入された、偽のキャリアIPアドレス帯域表がメールで送られてきたとき、それを信じてWebサイトに設定してしまったらどうなるか。攻撃者はインターネットからそのサイトにアクセスできてしまう。攻撃者は、事前に入手しておいた有効な契約者固有IDを、ひとつひとつヘッダにセットして繰り返しアクセスすることで、大量のユーザに連続して成り済ましログインできてしまう。

サイトの機能によっては、クレジットカードを不正使用されたり、登録されている住所氏名等の個人情報を抜き出されるといった被害が出るだろう。しかも、それは、短時間に大量に抜き出されてしまう。

Webサイト運営者に対し、「メールの内容は信用するな」という忠告はできるだろう。更新の通知だけ受け取って、新しいIPアドレス帯域表はキャリアの公式サイトから入手するというのが正しい。

しかし、キャリアの公式サイトからどうやって安全にIPアドレス帯域表を得るのか?

キャリア各社は、IPアドレス帯域の一覧表を以下のURLで提供しているが、なんと、いずれのページも https:// で閲覧しようとしても、できないようになっているのである。

NTTドコモ
http://www.nttdocomo.co.jp/service/imode/make/content/ip/index.html#ip
https://www.nttdocomo.co.jp/service/imode/make/content/ip/index.html#ip (404 Not Found)
KDDI
http://www.au.kddi.com/ezfactory/tec/spec/ezsava_ip.html
https://www.au.kddi.com/ezfactory/tec/spec/ezsava_ip.html (404 Not Found)
ソフトバンクモバイル
http://developers.softbankmobile.co.jp/dp/tech_svc/web/ip.php
https://developers.softbankmobile.co.jp/dp/tech_svc/web/ip.php (下の図のページにリダイレクトされる)
イー・モバイル
http://developer.emnet.ne.jp/ipaddress.html
https://developer.emnet.ne.jp/ipaddress.html (接続できない)

馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する(閲覧者が望めば https:// でも閲覧できるようにする)のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。

(8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。)

それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。

こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。

つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに毒入れ攻撃を続けることでそれに成功すれば、www.nttdocomo.co.jp や www.au.kddi.com、developers.softbankmobile.co.jp、developer.emnet.ne.jp のアドレスを偽サイトのIPアドレスに書き換えることができてしまう。その頃合いを見計らって、攻撃者が、サイトの管理者宛に、キャリアからのメールを装って更新通知メールを送れば、サイト管理者は、「キャリアのIPアドレス帯域が更新されて、新しいアドレスが追加された」と認識してしまうだろう。社内のアンテナでチェックしているなら、メールがなくても自動的に騙されてしまう。

ちょうど今、DNSポイゾニングの現実的危機が話題になっているが、元々DNSはそういうもので、今回話題の対策をしても、確率的にいくらか毒を入れられる危険性は残るのだから、このレベルのセキュリティに関わる用途で、DNSを信用してはいけない。

もっと危険なことに、キャリアのIPアドレス帯域表を自動的にダウンロードして、自動設定までやっていると思われる人たちがいるようだ。

  • 携帯キャリア各社のIPアドレス帯域を取ってくるスクリプト, spiritlooseのはてなダイアリー

        my $url = 'http://www.nttdocomo.co.jp/service/imode/make/content/ip/about/';
        my $content = get($url);
        while ($content =~ m!<FONT COLOR="\#009900"><B>(.*?)</B></FONT>!g) {
    

    (中略)本当はcronでACLを更新とかやりたいよなぁ・・・

    (中略)CPANにアップされたようです。

データを取りにいっているURLは http:// なので、DNSがやられたらイチコロだ。*1

携帯電話会社は、「IPアドレス帯域」と称するものを早急に https:// ページでも見られるようにするべきである。

そういうことは、ケータイWebで生計を立てている者達が、キャリアに要求するべきことだ。

だが、どうもケータイWebのサイト運営者たちは、どういう遠慮があるのか知らないが、キャリア様には何ひとつ要求できないらしい。「IPアドレス帯域」の表はHTMLで提供されているわけで、これがXMLでデータ化されるなり、Web APIで提供されるようになれば、業界は皆ハッピーに違いないが、それが実現されていない。WASForumでも愚痴が漏れていたが、小さな声で愚痴をこぼす程度で、誰もキャリア様を批判したりはしない。

こんな状況で事故が起きたら、キャリアに損害賠償請求したらいいと思う。https:// で提供するのが当然なのに、それを怠っていたのが原因と主張することはできるだろう。

キャリアは無責任を通せるか

とはいえ、上の方でも参照したように、各キャリアはいずれも、「本情報はあくまでも目安としてご参照ください。iモードセンタ以外から本IPアドレスでのアクセスがない事を保証するものではありません。」などと、以前からずっと無保証を宣言してきた。

キャリアのこの宣言は、「契約者固有IDは、顧客の行動分析や、悪質ユーザの排斥などに使うもので、セキュリティに関わる目的では使用しないでください。」という意味にとれる。なぜなら、契約者固有IDが偽装されないか否かは、IPアドレス制限が確実に行えることが必須の前提であるのに対し、顧客行動分析や悪質ユーザ排斥においては、それほどではないからだ。

ところが、その状況は今年の3月末に一変している。NTTドコモは、契約者固有IDが「簡単ログイン」のために使うものであることを公式に認めたのだ。

  • 重要なお知らせ: 『iモードID』の提供開始について, NTTドコモ, 2008年2月28日

    ■iモードIDの目的

    (1) お客様利便性の向上
    お客様がiモード対応サイトをご利用いただく際に、特別な操作をすることなくカスタマイズされたページを表示することができるようになります。

    (2) iモード対応サイト提供者様のビジネスの発展
    お客様の利便性向上により、iモード対応サイト利用率の向上につながります。

ここまで明確に、契約者固有IDを「認証」目的に使えと言っておきながら、その必須の前提であるIPアドレス制限のための「IPアドレス帯域」情報について、「本情報はあくまでも目安としてご参照ください」などという無責任が許されるのか*2。そのうち、法廷ではっきりされたらいいと思う。

検索クローラーのIPアドレス帯域に注意

最近さらに情勢は危うくなっている。

  • モバイルSEOのポイント実践編--端末識別、IPアドレスに最適化する, CNET Japan, Marketing CHANNEL, 2008年6月27日

    5.IPアドレスによるアクセス制限

    オープンな一般のウェブと異なり、モバイルサイトでは、各キャリアのネットワークからのみアクセス可能にしているサイトが多い。

    ここで問題になるのは、モバイルサイト用クローラーの多くがキャリアの保有するネットワークと異なる帯域で動作している点である。Googleモバイル、Yahoo!モバイルのクローラーのIPアドレス帯域は下記の通り。

    (略)

    検索結果に表示されるためにはキャリアのネットワークに加えて上記の帯域からもアクセス可能な状態にしておく必要がある。

キャリアのゲートウェイアドレスだけでなく、検索クローラのIPアドレスまで、アクセス許可に設定するケータイサイトが増えてきているようだ。

Googleのクローラなら信用できる(契約者固有IDでなりすましアクセスするなんてことは犯罪だからやらないだろう)と思って、これらのIPアドレスからのアクセスを普通に許してしまうサイトは多そうだ。

「Googleモバイル」について「IPアドレス帯域」が公開されているようだが、その公開方法がまた杜撰で酷い。よりによって、blogspot.com 上のブログで公開しているのだ。

  • Google モバイル検索についてのウェブマスター向け情報, Google Japan Blog, 2008年5月10日

    Google モバイルウェブクローラーのIP アドレス帯域

    日本向け Google モバイルウェブクローラー(モバイルウェブサイトを定期的に巡回するプログラム)の IP アドレス帯域はこれまで非公開としておりましたが、以下のとおりIPアドレス帯域の変更および公開を行います。なお、本変更は "Googlebot-Mobile" が含まれるモバイルウェブクローラーのみが対象となります。

    2008 年 6 月中旬以降順次
    以下の IP アドレス帯域を利用します。

    (略)

    この情報は予告なく変更される可能性があります。また、この IP アドレス帯域以外からのクローラーアクセスがないことを保証するものではありません。

なんというセキュリティ音痴。これがセキュリティに関わる情報だという認識がないのか。当然、ここを https:// で閲覧しようとしてもできない。

Googleというと、世界最高峰のIT技術者が集結していて、セキュリティにもプライバシーにも配慮した素晴らしいサービスを提供してくれるという印象があるが、日本のグーグルだとこんなもんだ。

「IPアドレス帯域」情報の提供方法にしても、キャリアのものも含めて安全に情報共有できるようなフレームワークを構築したりするのが、本国Googleの人たちのやり方だが、日本のグーグルはそういうことをやっていない。しょぼい。

そして、このしょぼいやり方に、誰一人文句を言わず、おびただしい数の無言ブックマークを付けている。

日本のWeb開発者たちはどんどん退化してゆく。

さらに言えば、

  • Google、モバイル向けクローラーの情報公開へ, ke-tai.org, 2008年5月12日

    公開されたのは、2008年6月中旬以降のIPアドレス帯域で、現時点のものではありませんのでご注意ください。

    以下のIPアドレス帯域が利用されるとのことです。今のうちから、許可IPに加えておくと良いかもしれません。

「今のうちから、許可IPに加えておくと良いかもしれません」などと言っているが、5月の時点でもし、そのIPアドレスが他人のものだったら(Googleのものでなかったら)どうするんだ?

もっとも、既に確保しているから予告している可能性は高いわけだけども、では逆に、このアドレスがいつまでGoogleに所有され続けるかということについて考えたことはあるだろうか。IPv4アドレスが枯渇しつつある今、アドレス割当が整理されて、このアドレスがGoogleから回収され、中国に割り当てられるかもしれないわけだが、ケータイWebの運営者達は、そういう可能性をちゃんと想定しているのか。

キャリアだけでなく、検索クローラにまでアクセスを許すとなると、検索クローラは無数にあるわけで、どのクローラは信用できるかといったことを評価しなくてはならないだろうし、廃止されたIPアドレス帯域をきちんと外していかないといけない。

あるいは、そういう心配がいらないように、キャリアからのアクセスでは契約者固有IDを解釈するが、検索クローラからのアクセスでは契約者固有IDを解釈しないように、Webアプリケーションを設計する必要があるだろう。

というか、そもそもIPアドレスで何かを制御しようとするのが誤りなんだが、ここまで常態化してしまった。

「IPアドレス帯域」で検索してみると、OKWaveや人力検索はてなで「IPアドレス帯域を教えてください」みたいな質問をしている人が散見される。この人たちは、見ず知らずの人が教えてくれた情報を鵜呑みにして、自分のケータイサイトに設定しているのだろうか。そんな輩が契約者固有IDを含む個人情報取り扱いサイトを運営しているかと思うとゾッとする。

iPhoneに契約者固有ID送信機能が搭載される日

10日の「日本のインターネットが終了する日」と22日の「あとがき」では、こうして退化してゆくケータイWebが、日本のスタンダードとなってしまい、いつの日か、PC向けの普通のインターネットまで、単一IDの全サイト送信が必須になってしまうのではないかと危惧した。

これに対し、「iPhoneがきっとそれを止めてくれる」と希望的観測を示す人が続出した。

  • iPhoneと携帯契約者固有IDと複アカと青少年ネット規制によるケータイ闇ナベ狂想曲, Web屋のネタ帳, 2008年7月21日

    2008年7月。ここへきてiPhoneが豪快に殴りこみ。もちろん空気読む気なぞさらさら無し。携帯契約固有ID?端末シリアル番号?はぁ?日本の事情なんか知るか。っていうかお元気ですかそこのガラパゴス諸島のみなさん。俺様はアップルだ、いいからそこに行列しろと。

  • むしろ「ケータイ」を変えようよ, 崎山伸夫のBlog, 2008年7月23日

    iPhoneはyomoyomoさんがFSFの批判を紹介しているように決して自由な端末ではないが、日本のケータイ文化の文脈とは縛るところが明らかに異なる端末であって、そうした多様性が日本のケータイ文化を市場を通して揺るがし、コンテンツプロバイダーとキャリアの態度を変えさせることに私は期待している。

なぜ、iPhoneだとそうだと思えてしまうのだろうか。先日の「あとがき」で「Windows MobileのIEでどうやって契約者固有IDを送信しているか」を書いたように、EMnetでは、Windows Mobileの普通のInternet Explorerが契約者固有IDの全サイト送信をやっているわけで、これは単にイー・モバイルが提供しているプロキシサーバを通すように設定されているからであって、同様のことはiPhoneでだって容易にできる。

ソフトバンクモバイルが「Yahoo!ケータイがiPhoneでもご利用可能になりました!」として、プロキシサーバの設定を案内するという事態が考えられる。

その必要があるのかというと、NAVITIMEの動向が気になるところだ。iPhoneにもNAVITIMEがApp Storeで提供されている。私はiPhoneは持っていないのでiPhoneでは確かめていないが、iPod touchでNAVITIMEを動かしてみたところ、下の図のようになった。

iPhoneには似つかわしくないケータイふうの画面で「会員登録/解除」*3というメニュー項目を選択し、「会員登録する」を選択すると、

■お知らせ

誠に申し訳ございませんが、iPhone版NAVITIMEの会員向けサービスは現在準備中です。サービス開始まで、いましばらくお待ちください。

という画面が出た。契約者固有IDがないとどうやって会員登録システムを作ったらいいのかわからないんじゃないのか……というのはさすがに穿ち過ぎだと思いたい。

NAVITIMEからソフトバンクモバイルに対して、契約者固有ID送信用プロキシサーバの用意を要請している……なんてことがなければいいのだが……。

今後の日記予定

  • 「日本のインターネット終了」を阻止するため、私たちにできる行動
  • 楠案では駄目な理由
  • どうやって解決するのか、「FirstPass」で解決するのか

*1 SSLを使用していないケータイサイトにおいては、「DNSが原因のリスクは元々あるじゃないか」と言う人がいるかもしれない。しかし、それは、キャリアのゲートウェイが参照するDNSがやられたときの話で、さすがにそれはそれなりに対策がとられていて安全であると思いたいし、仮にそれが起きても、偽サイトに誘導されるだけで、契約者固有IDを用いたなりすましログインをされてしまうわけではない。それと比べて、Webサイト側のDNSがやられて、IPアドレス制限用のIPアドレス帯域を誤って設定してしまったときの危険は、一気に全部抜き出されてしまうという点で深刻である。

*2 NTTドコモの立場からすれば、「iモードIDの目的」に「簡単ログイン」のことを持ち出したのは失敗だったと思う。本来はそれを言うべきでなかった。しかし、iモードIDを導入するにあたり、顧客に告知しなければならないとなると、何の目的の機能か説明しなくてはならなくなる。ここで正直に「広告で行動分析します」「悪質ユーザの排斥に使います」とは言えなかったのだろう。汚いことは見せないようにして、あくまでも「お客様利便性の向上」と美辞を連ねて説明せざるを得ないというのは、営利企業ゆえのしかたのないことなのだろうか。

*3 「解除」という表現が、いかにも契約者固有IDを用いた制御方式を想起させる。

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

高木さんからご批判いただいたようだけれども、私は「iPhoneがきっとそれを止めてくれる」という話をしているのではなくて、高々、可能性の話をしているだけ。
とりあえずの確認。契膊..

だが、どうもケータイWebのサイト運営者たちは、どういう遠慮があるのか知らないが、キャリア様には何ひとつ要求できないらしい。「IPアドレス帯域」の表はHTMLで提供されているわけで、これがXMLでデータ化されるなり、Web APIで提供されるようになれば、業界は皆ハッピ..

高木浩光氏の日記より「無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者」読んだ。 いまそこにある危機であると同時に、開発者の心構えとして胸に刻んでおきたい。 これ、誰も気付かなかったのか、誰も警鐘を鳴らさなかったのか。 僕は携帯Web

&#62;&#62;ここまで明確に、契約者固有IDを「認証」目的に使えと言っておきながら、その必須の前提であるIPアドレス制限のための「IPアドレス帯域」情報について、「本情報はあくまでも目安としてご参照ください」などという無責任が許されるのか*2。そのうち、法廷では..

楠さんは「ケータイ的な世界がPCに浸食するとは考え難い」というのだけれども、楽観的にはそうだろうし、そうあってほしいけれども、悲観的な見方は可能だ。ふとニュースサイトをみ祟..

8月27日(水)に「情報教育研究フォーラム2008」に行った. 午後の分科会では,大学生が模擬授業という形式で,情報セキュリティを専門とする大学教員の指導のもと行われた.これは,学生を育てる,という目的もあるが,「現場の高校教員に,大学から最新の科学的知識を..

無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者※時期外れのトラバですが・・・契約者固有IDだけで認証するのは大変危険な理由をもうすこし。・IP制限していないサイト ‐そのようなサイトで固有IDと住所などが紐付いた形で保存されていた...

検索

<前の日記(2008年07月26日) 次の日記(2008年07月30日)> 最新 編集

最近のタイトル

2024年12月02日

2024年11月24日

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|12|
<前の日記(2008年07月26日) 次の日記(2008年07月30日)> 最新 編集