<前の日記(2006年05月16日) 次の日記(2006年06月05日)> 最新 編集

高木浩光@自宅の日記

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

2006年05月20日

セッションハイジャック攻撃は1号不正アクセス行為か、それとも2号ないし3号か

情報ネットワーク法学会の学会誌「情報ネットワーク・ローレビュー」に論文を投稿していたところ、第5巻1号に掲載していただくことができた*1

  • 高木浩光, “不正アクセス行為の2つの文理解釈について”, 情報ネットワーク・ローレビュー, 第5巻1号, pp.30-43 (2006年5月).

この論文は、昨年11月に開かれた同学会の研究大会での個別発表(発表時スライド, 関連報道)の際に予稿集に掲載された発表要旨に大幅に加筆したもの*2である。

追記した論点のうち次の部分について、説明が足りていないと思うので、詳細な検討を日記に書き留めておくことにする。

セッションIDは、「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないとされている符号」(同法2条2項1号)には当たらない場合が多いが、「制限を免れることができる情報」(同法3条2項2号および3号)に該当するであろう。警察庁の不正アクセス禁止法の解説資料22では、他人の識別符号を無断で使用する行為以外の不正アクセス行為として、「セキュリティホールを攻撃してコンピュータに侵入する行為」しか挙げていないが、セッションハイジャック攻撃のように、セキュリティホールのない(瑕疵のない)Webサイトに対して「制限を免れることができる情報」(セッションID)を入力する行為も、不正アクセス行為に該当すると解するべきである。

高木浩光, “不正アクセス行為の2つの文理解釈について”, 情報ネットワーク・ローレビュー, 第5巻1号, p.37

この部分は、セッションハイジャック攻撃*3は、不正アクセス禁止法3条2項1号の不正アクセス行為には当たらず(当たらない場合が多く)、同2号ないし3号の不正アクセス行為に当たると解するべきであると主張している。

「当たらない場合が多いが」と書いたのは、サイト管理者がサイト利用者に対して「セッションIDを他人に知らせないでください」と利用規約等に明記していることがあるかといえば、あり得ないことではないがほとんどないであろうという背景に基づいて述べたものである。

しかし、セッションIDが「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないとされている符号」(同法2条2項1号)に当たらないからといって、セッションIDが「識別符号」に当たらないとまで言えるかというと、実はもう少し検討が必要である。

まず、同法2条2項は「識別符号」を次のように定義している。

この法律において「識別符号」とは、特定電子計算機の特定利用をすることについて当該特定利用に係るアクセス管理者の許諾を得た者(以下「利用権者」という。)及び当該アクセス管理者(以下この項において「利用権者等」という。)に、当該アクセス管理者において当該利用権者等を他の利用権者等と区別して識別することができるように付される符号であって、次のいずれかに該当するもの又は次のいずれかに該当する符号とその他の符号を組み合わせたものをいう。

不正アクセス行為の禁止等に関する法律 2条2項

ここで「その他の符号」が登場するので、セッションIDが「その他の符号」に該当することを検討してみる必要がある。しかし、「次のいずれかに該当する符号とその他の符号と組み合わせたもの」とあるので、仮にセッションIDが「その他の符号」であるとしても、それ単独では2条2項の「識別符号」にはならない。

ところが、2条3項に次の記述がある。

この法律において「アクセス制御機能」とは、特定電子計算機の特定利用を自動的に制御するために当該特定利用に係るアクセス管理者によって当該特定電子計算機又は当該特定電子計算機に電気通信回線を介して接続された他の特定電子計算機に付加されている機能であって、当該特定利用をしようとする者により当該機能を有する特定電子計算機に入力された符号が当該特定利用に係る識別符号(識別符号を用いて当該アクセス管理者の定める方法により作成される符号と当該識別符号の一部を組み合わせた符号を含む。次条第二項第一号及び第二号において同じ。)であることを確認して、当該特定利用の制限の全部又は一部を解除するものをいう。

不正アクセス行為の禁止等に関する法律 2条3項

つまり、「識別符号」の定義は2条2項で与えられているものの、2条3項では、その定義を拡張し、括弧書き部分が示す符号も含むものとしている。しかも、「次条第二項第一号及び第二号において同じ」とあるので、これは3条2項(つまり、不正アクセス行為の定義)においても、その拡張された「識別符号」で解釈しなければならない。したがって、「識別符号を用いて当該アクセス管理者の定める方法により作成される符号」として何が該当し得るかを検討する必要がある。

Webアプリケーションは、その構成によっては、ログイン後にセッションIDを発行する場合がある*4。その場合、セッションIDは「識別符号を用いて当該アクセス管理者の定める方法により作成される符号」であると言うことができるかもしれない*5

しかし、この括弧書きには「により作成される符号と当該識別符号の一部を組み合わせた符号」とあるので、「当該識別符号の一部を組み合わせた」ものでなくてはならない。一般的なセッションIDでは、それに2条2項の「識別符号」の一部が組み合わされていることはないはずである。

ただし、次の2つの屁理屈が考えられる。

まず、「当該識別符号の一部を組み合わせた」というときの「一部」という文言について、空の場合も含むという解釈があり得るかもしれない。つまり、長さゼロの部分文字列を組み合わせているという見なし方である。これは、理数系的発想ではよくある物の見方であるが、法解釈上はどうだろうか。何も組み合わせていないのに「組み合わせたもの」と解釈することは普通ではないのではなかろうか。

次に、2条2項の「識別符号」の定義で「次のいずれかに該当する符号とその他の符号を組み合わせたもの」とあることから、2条3項の「当該識別符号の一部を組み合わせた」における「識別符号の一部」は、2項の「その他の符号」の部分だけから構成される一部であってもかまわないと言える。そうすると、セッションIDには、たしかに、パスワードなどの「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないとされている符号」は含まれていないけれども、「その他の符号」(つまり何でもよい)は含まれているじゃないか、と見なすこともできるかもしれない。ただ、それなら、初めから「その他の符号を組み合わせた」と書けばよいのであって、わざわざ「当該識別符号の一部を組み合わせた」としている趣旨は、2号2項の1号〜3号に何らかの形で係る符号であることを想定していると解すべきだろう。

つまり、このように、ログイン後に発行されるセッションIDについて、それを「識別符号を用いて当該アクセス管理者の定める方法により作成される符号と当該識別符号の一部を組み合わせた符号」と見なすことは、不可能ではないがやや無理があるといえる。

また、いずれにしても、ログイン前に発行されるセッションIDを用いてセッション追跡するWebアプリケーション構成も存在するのであり、そのセッションIDが「識別符号を用いて当該アクセス管理者の定める方法により作成される符号」でないことは明らかであるから、セッションハイジャック攻撃が1号不正アクセス行為に当たらない場合があるとする論旨は否定されない。

ちなみに、ではなぜ、2条3項で「識別符号を用いて当該アクセス管理者の定める方法により作成される符号と当該識別符号の一部を組み合わせた符号を含む」と括弧書きされているのか。それは、立法担当者らによる逐条解説書で次のように説明されている。

(略)本項括弧書きでは「識別符号を用いて当該アクセス管理者の定める方法により作成される符号」である場合を既定している。これは、公開鍵暗号方式における秘密鍵が識別符号の一部(第二条二項一号)として用いられる場合のように、アクセス制御機能によっては、識別符号そのものを入力(送信)せず、識別符号を作用させて作り出される別の符号を当該識別符号の一部であるID等とともに入力する例があるために、このように既定しているものである(略)。この場合の別の符号としては電子署名が、ID等としては電子証明書(略)が挙げられる。

不正アクセス対策法制研究会編著, 逐条 不正アクセス行為の禁止等に関する法律, 立花書房, p.54

公開鍵暗号方式を用いた識別は、利用権者等が自分の秘密鍵により作成した電子書名を識別を行う特定電子計算機に入力することにより行われる。(中略)この場合、利用権者等の秘密鍵が識別符号(の一部)となるが、特定電子計算機に入力されるものは当該秘密鍵で作成された電子署名となる(図参照)。

これを第二条第三項括弧書きに当てはめれば、「識別符号」は秘密鍵と電子署名の組み合わせであり、このうち別の符号を作成するために「用い」られるのは秘密鍵、「作成される符号」は電子署名、これと組み合わせられる「当該識別符号の一部」は電子証明書ということになる。「アクセス管理者の定める方法」とは、識別符号を用いてどのように符号を作成するか、その作成方法を指し、具体的には、RSA、楕円暗号等暗号化の方式を指す。

不正アクセス対策法制研究会編著, 逐条 不正アクセス行為の禁止等に関する法律, 立花書房, p.57

つまり、3条2項1号の不正アクセス行為の定義で、「識別符号を入力して当該特定電子計算機を作動させ」ることを要件としているが、この「入力」というのは利用者側コンピュータへの入力のことではなく、サーバ側コンピュータへの入力(電気通信回線を通じた、つまり、利用者コンピュータから見れば「送信」)のことを指しているので、パスワードなど利用者が直接使用する秘密情報(2条2項1号)をサーバへ送信しないタイプのアクセス制御機能の場合、2条2項の「識別符号」の定義ではこの要件を満たさないことになってしまう。そのため、2条3項の括弧書きにより「識別符号」の定義は拡張され、3条でも同様とされているのである*6

そのようなアクセス制御方式として、逐条解説書は公開鍵認証の場合だけを挙げているが、他にも、HTTPのダイジェスト認証(RFC 2617)や、POP3のAPOP(RFC 1939)も該当するであろう。これらはいずれも、パスワードを元にしたハッシュ値(「当該アクセス管理者の定める方法により作成される符号」)とユーザID(「当該識別符号の一部」)の組(「組み合わせたもの」)を電気通信回線を通じて当該特定電子計算機に入力するものだからである。

このように、2条3項の括弧書きの意図は、ダイジェストを用いた認証方式等が該当しなくなるのを避けるために追加されたものであり、セッションIDを送信することによるセッションハイジャックを1号不正アクセス行為に含めるために追加したわけではないと考えるのが自然であろう。

おそらく、立法関係者らは法案立案時に、認証機能の実現手法については技術的に検討したものの、認証後の認証状態(セッション)の維持手法については検討する必要性を認識しなかったのではなかろうか。逐条解説書においても、後者に関する記述が何ら見当たらない。もっとも、セッションハイジャック行為は2号又は3号の不正アクセス行為に該当すると見なすことは、自然に可能であるから、運用上問題となることはないという結果になっている。

警察庁の不正アクセス行為類型の分類方法には不備がある

さて、上の論文では次のように書いた。

セッションIDは、「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないとされている符号」(同法2条2項1号)には当たらない場合が多いが、「制限を免れることができる情報」(同法3条2項2号および3号)に該当するであろう。警察庁の不正アクセス禁止法の解説資料22では、他人の識別符号を無断で使用する行為以外の不正アクセス行為として、「セキュリティホールを攻撃してコンピュータに侵入する行為」しか挙げていないが、セッションハイジャック攻撃のように、セキュリティホールのない(瑕疵のない)Webサイトに対して「制限を免れることができる情報」(セッションID)を入力する行為も、不正アクセス行為に該当すると解するべきである。

高木浩光, “不正アクセス行為の2つの文理解釈について”, 情報ネットワーク・ローレビュー, 第5巻1号, p.37

脚注22の警察庁の解説資料とは、次のページのことを指す。

この解説では、不正アクセス行為の例は「その1」と「その2」で説明されており、前者は「他人のID・パスワードなどを無断で使用する行為」、後者は「セキュリティ・ホールを攻撃してコンピュータに侵入する行為」と説明されている。

もう少し調べてみると、やはり警察庁の認識では、不正アクセス行為は2種類の様態から成り、それは「識別符号窃用型」と「セキュリティホール攻撃型」であるとされていることがわかる。

まず、逐条解説書に次の記述が見られる。

(3) 不正アクセス行為の類型

不正アクセス行為は、一言でいえば、アクセス制御機能による特定電子計算機の特定利用の制限を免れて、その制限されている特定利用をし得る状態にさせる行為である。

不正アクセス行為の類型は、大別すると、他人の識別符号を無断で入力する行為と、アクセス制御機能による特定利用の制限を免れる情報(識別符号を除く)又は指令を入力する行為、いわゆるセキュリティ・ホール攻撃に分類することができる(注三、注四)。

(略)

本条第二項は、第一号で他人の識別符号を無断で入力するという前者の類型を、第二号及び第三号でアクセス制御機能による特定利用の制限を免れることができる情報又は指令の入力という後者の類型を規定している。

不正アクセス対策法制研究会編著, 逐条 不正アクセス行為の禁止等に関する法律, 立花書房, p.69

そして、警察庁が毎年発表している「不正アクセス行為の発生状況等について」という統計資料において、「不正アクセス行為の手口別年別推移」の統計のなかで、手口を「識別符号窃用型」と「 セキュリティ・ホール攻撃型」に分類している(図1)。

セッションハイジャック攻撃は、先に述べたように、1号不正アクセス行為に当たると解釈するのは無理があるので、「識別符号窃用型」に分類することはできないだろう。そうすると、セッションハイジャック攻撃がはたして「セキュリティホール攻撃型」といえるかどうかが問題となる。

では、「セキュリティホール」とは何だろうか。逐条解説書には次の記述がある。

(注四) セキュリティ・ホール攻撃は、コンピュータのプログラムの瑕疵等により、アクセス管理者の意に反してアクセス制御機能により制限された特定利用をし得る状態にすることができる一定の情報又は指令を入力する行為であり、実際にも相当数のものが知られている。

不正アクセス対策法制研究会編著, 逐条 不正アクセス行為の禁止等に関する法律, 立花書房, p.72

セッションハイジャック攻撃はセッションIDの値が何らかの原因で攻撃者に知られてしまうことによって可能となるものであるが、その原因は、セキュリティホールが原因である場合(XSS脆弱性など)も存在するものの、パケット盗聴による方法のようにセキュリティホールが原因ではないものもある。SSLによる保護を謳っていないサイトにおいては、パケット盗聴によりパスワードなどを盗み見られる可能性があることは、サイトの仕様であり、それをセキュリティホールと呼ぶことは通常ない。

また、何らかの原因で攻撃者に知られてしまったセッションIDで攻撃者にアクセスされたときに、なりすましアクセスを許すことになるのは、システムにセキュリティホールがあるからではない。それは正常な動作であり、システムに瑕疵があるということにはならない*7

セッションハイジャックという概念は、Webアプリケーション固有のものというわけでもない。たとえば、TCP接続を直接乗っ取る TCP session hijacking という攻撃手法も古くから知られており、パケットの盗聴・改竄が可能な状況では、システムにセキュリティホールがなくても、そのような攻撃が可能である。一般に、様々な通信プロトコルにおいて、このようなハイジャック系の攻撃はあり得るのであり、不正アクセス禁止法の趣旨からすれば、そのような攻撃も不正アクセス行為に該当すると解されるべきである。

セッションハイジャック攻撃を「セキュリティホール攻撃型」と呼ぶのが不適切であることは、小さなことかもしれないが、そこにこだわる必要性がある。それについては論文で述べている。関連する部分を少しだけ引用しておく。

ACCS事件の判決文には、不正アクセスに当たらない場合の例として、「当該顧客の公開領域へのアクセスは、当該顧客の承諾(同法3条2項各号)があるか、当該特定利用を誰にでも認めていることによりアクセス制御機能による制限のない特定利用であるから(略)、もとより不可罰であって、この点で不都合が生じることはない」とする記述がある17*8。しかし、2002年の一連の事件では、管理者はそのようなアクセスを承諾していなかったであろうし、管理者の主観ではアクセス制御機能(FTPアカウント)により制限されていると理解されていたものであろう。2002年の事件が不正アクセス行為に当たらないと判断される何らかの理由(管理者の主観によらない条件)が存在するはずであるが、ACCS事件の判決には記されていない。

2.3 アクセス制御機能による制限の優劣

そこで次に、あるアクセスがアクセス制御機能によって制限されたものといえるかという点について検討する。

ACCS事件の判決では、この点について次の検討がある18

(略)

「本件の各特定利用ができたのは、プログラムのないし設定上の瑕疵があったためにすぎないのであり、アクセス管理者が本件アクセス行為のような形で特定利用をすることを誰にでも認めていたとはいえない。よって、本件においても、本件CGI及び本件ログファイルの各閲覧は、アクセス制御機能による特定利用の制限にかかっていたものということができる。」とある。

しかしながらこの根拠だけでは、前述の2002年の事件での警視庁の判断と矛盾する。2002年の事件は設定上の瑕疵が原因であった。

この矛盾について大橋7は、「アクセス制御機能が極めて拙劣であり、もはや利用者にとってアクセス制御機能の存在を認識し得ない場合に至れば、たとえ行為の外形として『アクセス制御機能による特定利用の制限を免れることができる情報又は指令』が入力されたとしても、犯罪構成要件としての故意が認められず、不正アクセス行為は成立しないのであるから、不当な結論は生じないであろう。」と主張している*9

2.4 2005年の連続サイバー攻撃事件との対比

確かに2002年の事件においては、アクセスした者たちに、「アクセス制御機能により制限されている利用をしている」との認識はなかったかもしれない。ところが、2005年に対照的な事件が起きた。(略)

2005年の事件では、アクセス管理者の主観では利用を制限していたつもりであったであろうし、アクセス者の行為は犯意を持ったものであったと推察できる。また、詳細は明らかにされていないものの、プログラムの瑕疵が原因だったと推察できる。それでもなお不正アクセス行為に当たらないと判断される場合があることを、この事件は意味しており、不正アクセス行為の構成要件として、行為の外形に関する何らかの客観的条件が存在すると推察される。しかしながら、その条件は公表されていない。

高木浩光, “不正アクセス行為の2つの文理解釈について”, 情報ネットワーク・ローレビュー, 第5巻1号, p.34

3. さらなる議論の必要性

以上のように整理すると、警視庁は「GETメソッドによるアクセスならば不正アクセス行為に当たらない」との判断基準を持っているのではないかとの推定が可能である。しかしながら、それは、現在のWebアプリケーション構築技術の標準を鑑みるに、受け入れ難い条件設定である。その理由を次に述べる。

3.1 セッションハイジャック攻撃の可罰性

ブラウザの画面上にユーザ名とパスワードを入力してログインするタイプのアクセス制御機能を有するWebサイトにおいて、しばしば次のようなURLを目にすることがある。

http://example.com/foo.cgi?sessionid=c62ae61b35b70c8c

「sessionid=」以降に書かれた文字列は、「セッションID」と呼ばれ、

(略)

そのような攻撃が可能となる原因は、セッションIDが漏洩したことにあるのであって、サーバー側にプログラムや設定上の瑕疵があるわけではない21し、ましてや、「拙劣な」アクセス制御方式だということにもならない。(略)

脚注21: URLにセッションIDを含める構成方式は、Webブラウザが「Referer:」機能によって第三者サーバーへIDを漏らしてしまう場合があるという点で、適切でない構成であるということもできるが、サイトの全体構成次第で、適切といえる場合もある*10ので、それ自体に瑕疵があるとはいえない。

(略)

もし、単純に「GETメソッドによるアクセスならば不正アクセス行為に当たらない」とする判断基準を採用すると、プログラムに瑕疵のないアクセス制御機能さえ、同法の保護対象とならない場合がある(URLにセッションIDを載せるWebサイトに対するセッションハイジャック攻撃が処罰されない)ことになってしまうのであり、この基準は不適切である。

高木浩光, “不正アクセス行為の2つの文理解釈について”, 情報ネットワーク・ローレビュー, 第5巻1号, p.36

つまり、一方で、「プログラムないし設定上の瑕疵があった」という前提状況が、不正アクセス行為と見なす根拠のひとつとされているところ、他方で、「GETメソッドによるアクセスならば不正アクセス行為に当たらない」との基準で判断するのは、それは逆に、瑕疵のないシステムに対してさえ、セッションハイジャック攻撃が不正アクセス行為に当たらないということになってしまうのであるから、そのような基準は不適切であり、つまり要するに、瑕疵の有無で不正アクセスか否かを切り分けられるものではない――ということを主張している。

そのため、セッションハイジャック攻撃がセキュリティホール(プログラムないし設定上の瑕疵)攻撃型ではないことを示すのが重要となっている。

なお、この論文の本題は、そこではなく、何が2号および3号不正アクセス行為に当たるかの既存の判断の矛盾を示すことと、それを回避する解釈ついての検討となっている。

*1 編集委員の先生方にはご迷惑をおかけし、たいへんお世話になりました。

*2 予稿集の原稿では上限ページ数の都合から短縮版としていたところ、この論文は元原稿から書き起こした。(発表時スライドは元原稿の文脈に沿っている。)今回の論文は、発表時の質疑応答で気づかされた点など、いくつかの論点を元原稿に追加したもの。

*3 ここで言う「セッションハイジャック攻撃」とは、利用権者がログイン中の状態のときに、攻撃者がその状態を「乗っ取って」利用する攻撃を指す。利用権者がログインしていなくても直接になりすましアクセスができてしまう欠陥(たとえば、ユーザIDを送信するだけでそのユーザになりすましてアクセスできるなどの欠陥)のあるサイトにおける、そのようななりすましアクセスはセッションハイジャックとは呼ばない。典型的には、ログイン時にサーバにより発行されるセッションID(ログインごとに生成される予測困難な受付番号)を何らかの方法で知得して、それを窃用して当該サーバになりすましアクセスする手法(Webアプリケーションの場合)がこれに該当する。その他、FTPの利用における control connectionに対する TCP session hijackingなども該当する。

*4 Session Fixationの問題を避けるために、セッションIDの発行はログイン後に行った方がよいが、ログイン前から発行されたセッションIDをログイン後にも継続して使用する(セッション追跡のために)という構成の場合もある。

*5 実際には、実装上は、ログイン後であれ、単にランダムにセッションIDを作成して、それをユーザIDと関連付けるだけであるから、「識別符号を用いて」作成しているわけではないが、識別符号が入力されなければ作成されなかった符号であるといった理屈から、法解釈上の観念的な見方として、「識別符号を用いて当該アクセス管理者の定める方法により作成される符号」と解釈されることもあり得るかもしれない。

*6 ではなぜ、初めから2条2項でそのように定義しなかったかという疑問が生ずるが、それは、4条(他人の識別符号を無断で第三者に提供する行為)で、2条2項の定義を必要としているからであろう。

*7 何らかの原因で攻撃者に知られてしまった識別符号で攻撃者にアクセスされたときに、なりすましアクセスを許すことになるのが正常であるのと同様に。

*8 東京地裁平16特(わ)752号 平成17年3月25日刑事10部判決、判例時報1899号, pp.155-161

*9 大橋充直, “検証 ハイテク犯罪の捜査 情報漏えい犯罪の新判例(ACCS事件)”, 捜査研究647号 pp.67-81 および 同648号 pp.67-74

*10 外部サイトへのリンクが一切存在しないサイトで、かつ、SSLを使用していないサイトなど。

検索

<前の日記(2006年05月16日) 次の日記(2006年06月05日)> 最新 編集

最近のタイトル

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|
<前の日記(2006年05月16日) 次の日記(2006年06月05日)> 最新 編集