公式サイトのメイン部分に、
Cache-Control: no-store
ヘッダつけました。

確認してる範囲ではブラウザにキャッシュされて問題になることはありませんでしたが、
明示的にキャッシュ不可にしないと問題が生じる可能性もあると思うので。

公開ページの方も掲示板とかうまいことCache-Controlできないか？
と考えてもいるが、難しいかな・・・

セッションIDとワンタイムパスワードのCookieにHttpOnly属性をつけました。

HttpOnly属性ってのはFirefox2の時代からあったらしいんですが、知らなかった・・・
属性つけてクッキー発行した場合、
ブラウザサイドのスクリプトから取得できなくなり、若干セキュリティが強化されます。

セッションIDについては
www ←→ ssl
間での通信にクエリで送ってるんで、
Cookieだけ隠してもあまり意味はないかも。

通常ログインに関しては元々クッキーだけではセッション維持できませんが、
ワンタイムログインはクッキーだけで認証できるんでワンタイムパスワードが隠せるのはちょっと意味があると思う。


まあ、クッキーがスクリプトで読めなかったとしても、
スクリプト埋め込めるんならAJAXとか出来ますから、あまり意味ない気もしますけど。


SSLページの方もセッションIDとワンタイムパスワードはクッキーに保存しますが、
SSLページは全てのページでssl.rentafree.net以外のドメインのコンテンツは埋め込んでいませんので、
元々問題があるとは思いませんのでHttpOnly属性はつけていません。

php5-cgiの脆弱性のアップデート適用ついでにメインサーバー再起動しました。
サブサーバーの方はさっき再起動してました。
php5-cgiのアップデートは不完全で、今日明日にも新しいのが来るとかどうとかって話なんで、
もう一回アップしそうではあります。
まあ、phpは非公開部分でMySQLのアレ用にしか使ってないんで問題ないとは思います。


あと、ちょうどいい機会なんで、
今まで常駐プロセスは手動起動していましたが、
起動時に自動起動するようにしました。

サービス開始から2年弱ですが、
今までに2回、サーバー再起動に気づかずに長時間障害出したことがありますが、
再起同時に自動起動で、勝手に再起動でも安心。
まあ、予期せぬ再起動が発生すると破損の可能性が生じますけど・・・

php5-cgiに脆弱性があるみたいなんで、
公開部分ではphp動かないようになっているんであまり問題なさそうなんですが、
php5-cgiのアップデート適用するんで、
ついでに色々アップしてサーバー再起動します。

で、多分今日やると思いますが、
今きてるアップデートが不完全らしいんで、
近日中にもう一回やりそうです。

テンプレートCSSの配信仕様を変更完了しました。
不具合がありましたら報告お願いします。

[変更点]
＊Content-Encodingな時にリクエスト時に圧縮していたので、編集時に圧縮して効率よく配信できるようにした。
＊Wikiと掲示板のCSSはLast-Modifiedヘッダに対応してなかったので対応させた。
＊Wikiと掲示板の公式テンプレートは!DOCTYPEがHTML5になってなかったので全部HTML5にした。

テンプレートのCSS配信の効率を上げるために修正します。
というか、すでにDB構造と管理ページの編集の方は修正してあります。
不具合発生したらごめんなさい。

変更内容ですが、
gzip転送いける場合は、今はリクエスト毎に動的にgzip圧縮してるんですが、
効率よくないと思うんで、
事前に圧縮データを保存しておいて適切な方を配信します。

配信側はまだ修正してません。
既存データを圧縮して、少し様子見してから完全修正します。


あと、今回の件でブログ以外にもWikiと掲示板も同じにしようとしましたが、
ブログの方は元々対応してたんですが、
Wikiと掲示板はLast-Modifiedヘッダ出力できない仕様だったんで、そこも修正します。

元々期限いっぱい残ってたんですけど、
優待の使い道がないんで、
このサービスで使ってるドメイン契約更新しておきました。
残り4年くらいあるんで、当分は更新し忘れの危険もなく安心です。

次回は多分半年後に優待もらえるつもりなんですが、
これ以上期限伸ばすのもどうかと思うんで、
公式ドメイン追加するかもです。
まあ、半年後になりますけど。


ついでに、うちは独自ドメインも設定できるんで、
ドメイン屋のアフィ貼っときます。

定番の大手ドメイン屋です。
うちも今はここ使ってます。
初年度だけいつも激安キャンペーンやってますけど、
更新は920円/年だと思います。
まあ、年払なんでサーバー代なんかに比べると安いもんです。
株持ってると優待で全額キャッシュバック（上限付き）とかあります。

「安全性について」のページを作り、
トップページにリンクを設置しておきました。

うちのサービスは、
ランダムパスワードを利用してもらうために、
「パスワードは覚えなくていいもの。」
って考えで作ってますんで、
他所のサービスと言ってること違ったりしますんで、
安全性についての考えをまとめました。

3Dリマインダ機能を実装しました。

この機能は、パスワード問い合わせ機能の不正利用を防止するための機能です。
ログイン状態で、メールアドレス変更ページから設定できます。

未設定状態でパスワード問い合わせ機能が利用された場合、
アカウントのメールアドレスにパスワード記載のメールを送信しますが、
この機能が設定されている場合は、
アカウントのメールアドレスにはメール発射用のURLを記載したメールを送信し、
URLに接続すると3Dリマインダで設定されたメールアドレスにパスワードを記載したメールを送信します。


メールというのは受信者が読める文章を利用するので、
メールサーバー管理者は盗み見ることができますし、
組織内ネットワークから平文で受信する場合などはネットワーク管理者等に傍受される危険があります。

しかし、この機能を利用すれば、
アカウントのメールと3Dリマインダのメールの両方のメールアドレスが受信できないとパスワード問い合わせ機能が完結しません。

アカウントのメールを傍受できる場合は問い合わせ機能自体は利用できますが、パスワード記載のメールは別です。
3Dリマインダのメールを傍受できる場合はパスワード記載のメールを読めますが、問い合わせ機能自体が利用できません。


機能を利用する場合は、
同一メールサーバーのメールアドレスを利用してもあまり意味がありませんので、
アカウントのメールアドレスにはフリーメール等を設定し、
３Dリマインダには携帯メール等を設定することを想定しています。

パスワードリマインダのセキュリティ強化を検討していますが、
メールアドレスを２つ利用することにより、
片方のメールが傍受される場合でも、
両方のメールを読むことができなければリマインダが使えなくなるようにする機能をつけるわけですが、

一度アカウントのメールアドレスにURLつきメールを送信し、
接続すると2番目のメールアドレスにパスワードを送信する感じで考えているんで、
1番目のメールは他のメール確認処理と共通化したいんですが、
パスワードリマインダは非ログイン状態で利用するものですので、
非ログイン状態のメール確認を共通化するにはちょっと修正が必要だったので修正しました。


リマインダの強化は多分やります。
設定しなければ今までどおりアカウントメールアドレスだけでリマインダできるようになるはずです。