Web屋のネタ帳

ちょっと前の記事だが、これ↓にかなり同意。

【ビジネス提案】家庭にはPCの代わりにThinClientを (sanonosa　システム管理コラム集: 2007/3)

ビジネス用途でばかり注目されがちなシンクライアントだが、こと日本においては、実は家庭向けにこそ通常のパソコンよりもシンクライアントが向いている。

とりあえず、シンクライアントについて説明しなければなるまい。

thin client = シン・クライアント は、文字通り「軽薄な」クライアントである。 実物で例を挙げると、

• TC-Station | シンクライアント端末 | NEC 8番街
  大きさのイメージがつきづらいと思うが、通常のPCよりぐっと小さく、弁当箱サイズを想像していただきたい。
• サン・マイクロシステムズ - Sun Ray 270 Virtual Display Client
  こっちはディスプレイ一体型。

こんなの。

通常のPCは、ＣＰＵやハードディスクなどの主要機能と、ディスプレイやキーボードなどの入出力機能が一体化されている。

一方シンクライアントは、CPUやハードディスクはサーバー側に集約され、クライアント側ではディスプレイとキーボード、そしてサーバーとの通信のみに特化された特殊なボードを積んだ弁当箱サイズのモジュールのみがある。ダム端末という単語を知っている古い人（笑）は、それを思い浮かべてほしい。

シンクライアントの利点については検索すればいろいろでてくるのでそっちに任せる。とりあえず サン・マイクロシステムズ - いま、なぜシンクライアントなのか あたりが短くまとまってる。

日本では、PCの維持管理の手間の削減というよりは、個人情報保護法にともなうセキュリティ強化という理由が多いようだ。例えば大量の顧客情報を扱わねばならないコールセンターのPCがシンクライアントに置き換えられたり。

だが、シンクライアントは企業のためだけではない。家庭向けにも大きな価値がある。

windows98で動く古いPCをいまだに使っている家庭は多い。買い替えに十数万円かかると思うと躊躇するのは当然である。ウィルス対策ソフトの更新を怠っているPCも多い。子供が勝手に導入したWinnyで情報流出事故しちゃいました、なんて事もあとを絶たない。運悪くハードディスクが壊れたら年賀状の送り先データもパーになっちゃいました、そもそも機械は苦手だetcetc...

Yahooメールでメールしてmixiで日記書いてANA Sky Webで飛行機のチケットを予約したい、ただそれだけのためにＰＣを購入することによって、これだけの手間や心配をかぶらなければならないことのほうがどうかしているのだ。

もしもNTTのOCNとかKDDIのDIONとかYahooBBとかが、ネット接続サービスとあわせてシンクライアントの提供もやるということになれば、その手間や心配の部分は家庭からすべて消え去る。

ワードやエクセルのライセンス料もプロバイダ側が負うのかって、そんなもん家庭にはもはやいらないので有料オプションで別料金扱いにしとけばいいのである。ブラウザ1枚でなんでもできるじゃないか。

コンピュータの管理権を家庭からプロバイダ側に渡せば自由にソフトをインストールできないじゃないかって、そりゃそうだが、子供がおかしなソフトを勝手に入れてしまう心配をしなくて済むメリットのほうが大きいのではないだろうか。繰り返すが、今はブラウザが使えればメールもmixiもデジカメ写真の保存も可能だ。余計な機能ばかりゴテゴテついてる高価なソフトの必要性自体をまず疑うべきだろう。

シンクライアントは、速い。サーバー側は基本24時間稼動である。そのため、PCのようにスイッチを押してOSが起動してさらに必要なソフトが起動してその間アンチウィルスソフトが余計なチェックを入れるためさらに時間がかかって、、、という時間が、必要ない。テレビのスイッチ並みのスピードでやりたい作業に入れる。この利点は地味だが、家庭環境では重要なことだ。寝る前にメールチェックしようと思ったけどPCを立ち上げるのにかかる時間を想像して「また明日にしよう」と思う人は少なくない。

シンクライアントは、安い。なぜならハードディスクもインテルのCPUも積んでないから。企業向けの仕切り価格で3万円以下くらいじゃないだろうか。壊れたら、シンクライアントごと交換してしまうだけ。データはサーバー側にあるのだし。すばらしいメンテナンス性である。もちろんサーバー側はそれなりに金がかかる。しかし、1台のサーバーが複数のシンクライアントにサービスを提供できる（※機種と構成にもよる）ことを考えれば、PCの管理の費用と手間と比べてほぼどっこいだろう。

シンクライアントにはUSB接続口もついているので、デジカメの接続くらいできる。 唯一問題なのは、印刷だ。プリンタの扱いをどうするかだが、シンクライアントを提供している各社はそれなりのソリューションをちゃんと出している。

シンクライアントの家庭への進出は、家庭向けPC市場を崩壊させることになりかねない。しかしそこはスクラップ＆ビルドである。 PCを製造販売しているメーカー各社は、その顧客を、家庭ではなくプロバイダに切り替えればいい。消費者向けビジネスはサポートに金がかかりすぎることだし、そのほうがいいのでは？

シンクライアントは、画面の情報をネットワークを介してやりとりしなければならないため、ある程度高速な回線を必要とする。どのメーカーのシンクライアントの紹介を見ても、企業LAN内での活用を想定した話しか載っていないのはそのためである。しかし、安価で高速なネットワーク回線が普通の家庭でも使えるという、世界的に見て実はまれな状況にある日本だからこそ、こんなことも考えうるのだ。

前にも似たようなことを自慢げに書いてるひとがいたが。

オンライン快適仕事術 - 重くなった Firefox 2.0 を劇的にスピードアップする13の方法

なんだかねえ。

以下、[Studying HTTP] Persistent Connections より抜粋。

---

RFC2616 section8.1.4より引用：
持続的接続を使用するクライアントは、サーバへ維持する同時接続の数を制限すべきである。 シングルユーザクライアントは、どんなサーバやプロクシへも 2 接続より多く維持すべきではない。 プロクシは、N は同時のアクティブユーザの数として、別のサーバやプロクシへの接続使用数を多くても 2*N までとすべきである。 これらのガイドラインは HTTP レスポンスタイムを改善し、ネットワークの混雑を避けようとするものである。

サーバは、不特定多数から接続される共有のリソースです。 従って、クライアントは、サーバへ同時に接続する数を多くても 2 までに制限すべきです。 プロクシの場合は、同時に接続されるユーザ数が例えば 50 の場合は、多くても 2 * 50 = 100 までにすべきです。

最近、一部では「高速化」と称して、ブラウザの同時接続値を大きな値にする事で、一度に大量のリソースを取得する行為が行われているようですが、このような行為は「一部の人間によるリソースの占有」とみなされるだけでなく、あまりに長い間続くとサービス拒否 (DoS) 攻撃とみなされる可能性もあるので、厳に慎むべきです。

---

抜粋ここまで。

再現手順

※環境は、WinXP+Firefox1.5。Cookie情報の参照と編集には Add N Edit Cookies :: Firefox Add-onsを使用した。

1. さくらインターネットのユーザーの契約情報などを見る画面において、ログインして、いろいろ情報を見る。
2. cookie情報を参照し、secure.sakura.ad.jpドメインで発行されている「SID」というCookieに格納されている値をメモ帳かなんかにコピペして保存しておく。
3. 画面右上の「ログアウト」ボタンを押す。念のためブラウザ内のすべてのCookie情報を削除し、さらにブラウザを閉じる。
4. 1年間待つ（笑）。筆者は本当に待ってた。というか、最近になってたまたま思い出して、試してみたらこんなだったので今これを書いている。そんなに待てるか！という人は、24時間でも3日でもいいだろう。
5. 待った後、再びメニューの画面にアクセスする。IDとパスワードの入力を促す画面が出ることを確認する。そこで、Cookie情報を手作業で追加、編集する。具体的には上でメモっておいた値をSIDというCookie名で保存する。ドメインはsecure.sakura.ad.jp、パスは/、secureフラグはオンにして、期限は適当に1年後くらいの日時にしておく。
6. その状態で改めてメニューの画面にアクセスする。IDやパスワードを入力してないのにログインした状態での画面が現れる。情報は見放題。サーバー設定画面での設定変更も可能だ。

問題点その１：ユーザーは明示的に「ログアウト」ボタンを押しているのに、サーバー側のセッション情報が消えていない

これはもう完全に言い訳のできない機能不備である。 画面上の「ログアウト」ボタンを押すと

Set-Cookie: SID=deleted; expires=Sat, 10 Apr 2006 05:36:41 GMT; path=/; domain=secure.sakura.ad.jp
※SID=deletedという部分はどうでもよくて、日付の部分が去年の日付になっているのがポイント。 Cookieを削除するというhttpヘッダは無いため、わざと古い日付を指定することでブラウザがそのCookieを削除するようにしむけるという手法。これはこれでおかしなやり方ではない。

というHTTPヘッダーがさくらのサーバ側から送信されてくる。どうやら管理画面のログイン機構を作った人は「ログアウトという処理ではブラウザ側のCookieを削除さえすればサーバー側の情報を消す必要はない」という大幅な勘違いまたは見落としをしているとしか思えない。

問題点その２：そもそも、「古いセッション情報はサーバー上から消す」という処理が存在しないらしい

なにしろ1年前の古いセッション情報すらサーバーから消えていないわけだから、そうとしか考えられない。そういう扱いが100%悪だとは言わない。扱っている情報の重要度にもよるからだ。だがしかし、レンタルサーバの契約／管理画面のセッション情報というものはそういう扱いをするにはクリティカルすぎる。

「ログアウトボタンをちゃんと押さなないでブラウザを閉じた場合の動作まで責任取れません」みたいな言い訳をするWebサイトも多いが、それは「サーバー側に保存されている、ある程度古いセッション情報の削除処理」をちゃんとやっていてこそ言えることである。

「古いセッション情報はサーバー上から消す」という処理の重要性をきちんと理解しているWebアプリ開発者は、もしかしたら意外と少ないのかもしれない。 例えばTomcatなんかではセッション情報はデフォルト30分でタイムアウトする。つまり、サーバ上に蓄積されているセッション情報のうち無接触のまま30分以上たっているものは「古い」とみなして自動的に削除されるようになっているのだ。モダンなAPサーバではこういう処理がもともと提供されているので、開発者があまり意識しなくなるのも無理はない。しかし、PHPやperlなどでオリジナルにセッション処理を書いている場合には、こうした点に注意するのも開発者の仕事のうちである。フレームワーク等を使う場合も、そういう処理がきちんと考慮されているフレームワークを選択するべきだろう。

問題点その３：重要な操作をするまえに改めてパスワードを入力させる過程が無い←間違い。あるようです。

サーバーのレンタル契約を解約するとか、住所などの情報を変更するとか、そういった重要な操作をする画面で「確定」のようなボタンを押す前にパスワードを入力させて確認する過程が無い。（←間違い。少なくとも解約機能の画面ではパスワードの再入力をうながす画面が出るようです） Webアプリケーションにおいてこれは保険みたいなものだが、やらないよりはやったほうがずっとマシである。

さくらインターネットという会社は、日本のWeb業界において目立たないけど確実な功績があると思う。 早くから低価格な共用/専用レンタルサーバーサービスを提供しはじめ、 多くの技術者（の卵）がその恩恵にあずかっているのは過去にも書いたとおりだ。株式も上場し、最近ではnaoyaのはてなダイアリー - さくらインターネット移行記#1といった感じの話題にもなって、好感度上昇中である。

だからこそ、というわけでもないが、その基幹サービスのセキュリティの甘さはあえて指摘せざるをえない。

（さくらインターネットの中の人のブログで「忌憚の無いご意見を」みたいなことが書いてあったのでとりあえずトラックバックしてみる）

追記(4/18)：
なんだかわざわざメールをくださった方（さくらの中の人からではない）がいる。その詳細については触れない。 が、いろいろ見てると、 セッションIDじゃないからかまわないとも受け取れることを言っている人がいるようだ。 「会員番号そのものではなく、少なくとも認証作業のつどくらいの頻度で毎回変わる文字列で、しかし古いものが使えてはだめで、、、」という情報って、それってWebアプリ一般におけるいわゆるセッションIDと呼ばれるモノと事実上どう違うというのだろう。

まあこの際、今考えうる脅威を具体的に示しておこう。

1. セキュリティ意識の甘そうな、小汚いネットカフェに行く
2. ブラウザのCookieをあさり、secure.sakura.ad.jpドメインで発行されているものを探す。 ※「当たる」確率は低いかもしれないが、そこはまあ「もしも」の話だということで。何しろ少なくとも1年以上有効だし
3. ビンゴ！とか言いながら、SIDという名前のCookieの値をコピ－／メモる。
4. その場で、またはまったくな場所のPCで、上の再現手順にあるようにCookieを手作業で書き換え
5. これでさくらの管理画面にアクセスすれば、その誰かさんの情報がまる見え。解約手続きだってできる。（←わー、間違えた。解約手続きは無理のようです。パスワードの再入力を求める画面がちゃんとでる）
   契約情報だけでなく、サーバーの管理画面も、ホームディレクトリ配下のファイルを見れる「ファイルマネージャ」なる機能にまでシームレスにアクセスできるので、コンテンツ改ざんも可能。
6. 被害者の側が、自分が管理画面にアクセスしたあとブラウザを閉じる前に「ログアウト」のボタンを押したかどうかは関係ないのは前述のとおり。←わー、間違えた。「ログアウト」ボタンを押した場合はブラウザ側のCookieが削除（deletedという文字で上書きも）され、盗むのはむずかしい。したがってログアウトちゃんとすれば大丈夫です。問題なのはログアウトせずにブラウザ閉じておしまいにしちゃった場合。Cookie値盗まれたらアウト。1年たってから盗まれてもアウト。

ネットカフェなんかでそんな画面にアクセスすんなよ、という話もあるが、数年前の銀行のネットバンキングサービスの不正アクセス事件はネットカフェのＰＣに仕込まれたキーロガーに起因していた。使う人は使うのである。

地方だとどうなのか知らないが、首都圏だと主要駅の近辺には必ずいる、「手相の勉強をしてるんですが」と声をかける、あからさまにあやしい人々。

オム来襲 - 宗教の営業「手相を勉強しています」

なるほどねー！ マニュアルというかシナリオがよくできてる。失敗したときの口止めまで考慮されてるとは。 よくできてるが、こんなんにひっかかる奴もどうかと思うが。

で、オチは、というか、結局どこの宗教なのよ？って話はここに書いてあります。

#探偵ファイル／スパイ日記 (2004/5)

See Also:
手相の勉強をしてる - Google 検索
霊感商法の実態 （全国霊感商法被害者対策弁護士連絡会）

ちょっと前に筆者が書いた

さくらインターネットの会員メニュー画面のセッション情報はログアウトしても1年たっても消えない件 (2007.4.16)

の件については、さくらの中の人が実にわかりやすい説明を自身のブログ上に書いてくださったようです。

会員メニューのセッションに関する指摘について (2007.4.24)

そもそもセッション維持（認証状態の維持）の方法それ自体が筆者の想定とは違う、そして、認証状態の継続期間の長短のポリシー的な問題に帰着する、と。

なるほど！かなりわかりやすい解説ありがとうございました。筆者の認識が一部間違っていたようだ。読者を混乱させてしまったばかりでなくさくらの中の人に変な心配をおかけましたことをお詫び申し上げます。

ただ、

指摘されている内容については、実際と異なることも多く、当該ブログの管理者様にはコメントだけお送りしたのですが、特に返事の無いまま、飛び火をして憶測だけが流れ続けていることに少し憂慮しており、ここで解説させて頂くことにしました。

たしかに、プロフィールのページに掲載している筆者のアドレス宛に直接メールをいただいた。読んだのは届いた3、4日後だったけど(苦笑)。その内容は この記事とほぼ同じ(さすがに認証状態維持の方式3種類の解説まではなかったが）で、かなりの長文。最後に「このメールを公開してくださってもかまいません」と記されていた。

うーん。 スパムならともかく筆者宛に送られた個人的メールの内容をを第三者が見れる場所（ブログとか）でまるごと公開してしまう趣味は少なくとも筆者には無いし、メールの内容を公開させてくれと筆者から依頼してもなく、もらったメールは公開しますよと前もって宣言してるわけでもないところで、「公開してくださってもかまいません」と判断をゆだねられても正直言って困るし、それって中の人（しかもかなり中枢）が果たすべき説明責任を筆者（のブログ）にゆだねる？ということとも取れなくもないし、それってどうなのよ俺さくらの広報担当じゃないし、、、という趣旨のことを筆者にしてはめずらしく返信メールとして書きだそうかなと思ったところで、待てよ？さくらの中のえらい人らしいし、自分のブログだってあるしその気になればさくら本体のサイトで広報させることもできる人だろうし、ということは少し待てば詳しい説明なり対応なりがどっかでなされるだろうなあ、、、と思い至ったところでかなり夜遅くだったので送信キャンセルボタン押して寝た、というのが筆者から見た経緯である。（ああ、実際そうなったんだからもうこれ以上つっこむこたぁないだろと頭の中でコビトさんがつぶやいている・・・）

建設的な話に戻そう。残る問題は、

Webサイト/Webアプリケーションの認証状態の継続期間はどうあるべきか？

である。

Webサイトの開発は比較と模倣(笑)が基本だ。わかりやすいところでYahooを見てみる。 まずはYahoo（Yahooメールやオークションなど共通）のログイン画面↓


次にさくらインターネットの会員メニューのログイン画面↓


違いはもちろん赤い矢印の部分である。 認証状態を長時間にわたって維持させるかどうかをユーザーが選択できるようになっているのがYahooである。Yahooに限らず他のサイトでも見かけるだろう。

カラクリはこうだ。Yahooのログインで矢印の部分にチェックを入れてログインボタンを押したときにYahooから送信されてくるCookieは有効期限付き。チェックを入れない場合のCookieは有効期限なし＝そのCookieの有効期限はブラウザが起動している間のみ。 対して、さくらネットのログイン画面で送信されるCookieは常に有効期限が設定され、ブラウザを閉じたりPCを再起動してもそのCookieは生きてしまう。

かなり長期間の有効期限設定のCookieであっても、サーバー側で発行日時（認証日時）をしかるべく維持/監視していれば認証状態はどうにでもいじれる（っていうか実際そうすべき）が、「そもそも有効期限なしのCookie送っとけばいいじゃんCookieってもともとそういう仕様のものなんだし」という感じで、ブラウザに本来備わる機能を有効活用するように考えられているのがYahoo方式である。

ブラウザを閉じたあとでも認証状態を維持するか否かをユーザーが選択できるようにするとして、 では次に考えなければならないのは「ログイン成功後、どの程度の時間その認証状態を維持するか」である。

下記は、 https://edit.yahoo.co.jp/config/set_profileの画面の下のほうのキャプチャである。



デフォルトが24時間（毎日）であり、かつ最長設定でも24時間である。 さらにクリティカルな情報の画面ではこの設定値にかかわらずいちいち認証画面にリダイレクトされる。たとえば上であげたこの画面とか。 ちなみにさくらインターネットの会員メニュー画面では同種の設定画面は見つからなかった。

まとめ。Webサイト/Webアプリケーションの認証状態の継続期間はどうあるべきか？

1. そもそもブラウザを閉じても認証状態を維持するか否か自体をユーザーが選択できるようにしてあるサイトが多い。（有効期限なしCookieの活用）
2. 認証状態を維持する利便性とセキュリティ確保の兼ね合いはユーザーの使い方や立場によっても違うので、認証状態を維持する最大時間をユーザー自身が選択できるようにしておけるとなお良い
3. いずれにしても認証状態の維持継続時間の最大値は短めに。
4. クリティカルな画面では1-3までがどうなってるかにかかわらず頻繁に認証処理を入れる

とりあえず以上がYahooから読み取れた。件のさくらインターネットの会員メニュー画面でどうなのかはこの前の記事に書いたとおりである。