WordPress のPHP環境をもう少しセキュアにする

はてなブックマークを見ていたら、文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定 というエントリを見つけた。

全て PHP で実装され、かつ日本語版は UTF-8 がデフォルトの文字コードになっているWordpress にも効果的と思い早速導入してみることにした。

エントリーはphp.iniの設定追加(変更)を前提に書かれているが、共有ホスティングの場合は、php.iniがいじれない。そこで、.htaccess に php_value/php_flag ディレクティブを指定することで、自分のwebサイトに対して、カスタムの php オプションを指定することができる機能を利用する。実際にどのように書き換えるか、簡単ではあるが役に立つかもしれないので、エントリしておく。

「.htaccess」ファイルでの設定を参考にさせてもらいながら、php.ini の書式を.htaccess 用に変更する。On/Off で設定するものについては、php_flag ディレクティブを、それ以外は、php_value ディレクティブを使用する。また、値の指定に「=」は使用しないので、空白にする。

自分が使っている、.htaccess に以下のエントリを追加。

 
#出力バッファリングを無効にする
php_flag output_buffering Off
#HTTPレスポンスの文字エンコーディングを設定
php_value default_charset UTF-8
#デフォルトの言語を日本語にする
php_value mbstring.language Japanese
#HTTP 入力変換を有効にする
php_flag mbstring.encoding_translation On
#HTTP 入力エンコーディング変換を UTF-8 に設定(UTF-8→UTF-8の変換)
php_value mbstring.http_input UTF-8
#HTTPレスポンスは変換しない
php_value mbstring.http_output pass
#内部エンコーディングを UTF-8 に設定
php_value mbstring.internal_encoding UTF-8
#無効な文字は「?」に
php_value mbstring.substitute_character “?”

(※元の設定項目・コメントは徳丸浩さんの文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定 そのままです。これを .htaccess で使えるように変更したものになります。設定の詳細についてはこちらのサイトをご参照下さい。)

これを、自分の web サイトのドキュメントルートにアップロードすれば完了する。念のため、表示が正しいかどうか、確認しておいた方が良いでしょう。

WordPressをCside Netからさくらインターネットに移行する

今回のエントリは、レンタルサーバを使って自分で WordPress を運用している人にだけ役に立つ(かもしれない)エントリです。Cside Netから、さくらインターネットに移行した際の手順をメモしたエントリです。WordPress のデータレポジトリを MySQL4 から MySQL5 に移行する場合の手順を含んています。羊ページはこうやって運用されているのか、という雰囲気が分かって面白い人には、面白いかもしれません。


羊ページは約 8年に渡って、Cside のレンタルサーバ上で運用してきた。この間、長時間のサービス停止やデータロストもなく、おおむね満足すべき運用だったと思う。しかし、2010年の 5月から WordPress を CMS として全面的に使用するようになって、MySQL のバージョンが4.0.x であること、またそのパフォーマンスには不満を感じていた。特に、MySQL のバージョンが低いことで、WordPress の最新バージョンや一部のプラグイン(broken link checker等)が使用できないのが非常に問題だった。

羊ページは元々静的 HTML で構築されていたが、ひつじログとして幾つか CMS も試している。ただ、メインテナンスの困難さと自由度の低さから、どれも使ってみて都度断念してきた。WordPress は初めて、これなら使えると思った CMS だ。WordPress の 3.2ではMySQLは5.x が要求されることが既にアナウンスされており、Cside が MySQL5 を提供しない限り、羊ページは WordPress のバージョンアップが出来なくなる。

ホスティング契約の更新を目前にして、Cside のサポートに MySQL5 提供の可能性について問い合わせてみたが、予定は無い、との回答が来てしまった。であれば、業者を変えるしかないと即決した。


僕が最初にホスティング業者を選ぶときに Cside と迷ったのはさくらインターネットだった。当時から、Shell が解放されている業者として有名だったが、8年たって、ホスティング業者の大手に成長したようだ。実際にサービス内容と価格を比べてみると、Cside がこの数年、あまり新しい機能を入れてきていないのに比べると、積極的に色々サービスが拡充されている印象を持った。

僕が Cside と契約していたのは、Personal 独自ドメインと呼ばれるもので、年額 20,160円で 5GBのディスクスペースが提供される。Shell アクセスは無く、SSL は使えるが CA は独自(信頼されていないサイトの警告が出てしまう)だ。収容サーバは Intel Xeon 2.8GHzでメモリ1GB、2003年からの運用されており、OS は Debian 3 だ。

これに対して、さくらインターネットの相当する契約は(おおよそ)、レンタルサーバ プレミアムで、年額 15,000円+工事手数料 1,000円。ディスクスペースは40GB(RAID1) 使えて、MySQLは4 or 5 のいずれかが選択できる。SSL は共有だが、公式の CA の認証を通ったものだ。サーバーは新規のものに収容されたようで、Intel Core2 CPU T7200 2.00GHz でメモリ 2GBのスペック。OS は FreeBSD 7.1-RELEASE-p13 i386 が載っている。Apache のエラーログが見られたり、Web ベースのファイルマネージャがあるのが便利。


ディスク容量だけでサービスを評価するのは意味がないが、Csdie に比べてさくらインターネットは容量 8倍、価格が 2割安く年払いでもカード決済が可能(Cside は年払いは銀行振り込みのみ)。

メールアドレスの発行や、ML の運用などのできることはほぼ同じだが、コントロールパネルの作り込み、ConceptBase を使った FAQ DB の検索機能、spam メールフィルタの標準装備など、使い勝手ではさくらインターネットが勝っている印象を受けた。ということで、サインアップしてみた。

なお、さくらインターネットのサインアップ画面は、JavaScript 等で凝った遷移をしているのか、セキュリティー系のプラグインを沢山入れたfirefox では申し込みを完了することができなかった。(結局、IE を使った)


申し込みから数分で、完了報告とアカウント情報がメールされてくるので、早速移行作業を開始する。幾つか、試行錯誤をしたのだが、うまくいった方法を中心に書いておく。

まず、移行前環境と移行先環境の整理。


■移行元
Cside.jp Personal 独自ドメイン
MySQL 4.0.24

■移行先
さくらインターネット レンタルサーバプレミアム
My SQL 5.1.42

■レジストラ
goddady.com

手順としては、以下のようになる。

移行元 Apache 上のデータをローカルにFTPダウンロード→移行元 MySQL のテーブルをエクスポート→ローカルに落とした Apache 上に載せるデータを移行先に FTP アップロード→ローカルの MySQL テーブルデータを移行先にアップロード→ wp-config.php の DB 設定を変更→さくらインターネットに sheeppage.net を登録→レジストラの Nameserver エントリを移行先の DNS サーバに変更


まず、Cside のサーバ上にある WordPress 本体や画像ファイルなどをまとめて、FTP 経由でローカルに落とす。元々マスターがローカルにあっても、作業用のデータファイルなどが混ざっていて、移行には向かない場合がある。あらかじめ、落としておいた方がよい。また、WordPress のプラグインやテーマはWeb の管理画面からイントールや設定変更が行われるので、ローカルの初期状態とは食い違っている場合が多く、面倒だがこの手順を踏んでおくことをお勧めする。

なお、ASCII と Binary を間違えると当然、ファイルが壊れるので拡張毎に処理を分けられるクライアントを使った方が良い。*.mo ファイルなど WordPress 固有のバイナリファイルの拡張子には注意。


次に、MySQL のテーブルデータをエクスポートしておく。wp_ で始まるテーブルを全てエクスポートする。作業には、phpMyAdmin を使用することになるが、必ずインターフェイスを UTF8 に切り替えておくこと。WordPress 日本語版は UTF8 でデータを格納しており、phpMyAdmin のデフォルトの EUC モードでエクスポートすると.sql ファイルの中が EUC と UTF8 混在になってしまう(これに気がつかなくて、やり直しになった)

さくらインターネット側は16MiB までのインポート制限がある。zip 圧縮にも対応しているので、もし.sql ファイルが大きくなってしまった場合は、ローカルで一度.zip に圧縮してから(Csideの phpMyAdmin はエクスポート時の圧縮オプションに対応していない )アップロードしても良いだろう。しかし、元があまり大きな.sqlファイル(30MBとか)では、圧縮すればエラーにはならないが、インポート時に結果表示がきちんと出ないので、一度にインポートする適宜テーブルの数を調整した方が良い。僕は10MB程度で分割して、4つのエクスポートファイルを使用した。


さくらインターネットの Apache に、ローカルのファイルをアップロードする。Cside とは推奨のアクセス権が異なっているので注意。アクセス権は705 になるように、FTP クライアントのデフォルト設定を変更しておく必要がある。


さくらインターネットの MySQL にテーブルデータをインポートする。まず、コントロールパネルから DB のバージョン(MySQL5)を選択し、パスワードを設定して DB が使えるようにしておく。

phpMyAdminの管理画面の言語設定がUTF8になっていることを確認し、おまじないに(Helpを読んでみたものの、これが正しいのか自信はないが)SQL互換モードをMySQL40に変更してインポートする。

インポート先は自分の契約ドメインの方にして、スキーマにインポートしてしまわないように注意(そういうことをする人は、そもそもこういう作業はしないと思うが、、)

インポートの際には、クエリがノーエラーで通ったことを確認する。


WordPressのDB設定をCsideのものから、さくらインターネットのものに変更してアップロードする。wp-config.phpのサーバ名、DB名、ユーザ名、パスワード、のみ変更する。

ここまでの作業で、サーバ上のデータは完全に移行先にコピーされた。次に、自分の契約しているgTDLドメインをさくらのサーバに登録する。コントロールバネルから、自分のドメイン(僕の場合sheeppage.net)を追加する。この作業は必ず、レジストラ側の設定変更の前に行うこと、とさくらインターネットの移行手順には書かれているので注意。

次に、(ここは各自の契約形態によるが)、DNS の設定変更を行う。具体的には、自分の契約しているレジストラ(僕の場合はgodaddy.com)に Nameserver の変更依頼を行う。

godaddy.com では、契約更新や Nameserver の変更は全て web から可能なので、ここでさくらインターネットの DNS サーバ(プラマリ/セカンダリ)に書き換えておく。浸透速度はケースによるが、僕の場合1時間程度で浸透した。


DNS の変更が済めば、WordPress の管理画面から一通りの設定の調整を行えば移行は完了する。例えば、wp-DBManager のアーカイブ保存先パスなどは、Cside とさくらインターネットでは異なるので、設定変更する必要がある。

また、DNS の変更後に Cside 側の設定を変更したくなった場合には(さくらインターネットのように、サブドメイン経由での設定変更ではないので)一時的に、Cside の DNS をクライアントから参照することで、移行前の sheeppage.net にアクセスできることも覚えておきたい(DNS 変更後に Cside のコントロールパネルへのアクセスが出来なくなって非常に焦ったのだった、、)


以上、Cside からさくらインターネットへの WordPress 移行のメモでした。さくらに移行後、直ぐにWordPress を最新の 3.0.1 にアップデートしましたが、かなり改良点が多く、移行して正解、と思っています。

web の Flash 化に対する異議

web サイトを Flash で作るっていうのは、僕は嫌い。そんなもので、幾ら見た目を格好良くしても、なんの意味もない。安易だ、と思う。

web でどう表現するかは自由だ、という意見と、スタンダードを守るべきだ、という意見は、web の誕生の頃からあって、(古くは、フレームの是非とかありましたね)そのバランスの中で、スタンダードも進化して今日に至るわけだけれど、アプリケーションとしての web ではなくて、コンテンツとしての web にあっては、依然として僕はスタンダードが守られるべきだと思っている。

その中にあって、Flash は スタンダードでは無いと思う。何よりも、安易な、「コンテンツとしての web の Flash 化」は、幼稚で自分勝手で、web デザイナーが単価を上げて、よく分かっていないクライアントをだまくらかす手段だとさえ思う。HTML で誠実にコーディングした格好良いサイトより、Flash で簡単かつ派手に作った方が、「分かってない人」からは、絶対金が取れる。


安易な Flash 化によって、web の非同期的な心地よさは失われる。本来、コンテンツとしての web はインタラクティブであってはならない、とさえ、僕は思っている。web は本のように、あくまで受動的であるべきだ。メニューを押してからの演出としてのディレイを取られたり、自分のフォント設定を無視して表示されたり、skip を押すまで勝手にムービーを流されたり、そんなお節介は不要だ。世界はお前のサイトのためにあるのではないし、web ページはテレビのチャンネルとは違うのだ。

例えば、ある写真展を見に行こうとして、公式サイトに行くと、全部 Flash でつくってある。文字の大きさは変えられないし、フレームサイズも固定だし、PC の画面は俺様のためにある的な傲慢な作りだ。アクセスの所をクリックすると、これまた Flash の中に、地図が開く。普通、これって印刷して、手に持って会場にいくものでしょう。どうやって印刷しろと?

スクリーンショットを撮って、画像ソフトにペーストして、保存して、印刷した。なんだそれ。web の一番大切な、アクセシビリティーの無視、もしくは、配慮の欠落。
僕も Flash でつくった、お遊びコンテンツは大好きだ。ああいう、小学校の頃、ノートの片隅に書かれて、クラス中を回ったような感じの下らないコンテンツが、エンハンスされて世界規模で出回っているのも面白いと思う。逆に言うと、そんな程度の用途で十分だよ、と思う。

もっと、考えよう。