結局、今週も動きはなかった。コン競べですかい？毎日チェックするのもいいかげん飽きてきた。どうにでもなれ！ってなもんで、お手上げ、降参です。ハイ。明日から３連休。

。。。。というレポートをここに書いたが、再度テストしてみると、まだ直っていなかった。

テスト方法を間違えたのか、システムが不安定だったのかよくわからない。たぶん、一度にたくさんのテストをしたので、間違えたのだと思う（あわてものめ）

記事の公開は、10分～20分程度だったが、その間、ここに書いていた記事を見た方、忘れてください。

「あなたは、ここで読んだ記事、何も覚えていな～い。忘れた～忘れた～忘れた～」

Ｄｏｂｌｏｇが改修されてから、今週でもうすぐひと月になる。
ことがことだけに、非常に歯がゆい書き方をしないといけないが、改修後のDoblogには、セキュリティやセッション管理やユーザ権限など表には出ないが基本的なところに多くの問題がある。

リリース前にいったいどんなチェックをしたのか、ノーチェックでリリースしたのではないかと思うくらいだ。

どんな問題があるのか、ここには書けないが、見つけたものはすべてバグ報告をしてある。おそらく他の方からも多くのバグが報告されていると思う。ＵＩ回りや使い勝手、見栄えなどのすぐわかるバグの対応も大事だが、悪用されると被害が出るような目立たない隠れた問題にも優先的に対応してほしいと願う。対応が遅れるほど問題が表に出てくるかもしれない。他にも見つかっていない問題もあるだろう。リリースしたからと安心せず、これでいいのか、設計と実装コードを最初から徹底的に見直しチェックてもらいたいと思う。

あまり大声では言いたくないが、これだけは言っておこう。
現在わかっているだけでも、Doblogは、いろんな面であまり安全、安心できる状況ではない。不安をあおるわけではないが、何が起きても不思議ではない状況だ。大げさに反応する必要はないが、ユーザとして現在できる自衛策は、できるだけログイン時間を短くする、ログインしたまま他のブログやサイトを訪問しない、大事な記事やコメントはバックアップを取っておく、どんなことが起きてもあきらめる、という覚悟も必要だろう。これはある意味、致命的である。といっても、命をとられる恐れはない。

このことは、秘密でもなんでもなく、見れば一目瞭然のことなのでここに書くが、Doblog改修後、記事番号の採番方法が変わっている。

今までだと記事の採番は、全ユーザの全記事に対して順に採番されていた。つまり、記事の投稿順に、Aさんの投稿が100番だと、次に投稿したＢさんは101番だった。そのため、AさんもＢさんも、ブログ中の記事番号は連続しておらず、バラバラ（飛び飛び）だった。

この採番方法だと、採番そのものがボトルネックになる。分散処理を目指した今回の改修では、こうした採番方法の改修もひとつの目玉だったのだろう。改修により採番方法が変更になった。

現在は、ユーザごとに連続した番号で採番するようになっている。つまり改修した6月16日以前の記事番号を基準に一つずつ増えていく。例えば、Aさんの6/16以前の記事が100番なら、Aさんの次の記事は、101番、102番、103番のようになる。

何だそんなことか、それがどうした？という方はちょっと考えてみよう。あるユーザの記事が連番で採番されるということは、どういうことか。逆に考えれば、欠番がわかるということではないか。

例えば、101, 102と続いて、次に104がくれば、103はどうしたの？ということに気がつくだろう。

この103番は、削除した記事か下書きにして非公開にした記事のどちらかだ。つまり、そこに下書きにした非公開の記事があるかもしれないということがわかる。

今までは記事番号が飛び飛びだったので、全ユーザの全記事を調べない限り下書き（非公開記事）を推測できなかった。番号が推測できてもそれがどのユーザに属する記事かはわからなかった。だが、改修後は、これを簡単に推測できる。

記事番号が推測できることから派生して困った問題（バグ）が発生している。そのバグについては編集部にバグレポートを送ってあり、早急に修正してくれると思うが（希望）、それまでは、下書きにした記事に関連するものすべてが他のユーザに不可視だと思って安心しているとヤバイかもしれない。

---この問題がWEBアプリケーションのセキュリティ上の脆弱性かどうかについて少し悩んだが、そうではないと判断し、単なるバグとして編集部に直接レポートすることにした。---

ときどき読んでいるJoel on Software。著者がMicrosoftでExcelのプログラムマネージャだったときの思い出話が載っている。Excel用VBの仕様をBill Gatesにレビューしたときの話だ。これをBillG Reviewというらしい。

このレビューには、F**** カウンターという役割の人がいて、仕様をレビューしている間、Bill Gatesが何回 F Wordを発するかをカウントしているのだという。このFカウント値が少ないほど、良いレビューであるということになっているらしい。

最初この話を読んだとき、F Wordが何のことを指すのか、はっきりとはわからなかった。想像はできたものの、特に調べもせず、ふ～んという感じで読んでいた。

その後しばらく経ち、F Wordって何だろう？と思い出しGoogleで調べてみた。やはり想像どおりのことだった。

Bille Gatesは、このF Wordをよく使うようだ。というより、一般にアメリカ人がよく使うのかもしれない。日本のマイクロソフトの社長だった古川氏のブログに、1986年の日本法人創業披露パーティの席上で、一人当たりのパーティ経費が高いと、古川氏がGatesから罵倒されるという思い出話が出てくる。そこで古川氏は、「具体的にはFから始まる単語でイキナリ罵倒されるのが、これまたビルゲイツ流」と書いている。それほどよく使っていたようだ。

GatesがF wordを実際に使っているという証拠のビデオもあるようだが、残念ながら英語耳になっていない私には聴えなかった。

お客さんから、こんにゃくをたくさんいただいた。ダイエット中のことをどこからか聞きつけてきたのだろうか？賞味期限30日となっているが、毎日３食、こんにゃくばかり食べても、ひと月では食べきれない量だ。

本場鹿沼産の手作り品とのこと。さすがに美味い。というのだろうか？とりあえず生で食べても癖がなかった。（写真は、鹿沼中條商店のこんにゃく）

禁煙を開始してから、30日目になった。この間の体調の変化。
臭覚が戻った。水道水の塩素の臭いに敏感になった。これまでは、塩素の臭いなんぞはしなかった。

味覚が戻った。食べるものが美味しい。ますます太るかも。困ったことだ。

ときどき理由無くタバコが欲しくなる。そんなに強い要求では無いため深呼吸一回くらいで消える。

眠い。禁煙の影響かどうかはわからないが。。。。

この程度までは前回もプチ禁煙しているので、これからが挑戦だ。

６月２２日の「セッション情報が、だだ漏れなのです」と
６月２５日の「事例研究：頭隠して尻隠さず」を非公開としました。
コメントいただいた方、コメントごと消しました。（orz.....)

新たに発見したセキュリティ問題があり、IPA/ISEC（情報処理推進機構セキュリティセンター）にウェブアプリケーションの脆弱性として正式に届出を提出しました。そのため、以前の記事が、経済産業省の「ソフトウェア等脆弱性関連情報取り扱い基準」の発見者基準である「第三者に漏洩しないよう適切に管理」しなければならない「当該脆弱性関連情報」とみなされる恐れがあるかもしれず、念のために非公開としました。

以後、問題は、IPAやJPCERT/CCと当該Web管理者との間で処理されることになります。

これは、「一部分を隠して、全部を隠したつもりでいるとき」よく使われることわざだ。こういう事例がある。

「ある」ブログにログインするとき、ニックネームとパスワードを入力する。ニックネームは公開データであり、誰でも知ることができる。これに対してパスワードは、本人しか知らない秘密データだ。

入力したニックネームとパスワードは、HTTPSという手順でサーバーに送られる。HTTPSとは、セキュアなHTTPという意味で、データはサーバーまでの通信経路上を暗号化して送られる。

なぜ暗号化して送るのか。それは、データが相手に届くまでの間に、「盗み読み」される恐れがあるからだ。そういう脅威があると想定しているから、その脅威から秘密データを守るために暗号化する。盗まれて困るデータとは、本人しか知らないはずの「パスワード」である。これを守るために、わざわざ暗号化して送っているのだ。

一般にシステムのセキュリティは、そこにどんな脅威が考えられるかという「脅威モデル」をまず想定し、その脅威に対してどのように防衛するかということを考える。
-------------------
さて、ログインのために入力したパスワードは、こうして安全にシステムに送られた。そこで、ログイン後に使える「マイプロフィール設定」という機能を使い、自分のプロフィールを変更してみよう。変更できるプロフィールには、
ニックネーム、メールアドレス、性別、誕生日、住まい、そして「パスワード」
などがある。

「マイプロフィール設定」をクリックすると、すでに設定してあるニックネームやメールアドレスなどが表示される。そして、「パスワード」は、●●●●●●で表示されている。

●●●●●●の下に何が埋まっているのか、ちょっとHTMLのソースを覗いてみよう。パスワードのところは、このようになっている。＜input type="password" name="password" size="26" maxlength="22"
value="ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ" AUTOCOMPLETE="off" id="idPassword"
class="profile-textbox0001"＞
value="ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ"というところに注目してみよう。このxxxxxにあなたのパスワードが入っているはずだ。

何故か。「マイプロフィール設定」をクリックしたとき、ニックネームやメールアドレスなどの他のデータとともに、サーバーがパスワードを送ってきたからだ。そのとき、これらのデータは暗号化されていただろうか。いいや、暗号化されてはいない。通常のHTTP手順で、通信経路上を平文のまま、可読可能なそのままの形で送られている。秘密のデータであるべき「パスワード」がだ。

ここで「設定保存」ボタンを押すとどうなるか。今度は、HTTPSで暗号化されて送信される。

つまりこのシステムは、行き（クライアント->サーバー）は盗聴されるが、帰り(サーバー->クライアント)は盗聴されない、という脅威モデルを持っていると考えられる。それは無いだろう。行きも帰りも盗聴されていると考えるのが普通だ。
-------------------
行きも帰りも盗聴されていると考えると、「マイプロフィール設定」をクリックした時点で、「パスワード」は、危険にさらされてしまう。そのため、このシステムを安全に使うためには、「マイプロフィール設定」をクリックした時は、必ず、パスワードを変更しないといけない。
-------------------
そもそも秘密データであるパスワードの変更は、他の項目の変更とは別に処理すべきであるし、サーバーから生のパスワードを返す必要はない。チェックが必要ならダイジェストで可能だ。
また、変更後のパスワード入力だけでパスワード変更を可能にしてしまうのも危険だ。もしセッションが乗っ取られている場合は、パスワードを変更され、他人に永遠にブログごと乗っ取られてしまうだろう。他にもいろいろある。。。。。
このブログは、研究すればするほど「すばらしい」システムのようだ。

----追記（7/29）------------------------------------------------
7/29日、途中非公開にしていたこの記事を公開にした。
非公開にしていた間に、Doblogでの「マイプロフィール設定」の動作が変化したようだ。
以前は、ｈｔｔｐでデータを取得し、ｈｔｔｐｓで書き込んでいたようだが、いまは、両方ともｈｔｔｐｓになっている。だが、ｈｔｔｐｓがｈｔｔｐにリダイレクトされるため、パスワードは相変わらず平文で送られてくる。何をしているのか。

Doblog 編集部へ
「[ 2006/06/21 ]新バージョンの不具合に関しまして 」へのTB

Doblogバージョンアップ後、Doblogへの初期アクセスでレイアウトが崩れる件を6/21に修正していただきました。修正箇所は、異常に長くなってしまうトラックバックURLでした。確かに、レイアウトが崩れる不具合は、無くなりました。しかし、この修正で当然直ると思っていたところが直っていないため、少しきつい苦情を書きます。

この問題の本当の原因＝問題の根源は、TomcatのセッションＩＤが漏れていることにあったんじゃないでしょうか。修正以前のトラックバックURLは、CookieにセットされていたセッションＩＤと同じ値が付加された異常に長いURLになっていました。このセッションIDは、普通なら表に出すべきものではなく、内緒にしておかなければならないものですね。ですので、この問題は、見た目のレイアウトの崩れだけでなく、もっと深刻な問題だったのではないでしょうか？

そして、現在も、このセッションIDの漏れは、いたるところにあります。ソースを見てください。百数十箇所みつかります。だだ漏れなのです。どんなコードを書けばこれほどだだ漏れになるのか不思議なくらいです。しかも悪いことに、Googleは、この漏れたセッションIDをすでに万の単位でキャッシュしています。恥の上塗り、一目瞭然です。

世の中には、セッションＩＤが漏れたくらいでは、どうということも無いシステムもあります。でもこのDoblogは違うでしょう。セキュリティに関する問題なので詳しくは書きませんが、このセッションIDが、どうでもいいＩＤで無いことはご存知のとおりです。Doblogは、認証前後で、本来なら＝常識的には、こういう実装をしてはいけないという方式でセッション管理をしていますね。セッション情報には、ログインを認証したという情報も含まれているでしょう。ですからそのセッション情報が事前に漏れることは余計にまずいんじゃないでしょうか。

もし私がこのプロジェクトに関係していれば、何よりも何よりも真っ先に、このセッションＩＤの漏れを直すと思います。それが、プロとしての責任じゃないでしょうか。