Web屋のネタ帳

再現手順

※環境は、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年たってから盗まれてもアウト。

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